提交 37026542 编写于 作者: W wusongqing

updated docs

Signed-off-by: Nwusongqing <wusongqing@huawei.com>
上级 9bf0a40e
# Review Application for the <ApiName\> API in the OpenHarmony <SubsystemName\> Subsystem
## Background
* API type: [Public API | Test API | HDI]
* API requirement source:
* API usage scenario:
* Belonging subsystem:
* Expected API release version:
* Contributor:
* Number of APIs involved in this review:
| Change Type| Quantity| Programming Language|
|---|---|---|
| Added| | |
| Behavior changed| |
| Deprecated| | |
| Deleted| | |
## API Description
### Necessity of the Changes
> Based on the as-is and gap analysis, describe what the application scenarios and benefits of the APIs are.
### Feature Overview
> Describe features implemented by the APIs.
## Review Conclusion
### Review conclusion from committers:
### Review conclusion from domain SIGs:
## Self-Check Table
| Self-Check Item| Self-Check Result|
|---|---|
| Is the spelling check completed?| |
| Are coding specifications complied with?| |
| Are parts of speech (noun, adjective, adverb) used correctly?| |
| Does the API name fully describe the API logic?| |
|Is the number of API parameters appropriate? (Generally, there should be fewer than 7 parameters.)| |
|Are abbreviations properly used? (Abbreviations used should be well known.)| |
|Is it really that the caller of a void API does not need a return value?| |
|Is the inheritance system appropriate? Does every method of a parent class apply to its child classes?| |
|Are all possible error states included and defined?| |
| Is the group of antonyms used correctly, for example: <br/>add/remove, create/destroy, insert/delete, start/stop, begin/end,<br/>send/receive, up/down, show/hide, open/close, source/target,<br/>source/destination, increase/decrease, first/last, next/previous| |
|Are the description and semantic hierarchy of new APIs consistent with those of existing APIs in the same module?| |
| Are asynchronous counterparts needed for synchronous APIs?| |
| Are all the public APIs truly required by developers?| |
## API Description
> Enter the code commit address.
* Code address:
## API Permission Design
> Specify whether developers need to apply for certain permissions to use the APIs.
## API Privacy Protection Design
> If user privacy data is involved, privacy protection must be considered.
## Developer Guide
> Optional.
## API Code Example
> Select either of the following:
* Code address:
* Code snippet:
## API Updates
> Only required for existing APIs.
### Behavior Change
> The API behavior change indicates that the API only has its behavior changed.
> The new API behavior must be released in a new version. You should not change the API behavior without releasing a new version (except for defect rectification).
#### Related APIs
#### Reason for the Change
### Deprecated APIs
> Add the `@deprecated` annotation to the description of deprecated APIs (including JS, TS, C, and C++ APIs).
#### Related APIs
> State the version from which the API is annotated by `@deprecated`.
#### Reason for Deprecation
#### Substitute APIs
> List the APIs provided to substitute the deprecated ones. If there are no substitute APIs provided, describe the reason.
### Deleted APIs
> An API can be deleted only after five API versions have been released since it is marked as deprecated.
#### Related APIs
#### Reason for Deletion
#### Substitute APIs
> List the APIs provided to substitute the deleted ones. If there are no substitute APIs provided, describe the reason.
## DFX
### Compatibility
### Performance
### Power Consumption
### Reliability
### Testability
> Automatic API test cases must be delivered for all APIs.
## Review Conclusion
* Reviewed on:
* Reviewers:
* Review conclusion: [Pass | Fail]
* Review meeting minutes:
...@@ -136,10 +136,7 @@ Design APIs from the perspective of their users rather than providers. ...@@ -136,10 +136,7 @@ Design APIs from the perspective of their users rather than providers.
### Compatibility ### Compatibility
1. The API compatibility requirements in descending order are as follows: contract compatibility > binary-code compatibility > source-code compatibility. 1.
1. Source-code compatibility: After version evolution, the developer’s existing source code can be compiled properly.
2. Binary-code compatibility: After version evolution, the developer’s existing programs can be linked to and run properly without recompilation.
3. Contract compatibility: It is also called semantic compatibility. After version evolution, the developer’s original program behaviors remain unchanged.
2. OpenHarmony API backward compatibility must meet binary-code compatibility requirements. Exceptions must be reviewed by the API SIG and approved by the PMC. Common API changes that break binary-code compatibility include: 2. OpenHarmony API backward compatibility must meet binary-code compatibility requirements. Exceptions must be reviewed by the API SIG and approved by the PMC. Common API changes that break binary-code compatibility include:
1. Delete any API elements. 1. Delete any API elements.
2. Reduce the visibility of a method. For example, change from protected to private or from public to protected. 2. Reduce the visibility of a method. For example, change from protected to private or from public to protected.
......
en/design/figures/API-Lifecycle.png

52.2 KB | W: | H:

en/design/figures/API-Lifecycle.png

49.1 KB | W: | H:

en/design/figures/API-Lifecycle.png
en/design/figures/API-Lifecycle.png
en/design/figures/API-Lifecycle.png
en/design/figures/API-Lifecycle.png
  • 2-up
  • Swipe
  • Onion skin
zh-cn/design/figures/API-Workflow.png

138.1 KB | W: | H:

zh-cn/design/figures/API-Workflow.png

98.7 KB | W: | H:

zh-cn/design/figures/API-Workflow.png
zh-cn/design/figures/API-Workflow.png
zh-cn/design/figures/API-Workflow.png
zh-cn/design/figures/API-Workflow.png
  • 2-up
  • Swipe
  • Onion skin
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册