@@ -100,7 +100,7 @@ Enumerates the types of Extension abilities.
| Name| Value| Description|
|:----------------:|:---:|-----|
| FORM | 0 | [FormExtensionAbility](../../application-models/service-widget-overview.md): provides APIs for widget development.|
| WORK_SCHEDULER | 1 | [WorkSchedulerExtensionAbility](../../task-management/work-scheduler.md): enables applications to execute non-real-time tasks when the system is idle.|
| WORK_SCHEDULER | 1 | [WorkSchedulerExtensionAbility](../../task-management/work-scheduler.md): enables applications to execute non-real-time tasks when the system is idle.|
| SERVICE | 3 | [ServiceExtensionAbility](../../application-models/serviceextensionability.md): enables applications to run in the background and provide services.|
| ACCESSIBILITY | 4 | [AccessibilityExtensionAbility](js-apis-application-accessibilityExtensionAbility.md): provides accessibility for access to and operations on the UI.|
...
...
@@ -116,7 +116,6 @@ Enumerates the types of Extension abilities.
| PRINT<sup>10+</sup> | 15 | PrintExtensionAbility: provides APIs for printing images. Printing documents is not supported yet.|
| PUSH<sup>10+</sup> | 17 | PushExtensionAbility: provides APIs for pushing scenario-specific messages. This ability is reserved.|
| DRIVER<sup>10+</sup> | 18 | DriverExtensionAbility: provides APIs for the peripheral driver. This type of ability is not supported yet.|
| APP_ACCOUNT_AUTHORIZATION<sup>10+</sup> | 19 | [AuthorizationExtensionAbility](js-apis-appAccount-authorizationExtensionAbility.md): provides APIs to process authorization requests for application accounts and allow account authorization from a third-party (relative to the operating system vendor) ecosystem platform.|
| UNSPECIFIED | 255 | No type is specified. It is used together with **queryExtensionAbilityInfo** to query all types of Extension abilities.|
| 1 | Customer-oriented mindset | **Stand in the shoes of developers and provide the use cases, parameter selection principles, recommendations/tips, sample code, and anything else that a developer will need to develop the API.**|
| 2 | Upload path | Upload markdown files to **docs/en/application-dev/reference/apis**.<br>Upload images to **docs/en/application-dev/reference/apis/figures**. In addition, reference the image path in the markdown file as follows: ****, ****, or ****.|
| 2 | Upload path | Upload markdown files to **docs/en/application-dev/reference/apis**.<br>Upload images to **docs/en/application-dev/reference/apis/figures**. In addition, reference the image path in the markdown file as follows: **\![]\(figures/exampleImage.jpg)**, **\![]\(figures/exampleImage.png)**, or **\![]\(figures/exampleImage.gif)**.|
| 3 | File name | Provide one JS API reference document for each d.ts file. Name the file in the format of **js-apis-exampleModule.md**, where **exampleModule** is a variable and must be the same as the actual module name.<br>Examples:<br>For @ohos.multimedia.audio in the Multimedia subsystem, the JS API file name is **js-apis-audio.md**.<br>For @ohos.telephony.sms in the Telephony subsystem, the JS API file name is **js-apis-sms.md**.|
| 4 | Directory update | After uploading an API reference document, update the **Readme-EN.md** file in **docs/en/application-dev/reference/apis**.<br>The directories are automatically arranged in alphabetical order.|
| 5 | Document structure | - Module description<br>- Initial version description<br>- Modules to Import/Usage description<br>- API description (attributes, constants, methods, enums, and custom types)<br> The order in which APIs are described in the document must be consistent with that in which they appear in the code. If some APIs have a logical sequence, pay attention to their sequence in the API reference document.|
| 6 | Initial version description | 1. Use the greater-than sign (**>**) followed by a space to indent the description about the initial version of the module. Unless otherwise marked, all APIs in the module have the same initial version.<br>2. When introducing an API to an existing module, use the **<sup>** tag to mark its earliest version. The format is **<sup>versionNumber+</sup>**, for example, **<sup>7+</sup>**.<br>If an attribute is added to an existing module, suffix the **<sup>** tag to the new attribute name, for example, **newAttribute<sup>7+</sup>**.<br>If a method is added to an existing module, suffix the **<sup>** tag to the method name, for example, **sim.getSimIccId<sup>7+</sup>**. The same rule applies to new interfaces, classes, and enums.|
| 7 | Deprecated API description | Do not delete the deprecated content from the document. Instead, suffix **deprecated** as a superscript to the content, and use the greater-than sign (**>**) to introduce the initial version and deprecated version.<br>Example: abandonmentMethod<sup>(deprecated)</sup><br>> This API is supported since API version 4 and deprecated since API version 7. You are advised to use [newMethod]\(#newmethod) instead.|
| 8 | Permission description | Provide the same permission description as that defined in the code for each method, enum, and attribute.<br> 1. If only one permission is required for using the API, use the following format:<br>**Required permissions**: ohos.permission.examplePermission<br>2. If multiple permissions are required for using the API, provide the permissions with **and** or **or** in the following format:<br>**Required permissions**: ohos.permission.examplePermissionA and ohos.permission.examplePermissionB<br>**Required permissions**: ohos.permission.examplePermissionA or ohos.permission.examplePermissionB|
| 8 | Permission description | Provide the same permission description as that defined in the code for each method, enum, and attribute.<br> 1. If only one permission is required for using the API, use the following format:<br>**Required permissions**: ohos.permission.examplePermission<br>2. If multiple permissions are required for using the API, provide the permissions with **and** or **or** in the following format:<br>**Required permissions**: ohos.permission.examplePermissionA and ohos.permission.examplePermissionB<br>**Required permissions**: ohos.permission.examplePermissionA or ohos.permission.examplePermissionB|
| 9 | @syscap | 1. Provide a description for every API in the following format, wherein *A.B* indicates a specific system capability.<br>**System capability**: SystemCapability.*A.B*<br>2. There are two cases for adding system capability information to a table (of attributes, enums, constants, or variables).<br> 1) If all the items in a table require the same system capability, add the following information to the front of the table:<br>**System capability**: SystemCapability.*A.B*<br> 2) If the items in a table require different system capabilities, list the system capability for each item in the table.|
| 10 | @system api | 1. If all APIs of the module are system APIs, add the following sentence to the next line of the initial version description:<br>The APIs provided by this module are system APIs.<br>2. If an API is a system API that can be used only by original equipment manufacturers (OEMs), add the following sentence to the API description:<br>**System API**: This is a system API.|
| 11 | @FAModelOnly<br>@StageModelOnly | 1. If a module is implemented only for a specific ability model, add the following sentence to the next line of the initial version description:<br>The APIs of this module can be used only in the FA model.<br>Or<br>The APIs of this module can be used only in the stage model.<br>2. If an API is implemented only for a specific ability model, add the following sentence to the API description:<br>**Model restriction**: This API can be used only in the FA model.<br/>Or<br/>**Model restriction**: This API can be used only in the stage model.|
...
...
@@ -185,6 +185,9 @@ For details about the error codes, see [moduleName Error Codes]\(link to the err
// Write an actual case that can be easily used, rather than the parameter names themselves. Use comments to describe the content that are not user-defined.
// Example: var result = xxx.createExample(parameterOne); // parameterOne is automatically obtained by scanning.
// Provide sample code for typical scenarios and use comments to describe the effect of the examples.
// Example: If an ID is passed in updateContact(), the specified contact is updated (typical scenario). Otherwise, all contacts are updated.
// Provide clear and concise comments in the following typical scenarios:
// 1. The meaning of a variable name or the code logic is not self-explanatory.
// 2. A complex algorithm or special syntax is involved.
| 1 | Customer-oriented mindset | **Stand in the shoes of developers and provide the use cases, parameter selection principles, recommendations/tips, sample code, and anything else that a developer will need to develop the component.**|
| 2 | Upload path | Upload markdown files to `docs/en/application-dev/reference/arkui-ts`.<br>Upload images to `docs/en/application-dev/reference/arkui-ts/figures`. In addition, reference the image path in the markdown file as follows: ``, ``, or ``.|
| 3 | File name | Provide one TS component reference document for each .d.ts file. Name the file in the format of `ts-componentClassName-componentName.md`.<br>Examples:<br>For the basic component **\<text>**, the reference file name is `ts-basic-component-text.md`.<br>For the container component **\<list>**, the reference file name is `js-container-component-list.md`.|
| 4 | Directory update | After uploading a TS component reference document, update the `Readme-EN.md` file in `docs/en/application-dev/reference/arkui-ts`.|
| 5 | Document structure | - Component description<br>- Initial version description<br>- Modules to import/Usage description<br>- Permission description<br>- APIs, attributes, events, objects, enums, and custom types<br>The order in which APIs are described in the document must be consistent with that in which they appear in the code. If some APIs have a logical sequence, pay attention to their sequence in the document.|
| 6 | Initial version description | 1. Use the greater-than sign (`>`) followed by a space to indent the description about the initial version of the component. Unless otherwise marked, all APIs in the component have the same initial version.<br>2. When introducing an API to an existing component, use the `<sup>` tag to mark its initial version. The format is `<sup>versionNumber+</sup>`, for example, `<sup>7+</sup>`.<br>When introducing an attribute to an existing API, use the `<sup>` tag to mark its initial version. The format is `newAttribute<sup>versionNumber+</sup>`, for example, `newAttribute<sup>7+</sup>`.|
| 2 | Upload path | Upload markdown files to `docs/en/application-dev/reference/arkui-ts`.<br>Upload images to **docs/en/application-dev/reference/arkui-ts/figures**. In addition, reference the image path in the markdown file as follows: **\![]\(figures/exampleImage.jpg)**, **\![]\(figures/exampleImage.png)**, or **\![]\(figures/exampleImage.gif)**.|
| 3 | File name | Provide one TS component reference document for each .d.ts file. Name the file in the format of `ts-componentClassName-componentName.md`.<br>Examples:<br>For the basic component **\<text>**, the reference file name is `ts-basic-component-text.md`.<br>For the container component **\<list>**, the reference file name is `js-container-component-list.md`.|
| 4 | Directory update | After uploading a TS component reference document, update the `Readme-EN.md` file in `docs/en/application-dev/reference/arkui-ts`.|
| 5 | Document structure | - Component description<br>- Initial version description<br>- Modules to import/Usage description<br>- Permission description<br>- APIs, attributes, events, objects, enums, and custom types<br>The order in which APIs are described in the document must be consistent with that in which they appear in the code. If some APIs have a logical sequence, pay attention to their sequence in the document.|
| 6 | Initial version description | 1. Use the greater-than sign (`>`) followed by a space to indent the description about the initial version of the component. Unless otherwise marked, all APIs in the component have the same initial version.<br>2. When introducing an API to an existing component, use the `<sup>` tag to mark its initial version. The format is `<sup>versionNumber+</sup>`, for example, `<sup>7+</sup>`.<br>When introducing an attribute to an existing API, use the `<sup>` tag to mark its initial version. The format is `newAttribute<sup>versionNumber+</sup>`, for example, `newAttribute<sup>7+</sup>`.|
| 7 | Deprecated API description | Do not delete the deprecated content from the document. Instead, suffix `deprecated` as a superscript to the content, and use the greater-than sign (`>`) to introduce the substitute API plus a link to the API description.<br>Example: abandonmentMethod<sup>(deprecated)</sup><br>> This API is no longer maintained since API version 7. You are advised to use [newMethod]\(#newmethod) instead.|
| 8 | Permission description | Use "Required Permissions" as a level-2 heading.<br>1. If a specific permission required for using the component can be requested only by system applications, provide the description in the following format:<br>ohos.permission.examplePermission (available only to system applications)<br>2. If a specific permission required for using the component can be requested by all applications, provide the description in the following format:<br>ohos.permission.examplePermission<br>3. If multiple permissions are required for using the component, provide the permissions with `and` or `or` in the following format:<br>ohos.permission.examplePermissionA and ohos.permission.examplePermissionB<br>ohos.permission.examplePermissionA or ohos.permission.examplePermissionB|
| 9 | @system api | 1. If all APIs of the component are system APIs, add the following sentence to the next line of the initial version description:<br>The APIs provided by this component are system APIs.<br>2. If an API is a system API that can be used only by original equipment manufacturers (OEMs), add the following sentence to the API description:<br>**System API**: This is a system API.|
| 8 | Permission description | Use "Required Permissions" as a level-2 heading.<br>1. If a specific permission required for using the component can be requested only by system applications, provide the description in the following format:<br>ohos.permission.examplePermission (available only to system applications)<br>2. If a specific permission required for using the component can be requested by all applications, provide the description in the following format:<br>ohos.permission.examplePermission<br>3. If multiple permissions are required for using the component, provide the permissions with `and` or `or` in the following format:<br>ohos.permission.examplePermissionA and ohos.permission.examplePermissionB<br>ohos.permission.examplePermissionA or ohos.permission.examplePermissionB|
| 9 | @system api | 1. If all APIs of the component are system APIs, add the following sentence to the next line of the initial version description:<br>The APIs provided by this component are system APIs.<br>2. If an API is a system API that can be used only by original equipment manufacturers (OEMs), add the following sentence to the API description:<br>**System API**: This is a system API.|
| 10 | Sample code programming language | Use code blocks to provide sample code, and mark the programming language ts by adding `// xxx.ets` at the beginning of every sample code block.|
| 11 | Link | Link format: [Link text]\(Link content)<br>Cross-folder link format: [markdown file name]\(\.\./../xxx/xxx.md). One `./` indicates one upper-level folder.<br>Intra-topic link format: [Interface A<sup>7+</sup>]\(#xxxa7). The text in the intra-topic link must be the same as the title to be linked. In the link, all letters must be in lowercase, and no special character (except the hyphen) or tag is included.|
