DEV Community: simple lau

How to Configure Multiple Environments for HarmonyOS Applications

simple lau — Wed, 14 May 2025 13:33:28 +0000

Preface

As is well known, development certificates and release certificates are not interchangeable. For those who have launched apps before, it is common knowledge that app submission rarely succeeds on the first try, and during daily updates, there are often scenarios where the app needs to be frequently released or updated. However, each app release requires switching certificates and repackaging the app.

With a large number of certificates, switching them each time becomes a tedious task. Forgetting to switch the correct certificate may lead to app rejection during submission, which is a minor issue. However, if it delays fixing a critical bug in the production environment, the consequences could be severe.

Additionally, when the environment changes, some variables (such as production server URLs) need to be adjusted accordingly. Forgetting to modify these variables can also cause significant problems.

Therefore, in development, there is a clear need to configure multiple sets of certificates and use environment variable control.

Configure Multiple Environments

We need to configure app.products in the global build-profile.json5 to package multiple product variants. Example configuration:

"products": [
  {
    "name": "default", // Ensure at least one "default" product exists in products
    "signingConfig": "default",
    "compatibleSdkVersion": "5.0.0(12)",
    "runtimeOS": "HarmonyOS",
    "buildOption": {
      "strictMode": {
        "caseSensitiveCheck": true,
        "useNormalizedOHMUrl": true
      }
    }
  },
  {
    "name": "release",
    "signingConfig": "release",
    "compatibleSdkVersion": "5.0.0(12)",
    "runtimeOS": "HarmonyOS",
    "buildOption": {
      "strictMode": {
        "caseSensitiveCheck": true,
        "useNormalizedOHMUrl": true
      }
    }
  }
]

Add a new set of signatures named release (this name needs to correspond to the signingConfig above).

Configure an additional target in the modules section to associate the phone entry with corresponding products:

{
  "name": "phone",
  "srcPath": "./entry",
  "targets": [
    {
      "name": "default",
      "applyToProducts": [
        "default"
      ]
    },
    {
      "name": "release",
      "applyToProducts": [
        "release"
      ]
    }
  ]
}

Modify the targets configuration in build-profile.json5 under the entry directory:

[
  {
    "name": "default"
  },
  {
    "name": "release"
  }
]

This completes the configuration for multiple signing profiles. To switch between different signatures, simply click the Product icon in the top-right corner.

Define Environment Variables

HarmonyOS projects are not frontend projects, so there is no .env file or --mode=production parameter.

We already know how to package multiple builds. Now, we just need to determine whether the current build is release or default to distinguish environments. Normally, we cannot directly know the current build mode, but the HAR runtime can obtain compilation parameters and generate a BuildProfile class file. Therefore, we can indirectly distinguish environments by introducing the BuildProfile file in the HAR package:

import BuildProfile from '../../../../BuildProfile';
const isRelease = (BuildProfile.BUILD_MODE_NAME as string) === 'release';

At this point, we can configure some JSON files and use the isRelease variable (or declare a mapping) to determine the current environment.

Summary

The general steps are as follows:

Configure multiple sets of certificates and environment variables in HarmonyOS development.
For multi-environment configuration, complete multiple signing configurations by editing the global build-profile.json5 and app.products, and switch signatures as needed.
When defining environment variables, leverage the BuildProfile file introduced at HAR runtime to determine the build environment.

Article and code version: HarmonyOS 5.0.1 Release SDK.

How to set up a HarmonyOS project from scratch

simple lau — Wed, 14 May 2025 13:27:11 +0000

0. Download the ecodev editor

(Details omitted)

1. Create a Project

Create an empty project.

Fill in the new project information.

Tip: The device type corresponds to the platform(s) where your app will be published when it goes live.

2. Three-Tier Architecture Setup

First, let's understand what the three-tier architecture is. In simple terms:

The first tier (Entry Layer): This is the entry point for different device types (e.g., phones, watches, foldable screens, etc.).
The second tier (Basic Features Layer): Comprising various components and pages, this layer serves as a resource for the Entry Layer to reference.
The third tier (Common Capabilities Layer): Stores utility libraries and common configurations, which can be referenced by both the Entry Layer and the Features Layer.

The structure of the three-tier project is as follows:

