Mobile Platform as a Service:Message push process

The Message Push Service (MPS) routes push notifications through different backend systems depending on the target device platform. This topic describes how MPS handles device registration, user binding, and message delivery for Android devices in the Chinese mainland, iOS devices, and Android devices outside China.

MPS uses the mPaaS Mobile Gateway Service to call the Remote Procedure Call (RPC) gateway for device registration, user binding, and third-party channel binding. The push flow then diverges by platform.

Basic concepts

• Device ID (token): A unique identifier that MPS assigns to each client device and uses to target message delivery.

  • Android devices use a persistent connection for message push.

  • iOS devices use the Apple Push Notification service (APNs) for message push.

• Push mode: MPS supports three push modes:

  • Device ID-specific push

  • User ID-specific push

  • Broadcast push without specifying any identifiers

    Note

    All three modes ultimately resolve to device IDs inside the system. User ID-specific push simplifies integration with your business systems: user IDs are mapped internally to device IDs, so you must bind user IDs to device IDs before sending user-targeted pushes. Bind the user ID to the device ID on login, and remove the binding on logout.

• Third-party push: Vendor-channel push that can guarantee a high arrival rate. During SDK initialization, calling the init method requests device IDs from both mPaaS and the third-party platform. Both IDs are returned via callback.

  To activate third-party push, call the report API to upload both the mPaaS device ID and the third-party device ID to Mobile Push Core, linking the two IDs. Without this step, the push falls back to the standard mPaaS channel.

Process

MPS uses two backend components:

• Mobile Push Core (Pushcore): handles service logic and exposes APIs to your server.

• Mobile Push Gateway (Mcometgw): maintains persistent connections with Android devices.

Select the flow for your target platform:

• Android devices in Chinese mainland

• iOS devices and Android devices outside China

Android devices in Chinese mainland

For Android devices in the Chinese mainland, MPS uses a self-built gateway (Mcometgw). The client communicates with Mobile Push Core (Pushcore) directly over RPC through the RPC gateway.

The flow is as follows:

• On app start, the client establishes a persistent connection with Mcometgw. If the connection request does not include a device ID, Mcometgw issues one.

• If the device is configured for a vendor channel (Xiaomi, Huawei, or similar), the vendor SDK initializes, establishes a persistent connection with the vendor's push gateway, and retrieves a vendor-specific device ID.

• The app calls the device report RPC API and reports the third-party device information.

• The user logs in to the app on the client.

• Your server receives the login request and, on successful authentication, can send a user-device binding request to Pushcore.

• Your server sends a push request to Pushcore.

• Pushcore receives the push request and routes it based on push mode:

  • For device ID-specific push, Pushcore calls Mcometgw directly to deliver the message.

  • For user ID-specific push, Pushcore resolves the device ID from the user ID in the request, then calls Mcometgw to deliver the message.

• Mcometgw delivers the message to the client.

• The client sends a delivery receipt to Mcometgw confirming receipt. If you configured a callback API, Pushcore forwards the delivery receipt to your server.

• When the user logs out, the client calls the unbinding RPC API to remove the user-device binding.

iOS devices and Android devices outside China

For iOS devices, the push gateway is APNs. For Android devices outside China, the push gateway is Firebase Cloud Messaging (FCM). The flow below uses iOS as the example; the Android-outside-China flow follows the same pattern with FCM in place of APNs.

The client communicates with Mobile Push Core (Pushcore) over RPC through the RPC gateway.

The flow is as follows:

• The client obtains the iOS device ID.

• The client calls the device report RPC API to upload the device ID to Pushcore through the RPC gateway.

• The user logs in to the app on the client.

• On successful login, the client calls the binding RPC API to send a user-device binding request through the RPC gateway to Pushcore.

• Your server sends a push request to Pushcore.

• Pushcore receives the push request and routes it based on push mode:

  • For device ID-specific push, Pushcore calls APNs directly to deliver the message.

  • For user ID-specific push, Pushcore resolves the device ID from the user ID in the request, then calls APNs to deliver the message.

• The client sends a delivery receipt to Pushcore confirming receipt. If you configured a callback API, Pushcore forwards the delivery receipt to your server.