1 -> Overview
The Ark development framework, which is compatible with JS-like web development paradigm, adopts the classic three-stage development method of HML, CSS, and JavaScript. Use HML tag files for layout construction, CSS files for style descriptions, and JavaScript files for logical processing. The UI components are associated with data through one-way data binding, and when the data changes, the UI interface automatically triggers an update. This development method is closer to the usage habits of Web front-end developers, and quickly transforms existing Web applications into Ark development framework applications. It is mainly suitable for small and medium-sized application development with a simple interface.
1.1 -> Overall Architecture
The Ark development framework uses a JS-compatible web development paradigm, including the Application Layer, the Front-end Framework Layer, the Engine Layer, and the Porting Layer.
Application
The application layer refers to the FA application developed by the developer, and the FA application here refers to the JS FA application.
Framework
The front-end framework layer mainly completes front-end page parsing, and provides capabilities such as MVVM (Model-View-ViewModel) development mode, page routing mechanism, and custom components.
Engine
The engine layer mainly provides animation parsing, DOM (Document Object Model) tree construction, layout calculation, rendering command construction and drawing, event management, and other capabilities.
Porting Layer
The adaptation layer mainly completes the abstraction of the platform layer and provides an abstract interface, which can be connected to the system platform. For example, event docking, rendering pipeline docking, and system lifecycle docking.
2 -> File organization
2.1 -> Directory structure
A typical development directory structure for a JS module (entry/src/main/js/module) for a JS FA application is as follows:
Directory structure:
Multi-instance resource sharing directory structure:
The catalog structure Chinese parts are classified as follows:
An HML template file ending in .hml that describes the file layout structure of the current page.
.css end of the CSS style file that describes the style of the page.
.js JS file at the end handles the interaction between pages.
What each folder does:
app.js files are used for global JavaScript logic and application lifecycle management, as detailed in app.js.
The pages directory is used to store all component pages.
The common directory is used to store public resource files, such as media resources, custom components, and JS files.
The resources directory is used to store resource configuration files, such as multi-resolution loading configuration files, see the Resource Definition and Access section for details.
The share directory is used to configure the resource content shared by multiple instances, for example, images and JSON files in share can be shared by default1 and default2 instances.
illustrate
i18n and resources are development reserved folders and cannot be renamed.
If a resource in the Share directory has the same name as the resource file in the instance (default) and the directory is the same, the priority of the resources in the instance is higher than that of the resources in the Share.
The share directory does not currently support i18n.
When using DevEco Studio for application development, you need to create an optional folder in the directory structure based on your actual situation.
2.2 -> File Access Rules
Application resources can be accessed through an absolute path that starts with “https://dev.to/” and a relative path that starts with “./” or “.. /”。 The specific access rules are as follows:
For referencing code files, it is recommended to use relative paths, such as: /common/utils.js。
For referencing resource files, it is recommended to use absolute paths. For example: /common/xxx.png.
It is recommended that public code files and resource files be placed under the common directory and accessed through the preceding two rules.
Use the url() function to create < url > data type in the CSS style file, for example: url(/common/xxx.png).
illustrate
When code file A needs to reference code file B:
If code file A and file B are in the same directory, code file B can use either relative or absolute paths when referencing resource files.
If code file A and file B are in different directories, code file B must use an absolute path when referencing the resource file. This is because when Webpack is packaged, the directory of code file B changes.
When you specify a resource file path in a JS file by data binding, you must use an absolute path.
2.3 -> Media file format
3 -> js tag configuration
The js tag contains the instance name, page route, and window style information.
illustrate
Tags such as name, pages, and window must be configured in the “js” tag in the configuration file (config.json).
3.1 -> pages
Define the routing information for each page, each page consists of a page path and a page name, and the file name of the page is the page name. Like what:
{
...
"pages": [
"pages/index/index",
"pages/detail/detail"
]
...
}
illustrate
The first page in the pages list is the home page of the application, that is, the entry entry.
The page file name cannot be a component name, such as text.hml or button.hml.
3.2 -> window
window is used to define the configuration related to the display window. There are 2 ways to configure screen adaptation:
Specify designWidth (screen logical width), all size-dependent styles (e.g. width, font-size) are scaled in proportion to designWidth and the actual screen width, e.g. when designWidth is 720, if you set width to 100px, on a screen with an actual width of 1440 physical pixels, the width is actually rendered in 200 physical pixels.
Set autoDesignWidth to true, the designWidth field will be ignored and the components and layouts will be scaled to screen density when rendering. The screen logical width is automatically calculated from the device width and screen density, and may vary on different devices, so use relative layouts to accommodate multiple devices. For example, on a device with 466*466 resolution and 320dpi, the screen density is 2 (based on 160dpi), and 1px is equal to 2 physical pixels rendered.
illustrate
The default value type in the component style is calculated and drawn according to the screen density, for example, on a device with a screen density of 2 (based on 160 dpi), when the default length > is 1px, the The setting of autoDesignWidth and designWidth does not affect the default value calculation method and drawing result. The following is an example:
3.3 -> Example 4 -> app.js 4.1 -> Application Lifecycle Each application can customize the implementation logic of the application-level lifecycle app.js, and the following example prints only the corresponding logs in the lifecycle function:
4.2 -> Apply object 6+ The following is an example:
{
...
"window": {
"designWidth": 720,
"autoDesignWidth": false
}
...
}
{
"app": {
"bundleName": "com.example.player",
"version": {
"code": 1,
"name": "1.0"
},
"vendor": "example"
}
"module": {
...
"js": [
{
"name": "default",
"pages": [
"pages/index/index",
"pages/detail/detail"
],
"window": {
"designWidth": 720,
"autoDesignWidth": false
}
}
],
"abilities": [
{
...
}
]
}
}
// app.js
export default {
onCreate() {
console.info('Application onCreate');
},
onDestroy() {
console.info('Application onDestroy');
},
}
// app.js
export default {
data: {
test: "by getAPP"
},
onCreate() {
console.info('AceApplication onCreate');
},
onDestroy() {
console.info('AceApplication onDestroy');
},
};
// test.js 自定义逻辑代码
export var appData = getApp().data;