commons (Common Capabilities Layer): Stores common foundational capabilities (e.g., utility libraries, common configurations). This layer can be compiled into one or more HAR or HSP packages and can only be depended on by the products and features layers, not the other way around.
features (Basic Features Layer): Contains basic feature sets (e.g., UI and business logic implementations for relatively independent functions in the application). Each feature is highly cohesive, loosely coupled, and customizable, enabling flexible deployment in products. Features that do not require separate deployment are typically compiled into HAR or HSP packages for use by products or other features. Features requiring separate deployment are usually compiled into Feature-type HAP packages, which are deployed in combination with the Entry-type HAP packages under products. The features layer can horizontally invoke and depend on the common layer and can be depended on by HAPs of different device forms in the products layer, but it cannot depend on the products layer.
products (Product Customization Layer): Integrates functions and features for different device forms. Each subdirectory in this layer is compiled into an Entry-type HAP package, serving as the main entry point for the application. The products layer cannot invoke other modules horizontally.

3. Create the Common Layer

Create a folder named commons in the project root directory to place modules for the common capabilities layer. You can choose between a HAR package or an HSP package; here, we select an HSP package.

Here you can name the module and select the device types that can use this module.

4. Create the Features Layer

Similar to the third step, create a folder named features in the project root directory to place modules for the basic features layer. You can choose between a HAR package or an HSP package; here, we still select an HSP package.

5. Create the Entry Layer

Create a folder named products in the project root directory for product modules. Rename the entry module to phone (note that you should rename the module, not just the folder, as shown in the figure below), then drag it into the products folder.

In this way, the three layers are basically created.

6. Architecture Association

When you need to use tools from the basic module in the phone module, follow these steps:

Open the phone/oh-package.json5 file.
Add the following content under the dependencies section:

"dependencies": {
  "basic": "file:../../commons/basic"
}

Click Sync Now to update the project dependencies.

Note: The modules you want to use should be either imported in basic/Index.ets or exported from other .ets files under the basic module (e.g., basic/xx/xx.ets).

7. Tips

I believe the three - tier architecture is suitable for building relatively large projects. For normal projects, a one - tier or two - tier architecture can meet the requirements. Currently, HarmonyOS is evolving rapidly. When developing a project, it is best not to frequently change the IDE version, otherwise, there may be various unexpected issues.

If you need the project, you can check the git repository.

git clone https://gitee.com/simple-lau/harmony_template.git

The version of the article and code used is HarmonyOS 5.0.1 Release SDK.

How to invoke the WeChat functions in a HarmonyOS project?

simple lau — Wed, 14 May 2025 10:34:08 +0000

Preliminary Preparation

For the HarmonyOS project to pass the review on the WeChat platform, a wx_app_id is required. It can generally be found through the platform. The process is omitted here.

Download Dependencies

First of all, we need to download the third-party library of WeChat to call relevant functions of WeChat, such as logging in, sharing with friends, sharing on Moments, etc.

Encapsulate the Callback Class

We can create a file and build a class.

This class is used for unified callbacks when we request WeChat functions. Some corresponding data will be returned. If we need to listen to a certain event, we can register here.

However, since unified callbacks are required, we can attach an identifier "state" when sending an event to distinguish the type of the callback event. The return value will also carry the identifier "state", and corresponding event handling can be carried out according to the "state" of the return value.

First, we need two arrays for storage.

// Used to store callback functions for WeChat request (Req) events.
// Both the key and the value are callback functions. Using a Map here makes it convenient to manage and delete callbacks.
onReqCallbacks: Map<
  (req: wechatOpenSdk.BaseReq) => void, 
  (req: wechatOpenSdk.BaseReq) => void
> = new Map()
// Used to store callback functions for WeChat response (Resp) events.
// Both the key and the value are callback functions. Using a Map also makes it convenient to manage and delete callbacks.
onRespCallbacks: Map<
  (resp: wechatOpenSdk.BaseResp) => void, 
  (resp: wechatOpenSdk.BaseResp) => void
> = new Map()

// Import all exports from the Tencent WeChat Open SDK and alias them as the wechatOpenSdk namespace
import * as wechatOpenSdk from "@tencent/wechat_open_sdk"

/**
 * The WechatApiEventHandlerImpl class implements the wechatOpenSdk.WXApiEventHandler interface
 * to handle request (Req) and response (Resp) events from the WeChat Open SDK,
 * while managing event callback functions.
 */
class WechatApiEventHandlerImpl implements wechatOpenSdk.WXApiEventHandler {

