Mobile Platform as a Service:Message push process

After integrating the Message Push Service (MPS), the client uses the mPaaS Mobile Gateway Service to call the Remote Procedure Call (RPC) gateway for device registration, user binding, and third-party channel binding, so as to implement message push by devices or users. The message push processes are different in different device platforms. The following sections introduce message push process through RPC on different device platforms.

Before acquainting yourself with the push process, you need to know some basic concepts involved in message push.

Basic concepts

• Device ID (token): MPS assigns a unique identifier to each client device and determines the target of message push based on the identifier.

  • For Android devices, a persistent connection is established for message push.

  • For iOS devices, the Apple Push Notification service (APNs) is used for message push.

• Push mode: MPS provides the following push modes:

  • Device ID-specific push

  • User ID-specific push

  • Broadcast push without specifying any identifiers

    Note

    No matter which mode is adopted, mapped device IDs will be eventually generated inside the system. User ID-specific message push offers convenience in interworking with your business systems. As user IDs are eventually mapped to device IDs, you must bind user IDs to device IDs. The recommended method is to bind the user ID to the corresponding device ID upon user login. When the user logs out, the binding relationship is removed.

• Third-party push: Third-party push refers to pushing by vendors, which can guarantee a high arrival rate. During the initialization process of calling the init method, the client applies for device IDs from both mPaaS and the third-party platform. Device IDs are then returned by mPaaS and the third-party platform in the callback.

  If you want to use a third-party push, you should call the report API to upload both mPaaS device ID and the third-party device ID to Mobile Push Core, and associate the two device IDs. After the above operation is completed, the third-party device ID can be truly used, otherwise the message push is a common mPaaS push.

Process

The MPS involves two backend systems:

• Mobile Push Core (Pushcore): handles service logic and provides APIs to developers.

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

Learn about the process for integrating MPS on different device platforms:

• Android devices in Chinese mainland

• iOS devices and Android devices outside China

Android devices in Chinese mainland

The client uses RPC to directly interact with Mobile Push Core (Pushcore) through the RPC gateway. For Android devices in China, MPS provides a self-built gateway. The following figure shows the process.

Where,

• When the app starts, the client establishes a persistent connection with Mcometgw. If the connection setup information of the client does not include the device identifier, Mcometgw issues the device identifier.

• If the user enables the MPS from a third-party channel such as Mi and Huawei, and the client is a third-party device, the third-party SDK initializes, establishes a persistent connection with the vendor’s push gateway, and obtains the device ID from the third-party channel.

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

• The app user initiates a login request on the client.

• The server receives the user login request. When successfully logging in to the app, you can send a user-device binding request to Pushcore.

• The server initiates a push request.

• Pushcore receives the push request, and distinguishes the message push type.

  • If the message is pushed by device, Pushcore calls Mcometgw to send the message.

  • If the message is pushed by user, Pushcore obtains the device ID based on the user ID in the request and then calls Mcometgw to send the message.

• Mcometgw sends the message to the client.

• After the message is successfully sent, the client will confirm the receipt of the message with Mcometgw. If the user has configured a callback API, Pushcore will send a receipt to the server.

• When the user actively logs out of the app, the client calls the unbinding RPC API.

iOS devices and Android devices outside China

The push gateway for Android devices outside China uses Google Firebase Cloud Messaging (GCM/FCM) for Android, while the push gateway for iOS devices uses the Apple Push Notification service (APNs). The following takes the iOS device for example.

The client uses RPC to directly interact with Mobile Push Core (Pushcore) through the RPC gateway. The following figure shows the process.

Where,

• The client obtains the iOS device ID.

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

• The app user initiates a login request on the client.

• When successfully logging in to the app, the user can call the binding RPC API to send a user-device binding request to the RPC gateway, which forwards the request to Pushcore.

• The server sends a push request to Pushcore.

• Pushcore receives the push request and distinguishes the message push type.

  • If the message is pushed by device, Pushcore directly calls the APNs to send the message.

  • If the message is pushed by user, Pushcore obtains the device ID based on the user ID in the request and then calls the APNs to send the message.

• After the message is successfully sent, the client will confirm the receipt of the message with Pushcore. If the user has configured a callback API, Pushcore will send a receipt to the server.