目录

Getting Started

Sample Code

You can refer to the server-side sample code to learn about the process of pushing scenario-specific messages, and refer to the client-side sample code to learn about the functions and processes of generating a push token and receiving a scenario-specific message from Push Kit.

Development Process

Follow the steps below (pushing notification messages is used as an example) to develop your app.

No. Step Description
1 Enable Push Kit.

Before developing an app, enable Push Kit first. When configuring the signing information, use the manual signing mode.

Automatic signing is available since DevEco Studio 6.0.0 Beta5.
2 Apply for the notification message self-classification permission.

· Apply for the required scenario-specific message permission based on the notification message classification standards. Each message type has its own message classification standards, notification modes, and frequency control rules.

If you have not requested the required permission or the permission you have requested does not match the category field contained in the request body of your REST API call for pushing scenario-specific messages, the messages are classified into news and marketing messages by default. In this case, you are subject to the restriction that each app can push up to 2 or 5 (depending on the app category) messages to each device on a daily basis. When the limit is reached, the device will no longer receive messages from that app on that day.

· You are advised to set testMessage to true during debugging. This ensures that successfully sent messages are not throttled by frequency control and can be received by devices.

· If frequency control is triggered, rectify the fault by referring to Message Frequency Control Problems.
3 Obtain a push token on the client side. When calling a REST API of Push Kit, you need to set the token parameter. For details about how to obtain a token, please refer to Obtaining a Push Token. You should pay attention to the push token change scenario. If the push token of a device changes but the server still uses the outdated push token to call the REST API of Push Kit, the device will not receive the pushed message.
4 Request notification authorization on the client side. To ensure that devices can receive messages properly, you need to call the requestEnableNotification() method to prompt users to allow notifications before sending messages. For details about the sample code, please refer to step 2 in Development Procedure.
5 Configure skills on the client side. Configure skills to ensure proper redirection upon tapping a message. For details, please refer to Actions to Be Triggered upon Message Tapping.
6 Generate a JWT based on a service account on the server side. When calling a REST API of Push Kit to push a scenario-specific message, you need to set the Authorization parameter in the request header. For details about the parameter setting, please refer to Generating a JWT Based on a Service Account.
7 Call a REST API to push a scenario-specific message on the server side. Your app server sends a REST API request. For details, please refer to the request body structure and request body parameters of the HarmonyOS NEXT version. If the API call request fails, rectify the error by referring to Response Parameters. If the request is successful but the device does not receive the message, rectify the error by referring to the relevant FAQ.
8 (Optional) Develop the message receipt. The Push Kit server sends the message delivery status to your app receipt server in a message receipt, so you can learn about the status of the delivered message and rectify any possible errors. For details, please refer to Developing the Message Receipt.
9 (Optional) Receive and process messages on the client side. Server-client data transfer can be achieved in the process of passing parameters on the server side and receiving data on the client side.

(Optional) Other Message Types

For details about all message types supported by Push Kit and their use scenarios, please refer to Message Types.

For example, your app can leverage in-app call messages for making voice and video calls, utilize text-to-speech messages for service implementation of voice broadcasting, and employ background messages to update app configurations.