  /**
   * Registers a callback function for WeChat request (Req) events
   * @param on - The callback function to execute when a WeChat request is received,
   *             which takes a parameter of type BaseReq
   */
  registerOnWXReqCallback(on: (req: wechatOpenSdk.BaseReq) => void) {
    // Add the callback function to the onReqCallbacks map
    this.onReqCallbacks.set(on, on)
  }

  /**
   * Unregisters a callback function for WeChat request (Req) events
   * @param on - The callback function to unregister, which takes a parameter of type BaseReq
   */
  unregisterOnWXReqCallback(on: (req: wechatOpenSdk.BaseReq) => void) {
    // Remove the specified callback function from the onReqCallbacks map
    this.onReqCallbacks.delete(on)
  }

  /**
   * Registers a callback function for WeChat response (Resp) events
   * @param on - The callback function to execute when a WeChat response is received,
   *             which takes a parameter of type BaseResp
   */
  registerOnWXRespCallback(on: (resp: wechatOpenSdk.BaseResp) => void) {
    // Add the callback function to the onRespCallbacks map
    this.onRespCallbacks.set(on, on)
  }

  /**
   * Unregisters a callback function for WeChat response (Resp) events
   * @param on - The callback function to unregister, which takes a parameter of type BaseResp
   */
  unregisterOnWXRespCallback(on: (resp: wechatOpenSdk.BaseResp) => void) {
    // Remove the specified callback function from the onRespCallbacks map
    this.onRespCallbacks.delete(on)
  }

  /**
   * This method is called when a WeChat request (Req) is received
   * @param req - The received WeChat request object of type BaseReq
   */
  onReq(req: wechatOpenSdk.BaseReq): void {
    // Original comment: Log.i(kTag, "onReq:%s", JSON.stringify(req))
    // Iterate over all callback functions in the onReqCallbacks map and execute them in sequence
    this.onReqCallbacks.forEach((on) => {
      on(req)
    })
  }

  /**
   * This method is called when a WeChat response (Resp) is received
   * @param resp - The received WeChat response object of type BaseResp
   */
  onResp(resp: wechatOpenSdk.BaseResp): void {
    // Original comment: Log.i(kTag, "onResp:%s", JSON.stringify(resp))
    // Iterate over all callback functions in the onRespCallbacks map and execute them in sequence
    this.onRespCallbacks.forEach((on) => {
      on(resp)
    })
  }
}

/**
 * The WechatManager class manages WeChat-related operations such as image sharing and WeChat login.
 */
export class WechatManager {
    /**
     * UI ability context, used to provide application context information (optional property).
     */
    context?: common.UIAbilityContext;

    /**
     * Creates a WeChat API instance using the WeChat app ID stored in the global variables.
     */
    wxApi = wechatOpenSdk.WXAPIFactory.createWXAPI(GlobalVariable.WX_APP_ID);

    /**
     * Shares an image to a WeChat conversation.
     * @param filePath - The local path of the image file to be shared.
     */
    shareImage(filePath: string) {
        // Create an image object
        let imageObject = new wechatOpenSdk.WXImageObject();
        // Set the URI of the image object using the file path
        imageObject.uri = fileUri.getUriFromPath(filePath);

        // Create a media message object
        let mediaMessage = new wechatOpenSdk.WXMediaMessage();
        // Attach the image object to the media message
        mediaMessage.mediaObject = imageObject;

        // Create a request object to send a message to WeChat
        let req = new wechatOpenSdk.SendMessageToWXReq();
        // Set the sharing scenario to a conversation
        req.scene = wechatOpenSdk.SendMessageToWXReq.WXSceneSession;
        // Attach the media message to the request
        req.message = mediaMessage;
        // Send the request via the WeChat API with the context
        this.wxApi.sendReq(getContext(this) as common.UIAbilityContext, req);
    }

    /**
     * Initiates a WeChat login request.
     * @returns A Promise that resolves to true on success or rejects with false on failure.
     */
    async login(): Promise<boolean> {
        return new Promise(async (resolve, reject) => {
            // Create an authorization request object
            let req = new wechatOpenSdk.SendAuthReq();
            // Set the authorization scope to retrieve user information
            req.scope = "snsapi_userinfo";
            // Generate a random UUID as the state parameter
            const state = util.generateRandomUUID();
            // Attach the state parameter to the request
            req.state = state;
            // Send the authorization request via the WeChat API
            this.wxApi.sendReq(getContext(this) as common.UIAbilityContext, req);

            // Register a callback for WeChat responses
            wechatEventHandler.registerOnWXRespCallback(async (resp) => {
                // Cast the response to a SendAuthResp object
                const res = resp as wechatOpenSdk.SendAuthResp;
                // Check if the state parameter matches and the error code indicates success
                if (res.state === state && res.errCode === wechatOpenSdk.ErrCode.ERR_OK) {
                    // The WeChat login has been successfully initiated; proceed with subsequent operations
                    resolve(true);
                } else {
                    // Reject the Promise if conditions are not met
                    reject(false);
                }
            });
        });
    }
}

Event Listening and Registration

Add an event within the lifecycle of the application window entry.

// Cold start mode. When the current application is launched by WeChat, listen for corresponding data.
onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
  this.handleWeChatCallIfNeed(want);
}

// Hot start mode. When returning to the current application from WeChat, listen for the need of corresponding responses.
onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void {
  this.handleWeChatCallIfNeed(want);
}

private handleWeChatCallIfNeed(want: Want) {
  wechatManager.wxApi.handleWant(want, wechatEventHandler)
}

The version of the article and the code used is HarmonyOS 5.0.1 Release SDK.

How to publish a HarmonyOS application?

simple lau — Wed, 14 May 2025 10:27:56 +0000

1. Obtain Certificates

To publish an app on the HarmonyOS AppGallery, you must apply for official certificates. (During personal development, you might often use auto-signing, but it is not accepted for app submission.) The certificates include p12, cer, csr, and p7b.

Summary: Create a folder in advance to store the four certificates. Generate a p12 and csr certificate in the IDE, then apply for the cer and p7b certificates on the AppGallery Content (AGC) platform, which is Huawei's app publishing platform.

Detailed Steps:

1.1 Obtain the p12 Certificate

In the top navigation bar of the IDE, find Build, then click Generate Key and CSR.

When generating the p12 certificate, you'll need to set a password. Write it down—forgetting it means you'll have to regenerate all certificates from scratch! A hard lesson learned; don't repeat this mistake!

1.2 Obtain the CSR Certificate

After generating the p12 certificate, click Next to proceed. Select a storage location to save the CSR certificate file.

1.3 Obtain the CER Certificate

To obtain the CER certificate, log in to AppGallery Content. After entering AGC, click "Add Certificate". The CSR certificate used here should be the one obtained in the previous step. After clicking "Submit" to successfully apply for the certificate, the certificate management page will display the certificate name, certificate type, and expiration date. Click "Download" to save the generated certificate to your local device for subsequent signing.

1.4 Obtain the P7B Certificate

Enter the Profile page as shown below, and click "Add Certificate". Select the certificate created in the previous step.

Notes on applying for restricted permissions: For example, restricted ACL permissions such as writing to and reading from the photo album. If these restricted permissions are used, you need to check the corresponding boxes here and apply to the platform for the permissions.

Tips: HarmonyOS may not easily grant these permissions. Consider using security components or security pop - ups to reduce the application for restricted permissions.

2. Package the Application

2.1 Configure Certificates

Open your IDE and navigate to the signing configuration section (refer to the illustration below).
Uncheck the "Auto-signing" option.
According to the certificate file extensions specified in the prompts:
- Import the p12 certificate you generated earlier.
- Enter the password you set when creating the p12 certificate (this password is also used for the alias).
- Enter the alias you specified during p12 certificate generation.

Important: Ensure the password and alias exactly match those from your p12 certificate creation step.

2.2 Build the Project

Click Build in your IDE to compile the application.
After the build process completes, a new build directory will be generated.
Navigate to build/outputs/default/.
Locate the file ending with .signed.app—this is your signed application package ready for upload to the AppGallery.

3. Publish the Application

Log in to AppGallery Connect and access "My Apps".
Click on the app you want to publish.
Fill in the relevant app information. The specific details may vary depending on the app, so screenshots are not provided here.
Upload the app package (the file ending with .signed.app built in the previous step).

Once the upload is completed and all the information is filled in, there will be a pre-review mechanism for examination. If it passes the pre-review, it will enter the stage of manual review.

The version of the article and the code used is HarmonyOS 5.0.1 Release SDK.

A Brief Discussion on Multithreading in HarmonyOS

simple lau — Sun, 11 May 2025 03:03:33 +0000

Today, I'd like to discuss multithreading in HarmonyOS development with you. ArkTS provides two concurrency capabilities, TaskPool and Worker, for developers to choose from.

