diff --git a/en/application-dev/ability/ability-assistant-guidelines.md b/en/application-dev/ability/ability-assistant-guidelines.md index 09feb5e590a67df877035069f0d80d8765831fd5..7af76245661a90090b4ba2533b5f24ea5e9a6b09 100644 --- a/en/application-dev/ability/ability-assistant-guidelines.md +++ b/en/application-dev/ability/ability-assistant-guidelines.md @@ -10,7 +10,7 @@ The ability assistant is pre-installed in the device environment. You can direct - **help** - Displays the help information about the ability assistant. + Displays help information for the ability assistant. **Return value** @@ -69,18 +69,18 @@ The ability assistant is pre-installed in the device environment. You can direct - **dump** - Prints ability related information. + Prints ability-related information. | Name | Level-2 Parameter | Description | | ----------------- | -------------------- | ------------------------------------------------------------ | | -h/--help | - | Prints help information. | | -a/--all | - | Prints ability information in all missions. | - | -l/--mission-list | type (All logs are printed if this parameter is left unspecified.)| Prints mission stack information.
The following values are available for **type**:
NORMAL
DEFAULT_STANDARD
DEFAULT_SINGLE
LAUNCHER | + | -l/--mission-list | type (All logs are printed if this parameter is left unspecified.)| Prints mission stack information.
The following values are available for **type**:
- NORMAL
- DEFAULT_STANDARD
- DEFAULT_SINGLE
- LAUNCHER | | -e/--extension | elementName | Prints extended component information. | - | -u/--userId | UserId | Prints stack information of a specified user ID. This parameter must be used together with other parameters. Example commands: aa **dump -a -u 100** and **aa dump -d -u 100**.| + | -u/--userId | UserId | Prints stack information of a specified user ID. This parameter must be used together with other parameters.
Example commands: aa **dump -a -u 100** and **aa dump -d -u 100**| | -d/--data | | Prints Data ability information. | | -i/--ability | AbilityRecord ID | Prints detailed information about a specified ability. | - | -c/--client | | Prints detailed ability information. This parameter must be used together with other parameters. Example commands: **aa dump -a -c** and **aa dump -i 21 -c**.| + | -c/--client | | Prints detailed ability information. This parameter must be used together with other parameters.
Example commands: **aa dump -a -c** and **aa dump -i 21 -c**| **Method** diff --git a/en/application-dev/ability/ability-brief.md b/en/application-dev/ability/ability-brief.md index 501b8a9514a4fbc1ed9481979ef32e1a59fcff41..06cf48ff0213a6bae33e0cd5d0a2c2cf4b5d042d 100644 --- a/en/application-dev/ability/ability-brief.md +++ b/en/application-dev/ability/ability-brief.md @@ -1,6 +1,6 @@ # Ability Framework Overview -An ability is an abstraction of a functionality that an application can provide. It is the minimum unit for the system to schedule applications. An application can contain one or more **Ability** instances. +An ability is the abstraction of a functionality that an application can provide. It is the minimum unit for the system to schedule applications. An application can contain one or more **Ability** instances. The ability framework model has two forms. @@ -17,7 +17,7 @@ The stage model is designed to make it easier to develop complex applications in | Bundle description file | The **config.json** file is used to describe the HAP and component information. The component must use a fixed file name.| The **module.json** file is used to describe the HAP and component information. The entry file name can be specified.| | Component | Four types of components are provided: Page ability (used for UI page display), Service ability (used to provide services), Data ability (used for data sharing), and Form ability (used to provide widgets).| Two types of components are provided: Ability (used for UI page display) and Extension (scenario-based service extension). | -In addition, the following differences are available in the development process: +In addition, the following differences exist in the development process: * Different ability types diff --git a/en/application-dev/ability/ability-delegator.md b/en/application-dev/ability/ability-delegator.md index a0bfc0908e5640b63af1f7abb1f7ec9c101b5002..cc7547e3806385f9bfba6d21314065d788032cae 100644 --- a/en/application-dev/ability/ability-delegator.md +++ b/en/application-dev/ability/ability-delegator.md @@ -1,23 +1,23 @@ # Test Framework Usage ## Overview -The delegator test framework provides a self-test framework (environment) for OpenHarmony applications. Using this framework, you can start an ability, schedule its lifecycle, listen for its state changes, run a shell command, and print the test result. +The delegator test framework provides a self-test environment for OpenHarmony applications. Using this framework, you can start an ability, schedule its lifecycle, listen for its state changes, run a shell command, and print the test result. ## Constraints -The APIs provided by the test framework can be used only in the test HAP. They take effect only after the test framework is started by running the **aa test** command or using the Integrated Development Environment (IDE). +The APIs provided by the test framework can be used only in the test HAP. They take effect only after the test framework is started. ## Starting the Test Framework -The test framework can be started using either of the following methods: +The test framework can be started in either of the following ways: -- Method 1: Run the **aa test** command. -- Method 2: Use the IDE. +- Method 1: Run the `aa test` command. +- Method 2: Use DevEco Studio. ### Running aa test -You can run the **aa test** command to start the test framework. You can specify the **TestRunner** to be used and the package name or module name of the HAP where the **TestRunner** is located. +To start the test framework, specify the **TestRunner** and the package name or module name of the HAP where the **TestRunner** is located. An example command in the FA model is as follows: @@ -37,17 +37,17 @@ aa test -m com.example.myapplicationfaets -s unittest OpenHarmonyTestRunner -s c | -w | No | Timeout interval of a test case, in seconds. If this parameter is not specified, the test framework exits only after **finishTest** is invoked.| | -s \\ | No | It can be any parameter in the key-value format. The entered parameters can be obtained in key-value mode through **AbilityDelegatorArgs.parameters**. For example, in **-s classname myTest**, **classname** is the key and **myTest** is the value.| -### Using the IDE +### Using DevEco Studio -For details about how to start the IDE, see [IDE Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-openharmony-test-framework-0000001263160453#section1034420367508). +For details about how to use DevEco Studio to start the test framework, see [OpenHarmony Test Framework](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-openharmony-test-framework-0000001263160453#section1034420367508). ## Introduction to TestRunner -**TestRunner** is the entry class of the test framework test process. When the test process is started, the system calls related APIs in **TestRunner**. You need to inherit this class and override the **onPrepare** and **onRun** APIs. When creating an application template, the IDE initializes the default **TestRunner** and starts the default **TestAbility** in the **onRun** API. You can modify the test code of **TestAbility** or override **onPrepare** and **onRun** in **TestRunner** to implement your own test code. For details, see [TestRunner](../reference/apis/js-apis-testRunner.md). +**TestRunner** is the entry class of the test framework test process. When the test process is started, the system calls related APIs in **TestRunner**. You need to inherit this class and override the **onPrepare** and **onRun** APIs. When creating an application template, DevEco Studio initializes the default **TestRunner** and starts the default **TestAbility** in the **onRun** API. You can modify the test code of **TestAbility** or override **onPrepare** and **onRun** in **TestRunner** to implement your own test code. For details, see [TestRunner](../reference/apis/js-apis-testRunner.md). ## Introduction to AbilityMonitor -**AbilityMonitor** is provided by the test framework for binding to and listening for abilities. You can use **AbilityMonitor** to bind to an **Ability** instance and add **AbilityMonitor** to the listening list. After an ability is bound, the creation and lifecycle changes of the ability will trigger the related callback in **AbilityMonitor**. You can test and verify the ability in these callbacks. For details, see [AbilityMonitor](../reference/apis/js-apis-application-abilityMonitor.md). +**AbilityMonitor** is provided by the test framework for binding to and listening for abilities. You can use **AbilityMonitor** to bind to an **Ability** instance and add **AbilityMonitor** to the listening list. When **AbilityMonitor** is bound to an ability, the creation and lifecycle changes of the ability will trigger the related callback in **AbilityMonitor**. You can test and verify the ability in these callbacks. For details, see [AbilityMonitor](../reference/apis/js-apis-application-abilityMonitor.md). **Example** diff --git a/en/application-dev/ability/fa-brief.md b/en/application-dev/ability/fa-brief.md index db7346a6f4723cdf5589a8e5671944d95ea3878f..670c741d84218a261df7fa09d88e42c9b69a693f 100644 --- a/en/application-dev/ability/fa-brief.md +++ b/en/application-dev/ability/fa-brief.md @@ -32,4 +32,4 @@ Currently, the **app.js** file provides only the **onCreate** and **onDestroy** ## Process and Thread Model An application exclusively uses an independent process, and an ability exclusively uses an independent thread. An application process is created when an ability is started for the first time, and a thread is created for this ability too. After the application is started, other abilities in the application are started, and a thread is created for every of these started abilities. Each ability is bound to an independent JSRuntime instance. Therefore, abilities are isolated from each other. -![fa-threading-nodel](figures/fa-threading-model.png) +![fa-threading-model](figures/fa-threading-model.png) diff --git a/en/application-dev/ability/fa-pageability.md b/en/application-dev/ability/fa-pageability.md index e6c097d55d25d1717c342c847452b0a84baf0d83..2f0e8feb991316d640f70b8c2acd988701676807 100644 --- a/en/application-dev/ability/fa-pageability.md +++ b/en/application-dev/ability/fa-pageability.md @@ -2,13 +2,13 @@ ## Overview ### Concepts -The Page ability implements the ArkUI and provides the capability of interacting with developers. When you create an ability in the integrated development environment (IDE), the IDE automatically creates template code. The capabilities related to the Page ability are implemented through the **featureAbility**, and the lifecycle callbacks are implemented through the callbacks in **app.js/app.ets**. +The Page ability implements the ArkUI and provides the capability of interacting with developers. When you create an ability in DevEco Studio, DevEco Studio automatically creates template code. The capabilities related to the Page ability are implemented through the **featureAbility**, and the lifecycle callbacks are implemented through the callbacks in **app.js** or **app.ets**. ### Page Ability Lifecycle **Ability lifecycle** -The Page ability lifecycle is a general term for all states of a Page ability, such as **INACTIVE**, **ACTIVE**, and **BACKGROUND**. +The Page ability lifecycle defines all states of a Page ability, such as **INACTIVE**, **ACTIVE**, and **BACKGROUND**. The following figure shows the lifecycle state transition of the Page ability. @@ -17,25 +17,25 @@ The following figure shows the lifecycle state transition of the Page ability. Description of ability lifecycle states: - - **UNINITIALIZED**: The Page ability is not initialized. This is a temporary state. A Page ability changes directly to the **INITIAL** state upon its creation. + - **UNINITIALIZED**: The Page ability is not initialized. This is a temporary state, from which a Page ability changes directly to the **INITIAL** state upon its creation. - - **INITIAL**: This state refers to the initial or stopped state. The Page ability in this state is not running. The Page ability enters the **INACTIVE** state after it is started. + - **INITIAL**: The Page ability is initialized but not running. The Page ability enters the **INACTIVE** state after it is started. - - **INACTIVE**: The ability is visible but does not gain focus. + - **INACTIVE**: The Page ability is visible but does not gain focus. - - **ACTIVE**: The ability runs in the foreground and gains focus. + - **ACTIVE**: The Page ability runs in the foreground and has focus. - - **BACKGROUND**: The Page ability returns to the background. After being re-activated, the Page ability enters the **ACTIVE** state. After being destroyed, the Page ability enters the **INITIAL** state. + - **BACKGROUND**: The Page ability runs in the background. After being re-activated, the Page ability enters the **ACTIVE** state. After being destroyed, the Page ability enters the **INITIAL** state. **The following figure shows the relationship between lifecycle callbacks and lifecycle states of the Page ability.** ![fa-pageAbility-lifecycle](figures/fa-pageAbility-lifecycle.png) -You can override the lifecycle callbacks provided by the Page ability in the **app.js/app.ets** file. Currently, the **app.js** file provides only the **onCreate** and **onDestroy** callbacks, and the **app.ets** file provides the full lifecycle callbacks. +You can override the lifecycle callbacks provided by the Page ability in the **app.js** or **app.ets** file. Currently, the **app.js** file provides only the **onCreate** and **onDestroy** callbacks, and the **app.ets** file provides the full lifecycle callbacks. ### Launch Type The ability supports two launch types: singleton and multi-instance. -The **launchType** item in the **config.json** file is used to specify the launch type. +You can specify the launch type by setting **launchType** in the **config.json** file. | Launch Type | Description |Description | | ----------- | ------- |---------------- | @@ -55,7 +55,7 @@ By default, **singleton** is used. | void startAbility(parameter: StartAbilityParameter) | Starts an ability. | | Context getContext(): | Obtains the application context.| | void terminateSelf() | Terminates the ability. | -| bool hasWindowFocus() | Checks whether the ability gains focus. | +| bool hasWindowFocus() | Checks whether the ability has focus. | ### Starting a Local Page Ability @@ -227,15 +227,15 @@ In the cross-device scenario, the application must also apply for the data synch | API | Description | | ------------ | ------------------------------------------------------------ | | onShow() | Called when the ability is switched from the background to the foreground. In this case, the ability is visible to users.| -| onHide() | Called when the ability is switched from the foreground to the background. In this case, the ability is invisible.| -| onDestroy() | Called when the ability is destroyed. In this callback, you can make preparations for app exit, such as recycling resources and clearing the cache.| +| onHide() | Called when the ability is switched from the foreground to the background. In this case, the ability is invisible to users.| +| onDestroy() | Called when the ability is destroyed. In this callback, you can make preparations for application exit, such as recycling resources and clearing the cache.| | onCreate() | Called when the ability is created for the first time. You can initialize the application in this callback.| -| onInactive() | Called when the ability loses focus. An ability loses focus before entering the background state.| +| onInactive() | Called when the ability loses focus. An ability loses focus when it is about to enter the background state.| | onActive() | Called when the ability is switched to the foreground and gains focus. | **Example** -You need to override the lifecycle callbacks in **app.js/app.ets**. The IDE template generates **onCreate()** and **onDestroy()** by default. You need to override the other callbacks. +You need to override the lifecycle callbacks except **onCreate()** and **onDestroy()** in **app.js** or **app.ets**. The **onCreate()** and **onDestroy()** callbacks are automatically generated in the template code provided by DevEco Studio. ```javascript export default { diff --git a/en/application-dev/ability/fa-serviceability.md b/en/application-dev/ability/fa-serviceability.md index b00796a80dc05e961c74554b2e0ecd70c8b2ed35..3da62ebeb92859e586ff319cc70ebc5cf759ba80 100644 --- a/en/application-dev/ability/fa-serviceability.md +++ b/en/application-dev/ability/fa-serviceability.md @@ -5,7 +5,7 @@ A Service ability is used to run tasks in the background, such as playing music ## Available APIs -**Table 1** Service ability lifecycle callbacks +**Table 1** Service ability lifecycle APIs |API|Description| |:------|:------| |onStart|Called to initialize a Service ability being created. This callback is invoked only once in the entire lifecycle of a Service ability. The **Want** object passed to this callback must be null.| @@ -231,7 +231,7 @@ import prompt from '@system.prompt' let mRemote; function onConnectCallback(element, remote){ console.log('onConnectRemoteService onConnectDone element: ' + element); - console.log('onConnectRemotelService onConnectDone remote: ' + remote); + console.log('onConnectRemoteService onConnectDone remote: ' + remote); mRemote = remote; if (mRemote == null) { prompt.showToast({ diff --git a/en/application-dev/ability/stage-ability-continuation.md b/en/application-dev/ability/stage-ability-continuation.md index 9b14be35b075c0e053e81e22eb09bd8f4e4fa06d..0e070f2fee46ba41aa1f7c342b202010a9b58d10 100644 --- a/en/application-dev/ability/stage-ability-continuation.md +++ b/en/application-dev/ability/stage-ability-continuation.md @@ -174,7 +174,7 @@ The following table lists the APIs used for ability continuation. For details ab var g_object = distributedObject.createDistributedObject({name:undefined}); export default class MainAbility extends Ability { - contentStorage : ContenStorage + contentStorage : ContentStorage sessionId : string; onContinue(wantParam : {[key: string]: any}) { diff --git a/en/application-dev/ability/stage-serviceextension.md b/en/application-dev/ability/stage-serviceextension.md index af7b31cc116b3e5841e857887f93a04770410f39..90448c52428af38b8128477c24eec4911b88b827 100644 --- a/en/application-dev/ability/stage-serviceextension.md +++ b/en/application-dev/ability/stage-serviceextension.md @@ -82,6 +82,5 @@ The following sample is provided to help you better understand how to develop a - [ServiceExtensionAbility](https://gitee.com/openharmony/app_samples/tree/master/ability/ServiceExtAbility) -This sample shows how to: +This sample shows how to create a Service Extension ability in the **ServiceExtAbility.ts** file in the **ServiceExtensionAbility** directory. -Create a Service Extension ability in the **ServiceExtAbility.ts** file in the **ServiceExtensionAbility** directory. diff --git a/en/application-dev/ability/wantagent.md b/en/application-dev/ability/wantagent.md index f3c7f335468161795a9d436fe8b1d8eeb7aadce7..eacc92936960cca3bd022e6438a63c15a8f2688a 100644 --- a/en/application-dev/ability/wantagent.md +++ b/en/application-dev/ability/wantagent.md @@ -1,15 +1,15 @@ # WantAgent Development -### When to Use +## When to Use The **WantAgent** class encapsulates want information that specifies a particular action, which can be starting an ability or publishing a common event. You can either call **wantAgent.trigger** to trigger a **WantAgent** directly or add a **WantAgent** to a notification so that it will be triggered when users tap the notification. -### Available APIs +## Available APIs | API | Description| | ---------------------------------------------------------------------------------------------- | ----------- | | getWantAgentInfo(info: WantAgentInfo, callback: AsyncCallback\) | Creates a **WantAgent** object. This API uses an asynchronous callback to return the result.| | getWantAgent(info: WantAgentInfo): Promise\ | Creates a **WantAgent** object. This API uses a promise to return the result.| | trigger(agent: WantAgent, triggerInfo: TriggerInfo, callback?: Callback\) | Triggers a **WantAgent** object.| -### How to Develop +## How to Develop 1. Import the **WantAgent** module. ```