@@ -148,19 +148,19 @@ The following example shows how to implement a distributed data object synchroni
8. Subscribe to the status (online/offline) changes of the distributed data object. A callback will be invoked to report the status change when the target distributed data object goes online or offline.
9. Unsubscribe from the status changes of the distributed data object. You can specify the callback to unsubscribe from. If you do not specify the callback, all status change callbacks will be unsubscribe from.
The sample code is as follows:
```js
// Unsubscribe from changeCallback.
local_object.off("status",changeCallback);
// unsubscribe from all status change callbacks.
// Unsubscribe from statusCallback.
local_object.off("status",statusCallback);
// Unsubscribe from all status change callbacks.
local_object.off("status");
```
10. Remove a distributed data object from the synchronization network. After the distributed data object is removed from the network, the data changes on the local end will not be synchronized to the remote end.
@@ -253,7 +253,7 @@ The HDF-based driver development involves driver implementation and configuratio
>
> If **preload** is set to **1 (DEVICE_PRELOAD_ENABLE_STEP2)**, the driver is loaded after a quick start is complete. If the system does not support quick start, the value **1** has the same meaning as **DEVICE_PRELOAD_ENABLE**.
>
> If **preload** is set to **2 (DEVICE_PRELOAD_DISABLE)** , the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service, the HDF attempts to dynamically load the driver if the driver service does not exist. For more details, see [Driver Message Mechanism Management](driver-hdf-message-management.md).
> If **preload** is set to **2 (DEVICE_PRELOAD_DISABLE)** , the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service, the HDF attempts to dynamically load the driver if the driver service does not exist. For more details, see [Driver Messaging Mechanism](driver-hdf-message-management.md).
>
> - Sequential loading (**preload** set to **0 (DEVICE_PRELOAD_ENABLE)**)<br/>
> In the configuration file, the **priority** fields (value range: 0 to 200) determines the loading sequence of a host and a driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority.
The Hardware Driver Foundation \(HDF\) provides the following driver framework capabilities: driver loading, driver service management, and driver message mechanism. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you can perform one-time development and multi-system deployment.
The Hardware Driver Foundation (HDF) provides driver framework capabilities including driver loading, driver service management, and driver messaging mechanism. It strives to build a unified driver architecture platform to provide a more precise and efficient development environment, where you can perform one-time development for multi-device deployment.
Both on-demand loading and sequential loading are supported.
- On-demand loading
## Driver Loading
Drivers can be loaded by default during the operating system \(OS\) startup or be loaded dynamically after the OS startup.
The HDF supports the following loading modes:
- Sequential loading
- On-demand loading
The driver is loaded by default during the operating system (OS) boot process or dynamically loaded after OS is started.
Drivers can be loaded based on their priorities during the OS startup.
- Sequential loading
The driver is loaded based on its priority during the OS boot process.
## Driver Service Management<a name="section12453133414412"></a>
## Driver Service Management
The HDF centrally manages driver services. You can directly obtain a specified driver service by using the API provided by the HDF.
The HDF allows centralized management of driver services. You can obtain a driver service by using the API provided by the HDF.
# HDF Development Example<a name="EN-US_TOPIC_0000001052451677"></a>
# HDF Development Example
The following example shows how to add driver configuration, compile the driver code, and implement interaction between the user-state applications and the driver.
## Compiling the Code for Interaction<a name="section6205173816412"></a>
The following is the sample code compiled based on HDF for interaction between the driver and user-state applications. You can place the code in **drivers/adapter/uhdf** for compilation. For details about the **build.gn** file, see **drivers/framework/sample/platform/uart/dev/build.gn**.
## Implementing Interaction Between the Application and the Driver
Write the code for interaction between the user-mode application and the driver. Place the code in the **drivers/adapter/uhdf** directory for compilation. For details about **build.gn**, see **drivers/framework/sample/platform/uart/dev/build.gn**.
>The code compilation of user-state applications depends on the dynamic libraries **hdf\_core** and **osal** provided by HDF because user-state applications use the message sending interface of HDF. In the GN file, add the following dependencies:
> The user-mode application uses the message sending API of the HDF, and the compilation of the user-mode application depends on the dynamic libraries **hdf_core** and **osal** provided by the HDF. Therefore, you need to add the following dependencies to the .gn file:
