Skip to content

D
Docs

OpenHarmony / Docs
大约 1 年 前同步成功

通知 159
Star 292
Fork 28
D
Docs

体验新版 GitCode，发现更多精彩内容 >>

提交 8f4a12b2 编写于 作者: W wusongqing
浏览文件
操作

updated docs against master updates 

Signed-off-by: Nwusongqing <wusongqing@huawei.com>
上级 a4969725
隐藏空白更改
内联 并排
Showing with 75 addition and 73 deletion
zh-cn/application-dev/ability/ability-brief.md
浏览文件 @ 8f4a12b2
# Ability框架概述
​ Ability是应用所具备能力的抽象，也是应用程序的重要组成部分。Ability是系统调度应用的最小单元，是能够完成一个独立功能的组件，一个应用可以包含一个或多个Ability。
​ Ability是应用所具备能力的抽象，也是应用程序的重要组成部分。Ability是系统调度应用的最小单元，是能够完成一个独立功能的组件。一个应用可以包含一个或多个Ability。
​ Ability框架模型结构具有两种框架形态：
​ Ability框架模型具有两种形态：
- 第一种形态为FA模型。API 8及其更早版本的应用程序只能使用FA模型进行开发。 FA模型将Ability分为FA（Feature Ability）和PA（Particle Ability）两种类型，其中FA支持Page Ability，PA支持Service Ability、Data Ability、以及FormAbility。
- 第二种形态为Stage模型。从API 9开始，Ability框架引入了Stage模型作为第二种应用框架形态，Stage模型将Ability分为Ability和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等等一系列ExtensionAbility，以便满足更多的使用场景。
- 第二种形态为Stage模型。从API 9开始，Ability框架引入了Stage模型作为第二种应用框架形态，Stage模型将Ability分为Ability和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等一系列ExtensionAbility，以便满足更多的使用场景。
​ Stage模型的设计，主要是为了方便开发者更加方便地开发出分布式环境下的复杂应用。下表给出了两种模型在设计上的差异：
​ Stage模型的设计，主要是为了开发者更加方便地开发出分布式环境下的复杂应用。下表给出了两种模型在设计上的差异：
| 对比 | FA模型 | Stage模型 |
| -------------- | ------------------------------------------------------------ | -------------------------------------------------------- |
| 开发方式 | 提供类Web的 api，UI开发与Stage模型一致。 | 提供面向对象的开发方式，UI开发与FA模型一致。 |
| 引擎实例 | 每个进程内的每个Ability独享一个JS VM引擎实例。 | 每个进程内的多个Ability实例共享一个JS VM引擎实例。 |
| 开发方式 | 提供类Web的API，UI开发与Stage模型一致。 | 提供面向对象的开发方式，UI开发与FA模型一致。 |
| 引擎实例 | 每个进程内的每个Ability实例独享一个JS VM引擎实例。 | 每个进程内的多个Ability实例共享一个JS VM引擎实例。 |
| 进程内对象共享 | 不支持。 | 支持。 |
| 包描述文件 | 使用config.json描述HAP包和组件信息，组件必须使用固定的文件名。 | 使用module.json描述HAP包和组件信息，可以指定入口文件名。 |
| 组件 | 提供PageAbility(页面展示)，ServiceAbility(服务)，DataAbility(数据分享), FormAbility(卡片)。 | 提供Ability(页面展示)、Extension(基于场景的服务扩展)。 |
| 组件 | 提供PageAbility(页面展示)，ServiceAbility(服务)，DataAbility(数据分享)以及FormAbility(卡片)。 | 提供Ability(页面展示)、Extension(基于场景的服务扩展)。 |
​ 除了上述设计上的差异外，对于开发者而言，两种模型的主要区别在于：
......
zh-cn/application-dev/ability/ability-delegator.md
浏览文件 @ 8f4a12b2
# 测试框架使用指导
## 概述
Delegator测试框架是OpenHarmony提供的一套开发者应用自测试框架，旨在为开发者提供针对应用的自测试环境。开发者可以通过delegator类启动对应Ability，并通过Delegator类提供的能力对Ability进行生命周期切换和监听，同时支持shellCMD输入和测试结果打印显示等功能。
Delegator测试框架是OpenHarmony提供的一套开发者应用自测试框架，旨在为开发者提供针对应用的自测试环境。开发者可以通过Delegator类启动对应Ability，并通过Delegator类提供的能力对Ability进行生命周期切换和监听，同时支持shellCMD输入和测试结果打印显示等功能。
## 约束与限制
测试框架相关接口只能在测试hap包中使用，只有通过`aa test`命令或者IDE启动测试环境后相关接口才能生效。
测试框架相关接口只能在测试hap包中使用，只有通过`aa test`命令或者DevEco Studio启动测试环境后相关接口才能生效。
## 测试框架启动
......@@ -13,11 +13,11 @@ Delegator测试框架是OpenHarmony提供的一套开发者应用自测试框架
测试框架启动有两种方式：
- 方式一：通过`aa test`命令启动。
- 方式二：通过IDE启动。
- 方式二：通过DevEco Studio启动。
### aa test启动
开发者可通过 `aa test` 命令启动启动测试框架，开发者可以自行指定使用的runner以及runner所在hap包的package name/module name，具体命令示例如下:
开发者可通过 `aa test` 命令启动测试框架，开发者可以自行指定使用的TestRunner以及TestRunner所在hap包的package name或module name，具体命令示例如下:
**FA模型：**
......@@ -40,25 +40,25 @@ aa test -b BundleName -m com.example.myapplicationfaets -s unittest OpenHarmonyT
| -D | 否 | 以Debug模式启动被测试应用。 |
| -h | 否 | 输出帮助信息。 |
### IDE启动
### DevEco Studio启动
IDE启动相关介绍见 [IDE指导网址](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-openharmony-test-framework-0000001263160453#section1034420367508)。
DevEco Studio启动相关介绍见 [OpenHarmony测试框架](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-openharmony-test-framework-0000001263160453#section1034420367508)。
## TestRunner介绍
TestRunner是测试框架测试流程入口类，当测试流程启动时，系统会调用TestRunner内相关接口，开发者需要派生该类，并重写onPrepare、onRun方法。IDE在创建应用模板时会初始化一个默认TestRunner，并在onRun方法启动默认的TestAbility。开发者也可以修改TestAbility测试代码内容，也可以修改默认的TestRunner内onPrepare、onRun方法，自行实现测试代码。具体详细内容请参考TestRunnerAPI接口说明[TestRunner](../reference/apis/js-apis-testRunner.md)。
TestRunner是测试框架测试流程入口类。当测试流程启动时，系统会调用TestRunner内相关接口，开发者需要派生该类，并重写onPrepare、onRun方法。DevEco Studio在创建应用模板时会初始化一个默认TestRunner，并在onRun方法启动默认的TestAbility。开发者也可以修改TestAbility测试代码内容，也可以修改默认的TestRunner内onPrepare、onRun方法，自行实现测试代码。具体详细内容请参考TestRunnerAPI接口说明[TestRunner](../reference/apis/js-apis-testRunner.md)。
## AbilityDelegatorRegistry介绍
AbilityDelegatorRegistry是测试框架提供的AbilityDelegator仓库类，开发者可以使用AbilityDelegatorRegistry获取AbilityDelegator实例以及执行此次测试时传入和生成的相关参数AbilityDelegatorArgs。开发者可以使用AbilityDelegator调用测试框架提供的函数集进行测试验证。具体详细内容请参考AbilityDelegatorRegistry API接口说明[AbilityDelegatorRegistry](../reference/apis/js-apis-abilityDelegatorRegistry.md)。
AbilityDelegatorRegistry是测试框架提供的AbilityDelegator仓库类。开发者可以使用AbilityDelegatorRegistry获取AbilityDelegator实例以及执行此次测试时传入和生成的相关参数AbilityDelegatorArgs。开发者可以使用AbilityDelegator调用测试框架提供的函数集进行测试验证。具体详细内容请参考AbilityDelegatorRegistry API接口说明[AbilityDelegatorRegistry](../reference/apis/js-apis-abilityDelegatorRegistry.md)。
## AbilityDelegatorArgs介绍
AbilityDelegatorArgs是测试框架提供的测试参数类，开发者可以使用AbilityDelegatorArgs获取执行此次测试时传入和生成的相关参数。具体详细内容请参考AbilityDelegatorArgs API接口说明[AbilityDelegatorArgs](../reference/apis/js-apis-application-abilityDelegatorArgs.md)。
AbilityDelegatorArgs是测试框架提供的测试参数类。开发者可以使用AbilityDelegatorArgs获取执行此次测试时传入和生成的相关参数。具体详细内容请参考AbilityDelegatorArgs API接口说明[AbilityDelegatorArgs](../reference/apis/js-apis-application-abilityDelegatorArgs.md)。
## AbilityMonitor介绍
AbilityMonitor是测试框架提供用来绑定并监听Ability类，开发者可以使用AbilityMonitor绑定Ability，并将AbilityMonitor添加到监听列表。绑定后Ability的创建、生命周期变化等会触发AbilityMonitor内相关回调函数，开发者可以在对应回调函数内进行测试验证。具体详细内容请参考AbilityMonitor API接口说明[AbilityMonitor](../reference/apis/js-apis-application-abilityMonitor.md)。
AbilityMonitor是测试框架提供用来绑定并监听Ability类。开发者可以使用AbilityMonitor绑定Ability，并将AbilityMonitor添加到监听列表。绑定后Ability的创建、生命周期变化等会触发AbilityMonitor内相关回调函数，开发者可以在对应回调函数内进行测试验证。具体详细内容请参考AbilityMonitor API接口说明[AbilityMonitor](../reference/apis/js-apis-application-abilityMonitor.md)。
**示例**
......
zh-cn/application-dev/ability/fa-brief.md
浏览文件 @ 8f4a12b2
......@@ -32,11 +32,12 @@ Ability框架在API 8及更早版本使用FA模型。FA模型中Ability分为Pag
## 进程线程模型
应用独享独立进程，Ability独享独立线程，应用进程在Ability第一次启动时创建，并为启动的Ability创建线程，应用启动后再启动应用内其他Ability，会为每一个Ability创建相应的线程。每个Ability绑定一个独立的JSRuntime实例，因此Ability之间是隔离的。
![fa-threading-nodel](figures/fa-threading-model.png)
![fa-threading-model](figures/fa-threading-model.png)
## 相关实例
针对Ability开发，有以下相关实例可供参考：
- [`DistributeCalc`：分布式计算器（eTS）（API8）](https://gitee.com/openharmony/app_samples/tree/master/Preset/DistributeCalc)
- [`DistributeGraffti`：分布式涂鸦（eTS）（API8）](https://gitee.com/openharmony/app_samples/tree/master/ability/DistributedGraffiti)
- [`DistributeGraffiti`：分布式涂鸦（eTS）（API8）](https://gitee.com/openharmony/app_samples/tree/master/ability/DistributedGraffiti)
- [分布式调度启动远程FA](https://gitee.com/openharmony/codelabs/tree/master/Distributed/RemoteStartFA)
- [分布式新闻客户端](https://gitee.com/openharmony/codelabs/tree/master/Distributed/NewsDemo)
- [分布式手写板（eTS）](https://gitee.com/openharmony/codelabs/tree/master/Distributed/DistributeDatabaseDrawEts)
......
zh-cn/application-dev/ability/fa-dataability.md
浏览文件 @ 8f4a12b2
......@@ -6,7 +6,7 @@ Data提供方可以自定义数据的增、删、改、查，以及文件打开
## 接口说明
**表1** Data中相关生命周期功能介绍
**表1** Data中相关生命周期API功能介绍
|接口名|描述|
|:------|:------|
|onInitialized?(info: AbilityInfo): void|在Ability初始化调用，通过此回调方法执行RDB等初始化操作。|
......@@ -14,13 +14,13 @@ Data提供方可以自定义数据的增、删、改、查，以及文件打开
|query?(uri: string, columns: Array\<string>, predicates: dataAbility.DataAbilityPredicates, callback: AsyncCallback\<ResultSet>): void|查询数据库中的数据。|
|delete?(uri: string, predicates: dataAbility.DataAbilityPredicates, callback: AsyncCallback\<number>): void|删除一条或多条数据。|
|normalizeUri?(uri: string, callback: AsyncCallback\<string>): void|对URI进行规范化。一个规范化的URI可以支持跨设备使用、持久化、备份和还原等，当上下文改变时仍然可以引用到相同的数据项。|
|batchInsert?(uri: string, valueBuckets: Array<rdb.ValuesBucket>, callback: AsyncCallback\<number>): void|向数据库中插入多条数据。|
|batchInsert?(uri: string, valueBuckets: Array\<rdb.ValuesBucket>, callback: AsyncCallback\<number>): void|向数据库中插入多条数据。|
|denormalizeUri?(uri: string, callback: AsyncCallback\<string>): void|将一个由normalizeUri生产的规范化URI转换成非规范化的URI。|
|insert?(uri: string, valueBucket: rdb.ValuesBucket, callback: AsyncCallback\<number>): void|向数据中插入一条数据。|
|openFile?(uri: string, mode: string, callback: AsyncCallback\<number>): void|打开一个文件。|
|getFileTypes?(uri: string, mimeTypeFilter: string, callback: AsyncCallback<Array\<string>>): void|获取文件的MIME类型。|
|getType?(uri: string, callback: AsyncCallback\<string>): void|获取URI指定数据相匹配的MIME类型。|
|executeBatch?(ops: Array\<DataAbilityOperation>, callback: AsyncCallback<Array\<DataAbilityResult>>): void|批量操作数据库中的数据。|
|executeBatch?(ops: Array\<DataAbilityOperation>, callback: AsyncCallback\<Array\<DataAbilityResult>>): void|批量操作数据库中的数据。|
|call?(method: string, arg: string, extras: PacMap, callback: AsyncCallback\<PacMap>): void|自定义方法。|
......
zh-cn/application-dev/ability/fa-formability.md
浏览文件 @ 8f4a12b2
......@@ -59,7 +59,7 @@ FormProvider类具体的API详见[接口文档](../reference/apis/js-apis-formpr
创建FA模型的卡片，需实现LifecycleForm的生命周期接口。具体示例代码如下：
1. 导入相关模块
1. 导入相关模块。
```javascript
import formBindingData from '@ohos.application.formBindingData'
......@@ -67,7 +67,7 @@ FormProvider类具体的API详见[接口文档](../reference/apis/js-apis-formpr
import formProvider from '@ohos.application.formProvider'
```
2. 实现LifecycleForm生命周期接口
2. 实现LifecycleForm生命周期接口。
```javascript
export default {
......@@ -86,7 +86,7 @@ FormProvider类具体的API详见[接口文档](../reference/apis/js-apis-formpr
console.log('FormAbility onCastToNormal');
},
onUpdate(formId) {
// 若卡片支持定时更新/定点更新/卡片使用方主动请求更新功能，则提供方需要覆写该方法以支持数据更新
// 若卡片支持定时更新/定点更新/卡片使用方主动请求更新功能，则提供方需要重写该方法以支持数据更新
console.log('FormAbility onUpdate');
let obj = {
"title": "titleOnUpdate",
......@@ -102,7 +102,7 @@ FormProvider类具体的API详见[接口文档](../reference/apis/js-apis-formpr
console.log('FormAbility onVisibilityChange');
},
onEvent(formId, message) {
// 若卡片支持触发事件，则需要覆写该方法并实现对事件的触发
// 若卡片支持触发事件，则需要重写该方法并实现对事件的触发
console.log('FormAbility onEvent');
},
onDestroy(formId) {
......@@ -219,7 +219,7 @@ FormProvider类具体的API详见[接口文档](../reference/apis/js-apis-formpr
}
```
且需要适配onDestroy卡片删除通知接口，在其中实现卡片实例数据的删除。
同时需要适配onDestroy卡片删除通知接口，在其中实现卡片实例数据的删除。
```javascript
onDestroy(formId) {
......@@ -235,9 +235,9 @@ FormProvider类具体的API详见[接口文档](../reference/apis/js-apis-formpr
需要注意的是，卡片使用方在请求卡片时传递给提供方应用的Want数据中存在临时标记字段，表示此次请求的卡片是否为临时卡片：
常态卡片：卡片使用方会持久化的卡片；
- 常态卡片：卡片使用方会持久化的卡片；
临时卡片：卡片使用方不会持久化的卡片；
- 临时卡片：卡片使用方不会持久化的卡片；
由于临时卡片的数据具有非持久化的特殊性，某些场景比如卡片服务框架死亡重启，此时临时卡片数据在卡片管理服务中已经删除，且对应的卡片ID不会通知到提供方，所以卡片提供方需要自己负责清理长时间未删除的临时卡片数据。同时对应的卡片使用方可能会将之前请求的临时卡片转换为常态卡片。如果转换成功，卡片提供方也需要对对应的临时卡片ID进行处理，把卡片提供方记录的临时卡片数据转换为常态卡片数据，防止提供方在清理长时间未删除的临时卡片时，把已经转换为常态卡片的临时卡片信息删除，导致卡片信息丢失。
......@@ -343,7 +343,7 @@ onUpdate(formId) {
}
```
最终可以得到，如下卡片：
最终可以得到如下卡片：
![fa-form-example](figures/fa-form-example.png)
......
zh-cn/application-dev/ability/fa-pageability.md
浏览文件 @ 8f4a12b2
......@@ -31,7 +31,7 @@ PageAbility生命周期流转如下图所示：
![fa-pageAbility-lifecycle](figures/fa-pageAbility-lifecycle.png)
PageAbility提供命周期回调，开发者可以在`app.js/app.ets`中重写生命周期相关回调函数 。目前`app.js`环境中仅支持onCreate和onDestroy回调，`app.ets`环境支持全量生命周期回调。
PageAbility提供生命周期回调，开发者可以在`app.js/app.ets`中重写生命周期相关回调函数 。目前`app.js`环境中仅支持onCreate和onDestroy回调，`app.ets`环境支持全量生命周期回调。
### 启动模式
ability支持单实例和多实例两种启动模式。
......
zh-cn/application-dev/ability/fa-serviceability.md
浏览文件 @ 8f4a12b2
......@@ -5,7 +5,7 @@
## 接口说明
**表1** Service中相关生命周期功能介绍
**表1** Service中相关生命周期API功能介绍
|接口名|描述|
|:------|:------|
|onStart|该方法在创建Service的时候调用，用于Service的初始化。在Service的整个生命周期只会调用一次，调用时传入的Want应为空。|
......@@ -18,7 +18,7 @@
### 创建Service
1. Service也是一种Ability，Ability为Service提供了以下生命周期方法，开发者可以重写这些方法，来添加其他Ability请求与Service Ability交互时的处理方法。
1. 重写Service的生命周期方法，来添加其他Ability请求与Service Ability交互时的处理方法。
创建Service的代码示例如下：
......@@ -45,7 +45,7 @@
2. 注册Service。
Service也需要在应用配置文件config.json中进行注册，注册类型type需要设置为service。
Service需要在应用配置文件config.json中进行注册，注册类型type需要设置为service。
```javascript
{
......@@ -168,7 +168,7 @@ let connId = featureAbility.connectAbility(
);
```
同时，Service侧也需要在onConnect()时返回IRemoteObject，从而定义与Service进行通信的接口。onConnect()需要返回一个IRemoteObject对象，OpenHarmony提供了IRemoteObject的默认实现，用户可以通过继承rpc.RemoteObject来创建自定义的实现类。
同时，Service侧也需要在onConnect()时返回IRemoteObject，从而定义与Service进行通信的接口。onConnect()需要返回一个IRemoteObject对象。OpenHarmony提供了IRemoteObject的默认实现，开发者可以通过继承rpc.RemoteObject来创建自定义的实现类。
Service侧把自身的实例返回给调用侧的代码示例如下：
......@@ -217,7 +217,8 @@ export default {
```
### 连接远程Service<a name="section126857614019"></a>（当前仅对系统应用开放）
>说明：由于DeviceManager的getTrustedDeviceListSync接口仅对系统应用开放，当前连接远程Service仅支持系统应用
>说明：由于DeviceManager的getTrustedDeviceListSync接口仅对系统应用开放，当前连接远程Service仅支持系统应用。
如果Service需要与Page Ability或其他应用的Service Ability进行跨设备交互，则须创建用于连接的Connection。Service支持其他Ability通过connectAbility()方法与其进行跨设备连接。
......@@ -231,7 +232,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({
......@@ -340,7 +341,7 @@ async function RequestPermission() {
}
```
同时，Service侧也需要在onConnect()时返回IRemoteObject，从而定义与Service进行通信的接口。onConnect()需要返回一个IRemoteObject对象，OpenHarmony提供了IRemoteObject的默认实现，用户可以通过继承rpc.RemoteObject来创建自定义的实现类。
同时，Service侧也需要在onConnect()时返回IRemoteObject，从而定义与Service进行通信的接口。onConnect()需要返回一个IRemoteObject对象。OpenHarmony提供了IRemoteObject的默认实现，开发者可以通过继承rpc.RemoteObject来创建自定义的实现类。
Service侧把自身的实例返回给调用侧的代码示例如下：
......
zh-cn/application-dev/ability/stage-brief.md
浏览文件 @ 8f4a12b2
# Stage模型综述
### 设计思想
## 设计思想
​ Stage模型的设计，主要是为了解决FA模型无法解决的开发场景问题，方便开发者更加方便地开发出分布式环境下的复杂应用。
......@@ -23,7 +23,7 @@
​ 为了支持多种设备形态和更易于实现多种不同的窗口形态，需要组件管理服务和窗口管理服务在架构层面上是解耦的，从而方便裁剪，更有利于定制不同的窗口形态。Stage模型通过重新定义了Ability生命周期定义和设计组件管理服务和窗口管理服务的单向依赖解决这一问题。
### 基本概念
## 基本概念
​ 下图展示了Stage模型中的基本概念。
......@@ -38,10 +38,10 @@
- **ExtensionAbility**：基于场景的服务扩展能力统称，系统定义了多种基于场景的ExtensionAbility类，它们持有各自的ExtensionContext;
- **WindowStage**：本地窗口管理器；
- **Window**：窗口 管理器管理的基本单元，持有一个ArkUI引擎实例；
- **Ark UI Page**：Ark声明式UI展示。
- **ArkUI Page**：方舟开发框架页面。
### 生命周期
## 生命周期
​ Ability及AbilityStage的生命周期是应用的基本流程中最重要的概念。在[Ability框架概述](ability-brief.md)中，给出了FA模型与Stage模型的生命周期对比，这里重点对Ability生命周期切换以及和AbilityStage、WindowStage之间的调度关系进行介绍。
......@@ -50,7 +50,7 @@
​ 为了实现多设备形态上的裁剪和多窗口的可扩展性，OpenHarmony对组件管理和窗口管理进行了解耦。Stage模型定义Ability组件的生命周期，只包含创建、销毁、前后台等状态，而将与界面相关内容强相关的获焦、失焦状态放在WindowStage之中，从而实现Ability与窗口之间的弱耦合；在服务侧，窗口管理服务依赖于组件管理服务，前者通知后者前后台变化，这样组件管理服务仅感知前后台变化，不感知焦点变化。
### Ability组件实例与任务
## Ability组件实例与任务
​ Ability组件有三种启动类型：
......@@ -66,7 +66,7 @@
![AbilityComponentInstanceMission](figures/AbilityComponentInstanceMission.png)
### ExtensionAbility机制
## ExtensionAbility机制
​ 不同于用于页面展示的Ability，ExtensionAbility提供的是一种受限的服务运行环境。ExtensionAbility具有如下特点：
......@@ -82,7 +82,7 @@
![ExtensionAbility](figures/ExtensionAbility.png)
### 进程模型
## 进程模型
​ OpenHarmony系统中的应用均满足单进程模型。所谓的单进程模型，是指不允许应用配置多进程，应用中所有的进程都是由系统创建和管理的。每个应用至多并存三类进程：
......
zh-cn/application-dev/ability/stage-call.md
浏览文件 @ 8f4a12b2
# Call调用开发指导
## 场景介绍
Ability Call调用是Ability能力的扩展，它为Ability提供一种能够被外部调用的能力。使Ability既能被拉起到前台展示UI，也支持Ability在后台被创建并运行。应用开发者可通过Call调用，使用IPC通信实现不同Ability之间的数据共享。Call调用的场景主要包括：
Ability Call调用是Ability能力的扩展，它为Ability提供一种能够被外部调用的能力，使Ability既能被拉起到前台展示UI，也支持Ability在后台被创建并运行。应用开发者可通过Call调用，使用IPC通信实现不同Ability之间的数据共享。Call调用的场景主要包括：
- 创建Callee被调用端。
- 访问Callee被调用端。
......@@ -37,7 +37,7 @@ Callee被调用端，需要实现指定方法的数据接收回调函数、数
|Json字段|字段说明|
|:------|:------|
|"launchType"|Ability的启动模式，设置为"singleton"类型 |
|"launchType"|Ability的启动模式，设置为"singleton"类型。 |
Ability配置标签示例如下：
```json
......@@ -51,11 +51,11 @@ Ability配置标签示例如下：
"visible": true
}]
```
2. 导入Ability模块
2. 导入Ability模块。
```
import Ability from '@ohos.application.Ability'
```
3. 定义约定的序列化数据
3. 定义约定的序列化数据。
调用端及被调用端发送接收的数据格式需协商一致，如下示例约定数据由number和string组成。具体示例代码如下：
```ts
......@@ -81,9 +81,9 @@ export default class MySequenceable {
}
}
```
4. 实现Callee.on监听及Callee.off解除监听
4. 实现Callee.on监听及Callee.off解除监听。
被调用端Callee的监听函数注册时机, 取决于应用开发者。注册监听之前的数据不会被处理，取消监听之后的数据不会被处理。如下示例在Ability的onCreate注册'CalleeSortMethod'监听，在onDestroy取消监听，收到序列化数据后作相应处理并返回，应用开发者根据实际需要做相应处理。具体示例代码如下：
被调用端Callee的监听函数注册时机, 取决于应用开发者。注册监听之前的数据不会被处理，取消监听之后的数据不会被处理。如下示例在Ability的onCreate注册'MSG_SEND_METHOD'监听，在onDestroy取消监听，收到序列化数据后作相应处理并返回，应用开发者根据实际需要做相应处理。具体示例代码如下：
```ts
const TAG: string = '[CalleeAbility]'
const MSG_SEND_METHOD: string = 'CallSendMsg'
......@@ -121,11 +121,11 @@ export default class CalleeAbility extends Ability {
```
### 访问Callee被调用端
1. 导入Ability模块
1. 导入Ability模块。
```
import Ability from '@ohos.application.Ability'
```
2. 获取Caller通信接口
2. 获取Caller通信接口。
Ability的context属性实现了startAbilityByCall方法，用于获取指定通用组件的Caller通信接口。如下示例通过`this.context`获取Ability实例的context属性，使用startAbilityByCall拉起Callee被调用端并获取Caller通信接口，注册Caller的onRelease监听。应用开发者根据实际需要做相应处理。具体示例代码如下：
```ts
......@@ -148,7 +148,7 @@ async onButtonGetCaller() {
console.error(TAG + 'get caller failed with ' + error)
})
```
在跨设备场景下，需指定对端设备deviceId。具体示例代码如下：
在跨设备场景下，需指定对端设备deviceId。具体示例代码如下：
```ts
let TAG = '[MainAbility] '
var caller = undefined
......@@ -172,7 +172,7 @@ context.startAbilityByCall({
console.error(TAG + 'get remote caller failed with ' + error)
})
```
从DeviceManager获取指定设备的deviceId，getTrustedDeviceListSync接口仅对系统应用开放。具体示例代码如下：
从DeviceManager获取指定设备的deviceId，getTrustedDeviceListSync接口仅对系统应用开放。具体示例代码如下：
```ts
import deviceManager from '@ohos.distributedHardware.deviceManager';
var dmClass;
......@@ -190,7 +190,7 @@ function getRemoteDeviceId() {
}
}
```
在跨设备场景下，需要向用户申请数据同步的权限。具体示例代码如下：
在跨设备场景下，需要向用户申请数据同步的权限。具体示例代码如下：
```ts
let context = this.context
let permissions: Array<string> = ['ohos.permission.DISTRIBUTED_DATASYNC']
......@@ -215,7 +215,7 @@ async onButtonCall() {
}
```
如下示例调用CallWithResult接口，向Callee被调用端发送待处理的数据`originMsg`，并将'CallSendMsg'方法处理完毕的数据赋值给`backMsg`。具体示例代码如下：
如下示例调用CallWithResult接口，向Callee被调用端发送待处理的数据`originMsg`，并将'CallSendMsg'方法处理完毕的数据赋值给`backMsg`。具体示例代码如下：
```ts
const MSG_SEND_METHOD: string = 'CallSendMsg'
originMsg: string = ''
......
zh-cn/application-dev/ability/stage-formextension.md
浏览文件 @ 8f4a12b2
......@@ -98,7 +98,7 @@ FormProvider类具体的API介绍详见[接口文档](../reference/apis/js-apis-
console.log('FormAbility onCastToNormal');
}
onUpdate(formId) {
// 若卡片支持定时更新/定点更新/卡片使用方主动请求更新功能，则提供方需要覆写该方法以支持数据更新
// 若卡片支持定时更新/定点更新/卡片使用方主动请求更新功能，则提供方需要重写该方法以支持数据更新
console.log('FormAbility onUpdate');
let obj = {
"title": "titleOnUpdate",
......@@ -114,7 +114,7 @@ FormProvider类具体的API介绍详见[接口文档](../reference/apis/js-apis-
console.log('FormAbility onVisibilityChange');
}
onEvent(formId, message) {
// 若卡片支持触发事件，则需要覆写该方法并实现对事件的触发
// 若卡片支持触发事件，则需要重写该方法并实现对事件的触发
console.log('FormAbility onEvent');
}
onDestroy(formId) {
......@@ -246,9 +246,9 @@ FormProvider类具体的API介绍详见[接口文档](../reference/apis/js-apis-
需要注意的是，卡片使用方在请求卡片时传递给提供方应用的Want数据中存在临时标记字段，表示此次请求的卡片是否为临时卡片：
常态卡片：卡片使用方会持久化的卡片；
- 常态卡片：卡片使用方会持久化的卡片；
临时卡片：卡片使用方不会持久化的卡片；
- 临时卡片：卡片使用方不会持久化的卡片；
由于临时卡片的数据具有非持久化的特殊性，某些场景比如卡片服务框架死亡重启，此时临时卡片数据在卡片管理服务中已经删除，且对应的卡片ID不会通知到提供方，所以卡片提供方需要自己负责清理长时间未删除的临时卡片数据。同时对应的卡片使用方可能会将之前请求的临时卡片转换为常态卡片。如果转换成功，卡片提供方也需要对对应的临时卡片ID进行处理，把卡片提供方记录的临时卡片数据转换为常态卡片数据，防止提供方在清理长时间未删除的临时卡片时，把已经转换为常态卡片的临时卡片信息删除，导致卡片信息丢失。
......
zh-cn/application-dev/ability/stage-serviceextension.md
浏览文件 @ 8f4a12b2
......@@ -7,7 +7,7 @@ ExtensionAbility，是Stage模型中新增的扩展组件的基类，一般用
## 接口说明
**表1** ServiceExtensionAbility中相关生命周期功能介绍
**表1** ServiceExtensionAbility中相关生命周期API功能介绍
|接口名|描述|
|:------|:------|
|onCreate|首次调用startAbility、connectAbility时触发，开发者可以进行初始化操作。|
......
zh-cn/application-dev/ability/wantagent.md
浏览文件 @ 8f4a12b2
# WantAgent开发指导
### 场景简介
## 场景简介
WantAgent封装了一个行为意图信息，可以通过WantAgent.trigger接口主动触发，也可以通过与通知绑定被动触发。
具体的行为包括：启动Ability和发布公共事件。
### 接口说明
## 接口说明
| 接口名 | 接口描述 |
| ---------------------------------------------------------------------------------------------- | ----------- |
| getWantAgentInfo(info: WantAgentInfo, callback: AsyncCallback\<WantAgent\>) | 以AsyncCallback形式创建WantAgent对象 |
| getWantAgent(info: WantAgentInfo): Promise\<WantAgent\> | 以Promise形式创建WantAgent对象 |
| trigger(agent: WantAgent, triggerInfo: TriggerInfo, callback?: Callback\<CompleteData\>) | 触发WantAgent |
| getWantAgentInfo(info: WantAgentInfo, callback: AsyncCallback\<WantAgent\>) | 以异步回调形式创建WantAgent对象。 |
| getWantAgent(info: WantAgentInfo): Promise\<WantAgent\> | 以Promise形式创建WantAgent对象。 |
| trigger(agent: WantAgent, triggerInfo: TriggerInfo, callback?: Callback\<CompleteData\>) | 触发WantAgent。 |
### 开发步骤
## 开发步骤
1. 导入WantAgent模块。
```
import wantAgent from '@ohos.wantAgent';
```
2. 创建拉起Ability的WantAgentInfo信息，详细的WantAgentInfo信息数据类型及包含的参数请见[WantAgentInfo文档](../reference/apis/js-apis-wantAgent.md#wantagentinfo)介绍。
2. 创建拉起Ability的WantAgentInfo信息。详细的WantAgentInfo信息数据类型及包含的参数请见[WantAgentInfo文档](../reference/apis/js-apis-wantAgent.md#wantagentinfo)介绍。
```
private wantAgentObj = null //用于保存创建成功的wantAgent对象，后续使用其完成触发的动作。
......@@ -42,7 +42,7 @@ WantAgent封装了一个行为意图信息，可以通过WantAgent.trigger接口
}
```
3. 创建发布公共事件的WantAgentInfo信息
3. 创建发布公共事件的WantAgentInfo信息。
```
private wantAgentObj = null //用于保存创建成功的WantAgent对象，后续使用其完成触发的动作。
......@@ -51,7 +51,7 @@ WantAgent封装了一个行为意图信息，可以通过WantAgent.trigger接口
var wantAgentInfo = {
wants: [
{
action: "event_name", // 设置事件名
action: "event_name", // 设置事件名。
parameters: {}
}
],
......@@ -75,10 +75,10 @@ WantAgent封装了一个行为意图信息，可以通过WantAgent.trigger接口
})
```
5. 触发WantAgent
5. 触发WantAgent。
```
//触发WantAgent
//触发WantAgent。
var triggerInfo = {
code:0
}
......
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或