First, let me share my personal understanding: Use TaskPool in scenarios where lightweight and frequent use of multithreading is required. Use Worker when there are tasks with large computational amounts and high resource consumption that need multithreading.

1. Concepts

The main function of TaskPool is to provide a multithreading running environment for applications. It enables developers to submit tasks to the task queue in the host thread. The system selects an appropriate worker thread to execute the task and then returns the result to the host thread. There is no need to manage the thread lifecycle.

The main function of Worker is also to provide a multithreading running environment for applications. It ensures that the application can be separated from the host thread during execution and run scripts in the background thread for time-consuming operations, avoiding computation-intensive or high-latency tasks from blocking the host thread. When it's no longer needed, it needs to be manually destroyed; otherwise, it will keep consuming memory.

2. Applicable Scenarios

Worker: Suitable for tasks that need to run for a long time and are relatively independent, such as processing a large amount of data and performing complex algorithm calculations. Since the Worker creates an independent thread, it can continuously perform complex calculation tasks without affecting the main thread.
TaskPool: More suitable for executing multiple short-term tasks, especially those that can be executed in parallel. For example, when an application is starting up and there are tasks for initializing multiple modules simultaneously, using TaskPool can distribute these tasks to different threads for parallel execution, thus improving the application's startup speed.

3. Usage Methods

Worker: To create a Worker, you need to specify a script file and write the task logic to be executed in that script file. Communication between the main thread and the Worker thread is carried out through the postMessage method. Here is a simple example:

Add the following configuration to the module-level entry/build-profile.json5 configuration file:

  "buildOption": {
      "sourceOption": {
          "workers": [
              "./src/main/ets/workers/Worker.ets"
          ]
      }
  }

// Create a Worker object in the host thread
const workerInstance = new worker.ThreadWorker("entry/ets/workers/Worker.ets");
// The host thread sends information to the worker thread
workerInstance.postMessage({ data: 'test' });
// The host thread receives information from the worker thread
workerInstance.onmessage = (e: MessageEvents): void => {
  // data: Information sent by the worker thread
  console.info("main thread data is  " + e.data);
  // Destroy the Worker object
  workerInstance.terminate();
}
// After calling terminate, execute onexit
workerInstance.onexit = (code) => {
  console.log("main thread terminate");
}

workerInstance.onerror = (err: ErrorEvent) => {
  console.log("main error message " + err.message);
}

// Worker.ets
import { worker, MessageEvents, ErrorEvent } from '@kit.ArkTS';

// Create an object in the worker thread for communication with the host thread
const workerPort = worker.workerPort

// The worker thread receives information from the host thread
workerPort.onmessage = (e: MessageEvents): void => {
  // data: Information sent by the host thread
  console.info("main thread data is  " + e.data);
  // The worker thread sends information to the host thread
  workerPort.postMessage('result');
}

// Callback when an error occurs in the worker thread
workerPort.onerror = (err: ErrorEvent) => {
  console.log("worker.ets onerror" + err.message);
}

TaskPool: When using TaskPool, developers only need to define the task function and then submit the task to the TaskPool. The TaskPool will automatically select an appropriate thread to execute the task. Here is an example of using TaskPool:

import { taskpool } from '@kit.ArkTS';

@Concurrent
function add(num1: number, num2: number): number {
  return num1 + num2;
}

async function ConcurrentFunc(): Promise<void> {
    let task: taskpool.Task = new taskpool.Task(add, 1, 2);
    console.info("taskpool.execute(task) result: " + await taskpool.execute(task));
}

4. Resource Management

Worker: Each Worker creates an independent thread, so it will occupy relatively more system resources. When the Worker task is completed, if it is not manually terminated, it will keep occupying system resources. In the same process, theoretically, a maximum of 64 Workers can be configured (the actual number depends on the remaining memory space).
TaskPool: TaskPool manages threads through a thread pool, avoiding the resource overhead caused by frequent creation and destruction of threads. The threads in the thread pool can be reused by multiple tasks, thus improving resource utilization. However, the TaskPool can only execute tasks for a maximum of 3 minutes (usually this time is sufficient because this duration does not include the time-consuming operation of asynchronous waiting).

Summary

Worker runs the specified script by creating an independent thread, which is suitable for long-term and independent tasks. It requires manual management of thread resources and communicates through messages. TaskPool, as a thread pool management tool, automatically manages the creation, reuse, and destruction of threads, supports multiple task types, and is suitable for multiple short-term parallel tasks.

