メッセージプッシュサービス (MPS) を統合した後、クライアントは mPaaS モバイルゲートウェイサービスを使用して、デバイス登録、ユーザーバインディング、およびサードパーティチャンネルバインディングのためにリモートプロシージャコール (RPC) ゲートウェイを呼び出し、デバイスまたはユーザーによるメッセージプッシュを実装します。メッセージプッシュプロセスは、デバイスプラットフォームによって異なります。以下のセクションでは、さまざまなデバイスプラットフォームでの RPC を介したメッセージプッシュプロセスについて説明します。
プッシュプロセスについて理解する前に、メッセージプッシュに関連するいくつかの基本的な概念を知る必要があります。
基本概念
デバイス ID (トークン): MPS は各クライアントデバイスに一意の識別子を割り当て、その識別子に基づいてメッセージプッシュのターゲットを決定します。
Android デバイスの場合、メッセージプッシュのために持続的接続が確立されます。
iOS デバイスの場合、Apple Push Notification service (APNs) がメッセージプッシュに使用されます。
プッシュモード: MPS は、次のプッシュモードを提供します。
デバイス ID 指定プッシュ
ユーザー ID 指定プッシュ
識別子を指定しないブロードキャストプッシュ
説明どのモードを採用する場合でも、最終的にはシステム内でマップされたデバイス ID が生成されます。ユーザー ID 指定のメッセージプッシュは、業務システムとの連携に便利です。ユーザー ID は最終的にデバイス ID にマップされるため、ユーザー ID をデバイス ID にバインドする必要があります。推奨される方法は、ユーザーログイン時にユーザー ID を対応するデバイス ID にバインドすることです。ユーザーがログアウトすると、バインディング関係は削除されます。
サードパーティプッシュ: サードパーティプッシュとは、ベンダーによるプッシュを指し、高い到達率を保証できます。
initメソッドを呼び出す初期化プロセス中に、クライアントは mPaaS とサードパーティプラットフォームの両方からデバイス ID を申請します。その後、デバイス ID は mPaaS とサードパーティプラットフォームによってコールバックで返されます。サードパーティプッシュを使用する場合は、
reportAPI を呼び出して mPaaS デバイス ID とサードパーティデバイス ID の両方をモバイルプッシュコアにアップロードし、2 つのデバイス ID を関連付ける必要があります。上記の操作が完了すると、サードパーティデバイス ID を実際に使用できます。そうでない場合、メッセージプッシュは一般的な mPaaS プッシュになります。
プロセス
MPS には、2 つのバックエンドシステムが関係しています。
モバイルプッシュコア (Pushcore): サービスロジックを処理し、開発者に API を提供します。
モバイルプッシュゲートウェイ (Mcometgw): Android デバイスとの持続的接続を維持します。
Xiaomi、Huawei などのサードパーティプッシュプラットフォームへのアクセスが設定されているデバイスの場合、クライアントはサードパーティプラットフォームからもデバイス ID をリクエストします。サードパーティプッシュチャンネルは、report API を呼び出して、返された mPaaS デバイス ID とサードパーティデバイス ID をバインドした後にのみ使用できます。一般的なデバイスの場合、mPaaS によって返されたデバイス ID のみが使用されます。
さまざまなデバイスプラットフォームで MPS を統合するプロセスについて説明します。
中国本土の Android デバイス
クライアントは RPC を使用して、RPC ゲートウェイを介してモバイルプッシュコア (Pushcore) と直接対話します。中国の Android デバイスの場合、MPS はセルフビルドゲートウェイを提供します。次の図は、そのプロセスを示しています。
ここで、
アプリの起動時、クライアントは Mcometgw との持続的接続を確立します。クライアントの接続設定情報にデバイス識別子が含まれていない場合、Mcometgw はデバイス識別子を発行します。
ユーザーが Mi や Huawei などのサードパーティチャンネルから MPS を有効にしていて、クライアントがサードパーティデバイスである場合、サードパーティ SDK が初期化され、ベンダーのプッシュゲートウェイとの持続的接続が確立され、サードパーティチャンネルからデバイス ID を取得します。
アプリはデバイスレポート RPC API を呼び出し、サードパーティデバイス情報を報告します。
アプリユーザーは、クライアントでログインリクエストを開始します。
サーバーはユーザーログインリクエストを受信します。アプリに正常にログインすると、ユーザーとデバイスのバインディングリクエストを Pushcore に送信できます。
サーバーはプッシュリクエストを開始します。
Pushcore はプッシュリクエストを受信し、メッセージプッシュタイプを区別します。
メッセージがデバイスによってプッシュされた場合、Pushcore は Mcometgw を呼び出してメッセージを送信します。
メッセージがユーザーによってプッシュされた場合、Pushcore はリクエスト内のユーザー ID に基づいてデバイス ID を取得し、Mcometgw を呼び出してメッセージを送信します。
Mcometgw はクライアントにメッセージを送信します。
メッセージが正常に送信されると、クライアントは Mcometgw でメッセージの受信を確認します。ユーザーがコールバック API を設定している場合、Pushcore はサーバーに受信通知を送信します。
ユーザーがアプリからアクティブにログアウトすると、クライアントはアンバインディング RPC API を呼び出します。
中国国外の iOS デバイスと Android デバイス
中国国外の Android デバイスのプッシュゲートウェイは、Android 用に Google Firebase Cloud Messaging (GCM/FCM) を使用し、iOS デバイスのプッシュゲートウェイは Apple Push Notification service (APNs) を使用します。以下では、iOS デバイスを例に説明します。
クライアントは RPC を使用して、RPC ゲートウェイを介してモバイルプッシュコア (Pushcore) と直接対話します。次の図は、そのプロセスを示しています。
ここで、
クライアントは iOS デバイス ID を取得します。
クライアントはデバイスレポート RPC API を呼び出し、RPC ゲートウェイを介してデバイス ID を Pushcore に報告します。
アプリユーザーは、クライアントでログインリクエストを開始します。
アプリに正常にログインすると、ユーザーはバインディング RPC API を呼び出して、ユーザーとデバイスのバインディングリクエストを RPC ゲートウェイに送信できます。RPC ゲートウェイは、リクエストを Pushcore に転送します。
サーバーは Pushcore にプッシュリクエストを送信します。
Pushcore はプッシュリクエストを受信し、メッセージプッシュタイプを区別します。
メッセージがデバイスによってプッシュされた場合、Pushcore は APNs を直接呼び出してメッセージを送信します。
メッセージがユーザーによってプッシュされた場合、Pushcore はリクエスト内のユーザー ID に基づいてデバイス ID を取得し、APNs を呼び出してメッセージを送信します。
メッセージが正常に送信されると、クライアントは Pushcore でメッセージの受信を確認します。ユーザーがコールバック API を設定している場合、Pushcore はサーバーに受信通知を送信します。