The device cannot receive offline messages manually pushed by the server.

#harmonyos #pushkit #mobiledevelopment #tutorial

Read the original article：The device cannot receive offline messages manually pushed by the server

Problem Description

When the server pushes offline messages, if the mobile application process does not exist, the messages cannot be received. Even after starting the application and the process exists, the messages still cannot be received. How to locate and handle this issue?

Scenario:

The category selected for the push is MARKETING.

The token has been obtained.

Background Knowledge

Offline Push: Offline push refers to the process where, if the device is offline, Push Kit will cache the messages and push them to the device once it comes online. For more details, refer to: Push Kit Introduction.

Offline means the device is in an offline state, i.e., powered off or without network connectivity, and is not related to whether the APP is in the process.

If the device has network connectivity, it can receive push messages regardless of whether the APP is in the process.

If the device is already offline, developers can control the time the message is cached on the Push server through the ttl parameter in the request body. If the user's device comes online within the message cache time, the message will be delivered; otherwise, the message will be discarded after the cache time.

Troubleshooting Process

Notification Authorization:

You can determine whether the user has authorized by checking the error code returned from requestEnableNotification. If the returned error code is 1600004, it indicates that the authorization was denied. Below is an example code for the development steps. Please refer to it:

import { notificationManager } from '@kit.NotificationKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { UIAbility } from '@kit.AbilityKit';
import { window } from '@kit.ArkUI';
import { hilog } from '@kit.PerformanceAnalysisKit';

class MyAbility extends UIAbility {
  onWindowStageCreate(windowStage: window.WindowStage) {
    hilog.info(0x0000, 'testTag', '%{public}s','Ability onWindowStageCreate');
    windowStage.loadContent('pages/Index', (err, data) => {
      if (err.code) {
        hilog.error(0x0000, 'testTag', 'Failed to load the content. Cause: %{public}s', err);
        return;
      }
      hilog.info(0x0000, 'testTag', 'Succeeded in loading the content. Data: %{public}s', data);
      notificationManager.requestEnableNotification(this.context).then(() => {
        hilog.info(0x0000, 'testTag', `[ANS] requestEnableNotification success`);
      }).catch((err: BusinessError) => {
        hilog.error(0x0000, 'testTag',
          `[ANS] requestEnableNotification failed, code is ${err.code}, message is ${err.message}`);
      });
    });
  }
}

Message Type and Configuration:

Confirm that the type and configuration of the message to be sent are correct. For instance, it is necessary to set appropriate category and push-type to ensure the message is processed correctly. Additionally, check if testMessage is set to true, as test messages have specific sending restrictions:

When testMessage is true, a single project can push up to 1000 test messages, with no more than 10 Tokens carried per push. When pushing authorized subscription messages and card refresh messages, only one Token can be carried per push.

If the self-classification rights for notification messages have not been applied for, the pushed notification messages will default to the information marketing category (with category value set to MARKETING). If only information marketing messages need to be sent, there is no need to apply for the self-classification rights for notification messages.

PushToken:

Confirm that the application has successfully obtained and uploaded the PushToken.

The PushToken identifies each application on every device. Developers call the getToken() interface to request the PushToken from the PushKit server, and use the PushToken to send push messages after obtaining it.

The PushToken generally does not change, except in the following scenarios where the PushToken may change:

Uninstall the application and then reinstall it.
Reset the device to factory settings.
After the application explicitly calls the deleteToken() interface, call the getToken() interface again.
After the application explicitly calls the deleteAAID() interface, call the getToken() interface again.
When the device (only Wearable devices) is taken to other countries or regions overseas, the system will update the device's Token. The updated Token is returned through the callback of the pushService.on('tokenUpdate') interface.

Therefore, it is recommended to call the getToken() interface when the application starts. If the device's PushToken changes, it should be promptly reported to the application server to update the PushToken.

Below is a reference example code:

  // Import the pushService module and related common modules.
  import { pushService } from '@kit.PushKit';
  import { hilog } from '@kit.PerformanceAnalysisKit';
  import { BusinessError } from '@kit.BasicServicesKit';

  // It is recommended to call the `getToken()` interface in the `onCreate()` method of the UIAbility (such as EntryAbility) to obtain the PushToken and report it to the server, facilitating the server to push messages to the terminal.
  try {
    pushService.getToken().then((data: string) => {
      hilog.info(0x0000, 'testTag', 'Succeeded in getting push token.');
    }).catch((err: BusinessError) => {
        hilog.error(0x0000, 'testTag', 'Failed to get push token: %{public}d %{public}s', err.code, err.message);
    });
  } catch (err) {
    let e: BusinessError = err as BusinessError;
      hilog.error(0x0000, 'testTag', 'Failed to get push token: %{public}d %{public}s', e.code, e.message);
  }

Configuration Issues with the module.json5 File:

Under the skills tag in the module.json5 file, multiple skill objects can coexist, each corresponding to a specific capability. If you need to set up both push message redirection capabilities and other redirection capabilities (such as NFC redirection, browser redirection, etc.) simultaneously, you should create different skill objects within the skills array, each mapping to the corresponding capability. It is not recommended to configure multiple actions within a single skill, as this may result in the inability to match the intended scenarios.

Analysis Conclusion

There is an issue with the configuration of the module.json5 file, which requires the creation of different skill objects within the skills array.

Solution

If you need to set up both push message redirection capabilities and other redirection capabilities (such as NFC redirection, browser redirection, etc.), you should create different skill objects within the skills array, each mapping to the corresponding capability.

Example of skills tag configuration:

"abilities": [
  {
    "name": "PushMessageAbility",
    "srcEntry": "./ets/abilities/PushMessageAbility.ets",
    "launchType": "singleton",
    "startWindowIcon": "$media:startIcon",
    "startWindowBackground": "$color:start_window_background",
    "exported": false,
    "skills": [
      {
        "actions": [
          "action.ohos.push.listener"
        ]
      }
    ]
  }
]