The version used in this article and code is HarmonyOS 5.0.1 Release SDK.

How to communicate with wearable devices in HarmonyOS development

simple lau — Sat, 10 May 2025 23:47:09 +0000

0. Preparation Work

Enter the "Management Center" of the Huawei Developer Alliance, and click on the "Wear Engine" card under the "Application Service" tab.

Note: The permission review may take a long time. Even if expedited, it may take 3 to 5 days. Therefore, if you need to use this permission, you should apply for it as early as possible to avoid delaying important matters.

1. Project Configuration

Configure the client_id in the module.json5 of the engineering project. If it has been configured previously, you can ignore this step.

"metadata": [ // Configure the following information
    {
        "name": "client_id",
        "value": "xxxxxx"
    }
]

2. Permission Acquisition

// Step 1: Obtain the AuthClient object
let authClient: wearEngine.AuthClient = wearEngine.getAuthClient(getContext(this));

// Step 2: Define the permission request class based on the permissions that require user authorization
let request: wearEngine.AuthorizationRequest = {
  permissions: [wearEngine.Permission.USER_STATUS]
}

Note: The permissions you request here must correspond to the permissions you've applied for in the developer console. If the permissions don't match, you'll encounter an error code 1008500004.
The available permission enumerations are:

USER_STATUS: User status data
HEALTH_SENSOR: Health sensor data (e.g., heart rate)
MOTION_SENSOR: Motion sensor data (e.g., accelerometer)
DEVICE_IDENTIFIER: Device identifier information

3. Device Communication

3.1 Obtain Devices

// Obtain the DeviceClient object
const deviceClient = wearEngine.getDeviceClient(ctx)
// Obtain the connected wearable devices
const deviceList = await this.deviceClient.getConnectedDevices()
// Obtain the specified wearable device
const targetDevice = deviceList.find(device => device.category === wearEngine.DeviceCategory.WATCH)

After obtaining the device list, you can further obtain the specified device through the device's category, name, device model, etc. Once you have obtained the device, you can perform the next steps of operation on it.

3.2 Communication Configuration

Some preparatory work needs to be done before the device communicates with other devices:

Prepare the package name and appid of the watch application, which will be required during communication.
Configure the package name and appid of the current application on both the mobile phone side and the watch side. If not configured properly, errors such as 206 and 207 will occur. If there are multiple package names, you can separate them with commas (in module.json5).

metadata: [
    {
      "name": "wearEngineRemoteAppNameList",
      "value": "xxx.xxx.xxx"
    }
]

3.3 Device Communication

Before device communication, you can first check whether the device that needs to communicate is properly installed on the current device, and launch the application on the remote device.

// Obtain the client of the P2p module
const p2pClient = wearEngine.getP2pClient(ctx)

// Check if it is installed currently
p2pClient.isRemoteAppInstalled(this.device.randomId, this.remoteBundleName)
  .then((isInstalled) => {
    if(isInstalled) {
        // Launch the remote app
       await p2pClient.startRemoteApp(targetDevice.randomId, 'Specified package name')
    }
  })

// Send a message
const textEncoder: util.TextEncoder = new util.TextEncoder();
const messageStr = JSON.stringify(messageContent)
const message: wearEngine.P2pMessage = {
  content: textEncoder.encodeInto(messageStr)
}
p2pClient.sendMessage(this.device.randomId, appParam, message)

// Receive a message
p2pClient.registerMessageReceiver(this.device.randomId, appParam, callback)

Notes:

Before device communication, only binary data can be sent, so it is necessary to convert it into the corresponding format through textEncoder.encodeInto.
appParam is the watch package name and appid prepared in 3.2, with the following format:

    {
      remoteApp: {
        // Set the application information of the device-side application: package name and fingerprint
        bundleName: '',
        fingerprint: ''
      }
    }

Summary of the Ideas

During the development process, first apply for the permission for the current application to access the wearable device service connected to the mobile phone through wearEngine.AuthClient.
Then obtain the client device object deviceClient through wearEngine.getDeviceClient.
Further obtain the list of wearable devices connected to the current mobile phone through deviceClient.getConnectedDevices of the client device object.
Obtain the specified device through the type and name of the wearable device list.
Use the built-in methods of wearEngine to obtain the specified client class, which can be used to monitor the status of the current device, launch the service, obtain the sensor data of the wearable device, and perform two-way communication, etc.

The version used in this article and code is HarmonyOS 5.0.1 Release SDK.