Message push process

Before you learn about the push flow, it is helpful to understand some basic concepts of MPS.

Basic Concepts

• Device ID (token)

  The MPS component assigns a unique ID to each client device. This ID is used to identify the target for a message push:

  • Android devices use a self-managed persistent connection for message pushes.

  • iOS devices use the Apple-provided Apple Push Notification service (APNs) for message pushes.

  • HarmonyOS devices use the HarmonyOS-provided HarmonyOS API service for message pushes.

• Push pattern

  The MPS component provides the following push patterns:

  • Push to a specific device ID

  • Push to a specific user ID

  • Broadcast without a specific ID

  Note

  Regardless of the pattern used, the push is ultimately mapped to a device ID within the system. Pushing to a specific user ID is a method that MPS provides to simplify integration with your business systems. Because the push is ultimately mapped to a device ID, the application developer must attach the user ID to the device ID. The IDs are attached when a user logs on and detached when the user logs off.

• Third-party channel push

  A third-party channel push is a push sent through the manufacturer's own channel. This method ensures a high delivery rate. During initialization, which is performed by calling the push init method, the system requests device IDs from both mPaaS and the third-party push platform. The callback returns the mPaaS device ID and the third-party device ID.

  To use a third-party channel push, you must wait for both device IDs to be returned and then call the report interface to upload both device IDs to the MPS core. The system then associates the two IDs. After these steps are completed, you can use the third-party device ID for pushes. Otherwise, the system sends a standard mPaaS push.

Process

MPS consists of two backend systems:

• MPS core (Pushcore): Handles business logic and provides APIs for developers.

• MPS gateway (Mcometgw): Maintains persistent connections with Android devices.

The message push connection flow differs for each device platform:

• Android devices in the Chinese mainland

• Apple and non-Chinese mainland Android devices

• HarmonyOS devices in the Chinese mainland

Android devices in the Chinese mainland

The client uses the RPC SDK to interact directly with the MPS core through the RPC gateway. For Android devices in the Chinese mainland, Mobile Push Service provides a self-managed gateway. The following figure shows the entire flow.

Where:

• When the application starts, the client establishes a persistent connection with the MPS gateway. If the client's connection information does not contain a device ID, the MPS gateway sends a device ID to the client.

• If the user enables a third-party channel such as Xiaomi or Huawei, and the client device supports that channel, the channel's SDK initializes. It establishes a persistent connection service with the corresponding third-party push gateway and retrieves the third-party channel device ID.

• After retrieving the third-party channel device ID, the client calls the device reporting RPC interface to upload the third-party channel device information.

• The application user logs on from the client.

• The server-side receives the user logon request. After the user successfully logs on, you can choose to send a request to the MPS core to attach the user and device.

• The server-side sends a push request.

• The MPS core receives the push request and handles it based on the push type:

  • For a push by device, it directly calls the MPS gateway to send the message.

  • For a push by user, it retrieves the attached device ID based on the user ID in the request. Then, it calls the MPS gateway to send the message.

• The MPS gateway sends the message.

• After the message is sent successfully, the client confirms receipt with the MPS gateway. If the user has configured a callback interface, the MPS core sends a receipt to the server-side.

• The client calls the detach RPC interface when the user actively logs off.

Apple and non-Chinese mainland Android devices

The push gateway for non-Chinese mainland Android devices uses Google's Firebase Cloud Messaging (FCM) service. The push gateway for Apple devices uses Apple's APNs service. This section uses an Apple device as an example.

The client uses RPC to interact directly with the MPS core through the RPC gateway. The following figure shows the entire flow.

Where:

• The client retrieves the device ID sent by Apple.

• The client calls the device reporting RPC interface to upload device information to the MPS core through the RPC gateway.

• The application user logs on from the client.

• After the user successfully logs on, you can choose to call the attach RPC interface. This sends a request to the MPS core through the RPC gateway to attach the user and device.

• The server-side sends a push request to the MPS core.

• The MPS core receives the push request and handles it based on the push type:

  • For a push by device, it directly calls the APNs service to send the message.

  • For a push by user, it retrieves the attached device ID based on the user ID in the request. Then, it calls the APNs service to send the message.

• After the message is sent successfully, the client confirms receipt with the MPS core. If the user has configured a callback interface, the MPS core sends a receipt to the server-side.