Google Cloud Messaging-PHPでバックエンドを書く

チュートリアルの一環として、GCMサーバーにメッセージを送信するための本格的なクラスを作成します。

• 送信用の入力データ配列を受け取ります
• それぞれ最大4096kbを送信するためのパッケージを形成します。
• 並列リクエストでパケットを送信します。
• 答えを解析し、知っている：
  
  
  • メッセージが正常に配信されたかどうか
  • エラーの種類
  
  
  

Google Cloud Messaging-簡潔かつ明確

GCMはインスタントメッセージングサービスです。 標準のポーリングと長いポーリングの代替手段ですが、排他的ではありませんが、それらを補完します。 Googleは、メッセージが配信されることを保証しません（ただし、配信の信頼性と速度は、C2DMの祖先に比べて単純にスペースになりました）。 電話でインターネットがオフの場合、メッセージは最大4週間GCMサーバーに保存されます。 つまり、ユーザーが電話をオフにして休暇を取り、到着するとメッセージを受信しなくなる可能性があります。 そのため、GCMは、たとえば基本ポーリング-N分ごとにサーバーにhttp要求を送信するなど、信頼できる配信方法でのみ動作する必要があります。



どのAndroidアプリケーションも、GCMからのメッセージの受信者として自分自身を登録できます。 インターネットがオンになっていると、登録は数秒で行われます。 これが発生するとすぐに、アプリケーションはGCMサーバーからRegistrationIdを受け取ります。これはサーバーに送信する必要があります。 その結果、サーバーデータベースには、たとえば、RegistrationIdを含むデバイスに関する情報を格納するDevicesテーブルがあります。



デバイスがメッセージの受信を開始するには、サーバーコードがPOST要求をjson形式でGCMサーバーに送信する必要があります（通常のキー=>値を送信することもできますが、jsonをお勧めします）。 サーバー応答にはjsonも含まれます。これにより、メッセージが配信されたかどうか、配信されていない場合はどのエラーが発生したかを分析できます。

さあ始めましょう

GcmPayloadとGcmSenderの2つのクラスを作成しましょう。







GCMの用語では、ペイロードは受信者に送信するデータです。 このデータは、データキーの値に格納する必要があり、4096バイトの制限があります。 要求形式に関する詳細 。



GcmPayload-1人の受信者、したがって1つのRegistrationIdのデータモデル。 $ jsonsフィールドは、この受信者に送信されるデータを含む文字列形式のjson'ovの配列で初期化する必要があります。 チュートリアルを簡素化するために、これはクラスの外部で、たとえば次のように行われると考えています。

Gcmsender

定数とクラスメンバー

const GCM_API_KEY = 'your api key'; // Google APIコンソールページにアクセスする必要がある

const CURL_TIMEOUT = 10; // Googleサーバーのタイムアウト（秒）

const GCM_MAX_DATA_SIZE = 4096; //送信データのバイト単位の制限

const GCM_SERVER_URL = 'https://android.googleapis.com/gcm/send'; // GCMサーバーアドレス

const GCM_MAX_CONNECTIONS = 10; //同時リクエストの数



const KEY_REG_IDS = 'registration_ids'; // JSONリクエストの受信者キー

const KEY_DATA = 'data'; // JSONリクエストのデータキー

const KEY_ITEMS = 'items'; //データ配列を含むデータオブジェクトをキー入力します

const REGID_PLACEHOLDER = '_REGID_'; // JSONリクエストテンプレートのRegistrationIdのプレースホルダー

const ITEMS_PLACEHOLDER = '_ITEMS_'; // JSONリクエストテンプレート内のデータの配列のプレースホルダー



const GCM_ERROR_NOTRcture = 'NotRegistered'; //ユーザーがアプリケーションをアンインストールした場合のエラーの定数



保護された$ _template; // JSONリクエストテンプレート

protected $ _baseDataSize; //項目キー、括弧引用符などを含む初期データサイズ

コンストラクター

コンストラクターは、getPackagesメソッドで使用される要求テンプレートを作成します。 データあたり4096バイトの制限を潜在的に超えないように、テンプレートの初期データのサイズを覚えて考慮する必要があることに注意してください：{"items"：[]}

送信方法

GCMサーバーにデータを直接送信するには、このパブリックメソッドを呼び出す必要があります。 このメソッドは送信用のデータを受け入れます。これはgetPackagesメソッドによってデータパケットに変換されます-json形式の準備済みポストデータ（1パケット-1要求）で、4096バイトを超えないことが保証されます。 残りのメソッドは、素晴らしいRollingCurlライブラリの初期化です。このライブラリはcurl_multi_execを使用して作業をカプセル化し、リクエストを並行して送信し、透過的なコードを記述できるようにします。 RollingCurlをコールバックメソッドonResponseで初期化し、送信結果を分析します。 次は、データ送信自体です。

GetPackagesメソッド

このメソッドでは、クラスに渡されたペイロードの配列がソートされ、コンストラクターで作成されたテンプレートは、パケットが4096バイトの制限を超えるか、受信者のデータが終了しないまで徐々に満たされます。 ところで、この例では、1つのパケットが1つの受信者であると見なします。 これはどういう意味ですか？ たとえば、テキストメッセージが1人だけに宛てられている場合、このような規則は当てはまります。 ただし、グループ会話では、同じメッセージを複数の人に送信できます。GCMでは、registration_idsキーの値に複数のRegistrationIdを指定することでこれを許可しています。 ただし、この例では、不必要な合併症を避けるため、このケースは考慮されていません。



getPackagesメソッドに戻ります。 実際、isReadyToFlush関数はここで重要です。これは、パッケージに新しいjsonを追加すると4096バイトの制限を超えるかどうかを決定します。 はいの場合、パッケージはすぐに終了し、このjsonが新しいパッケージに追加されます。

OnResponseメソッド

メッセージを送信するだけでなく、メッセージが配信されるかどうか、また配信されない場合は、その理由を理解することも重要です。 onResponseは、sendメソッドでRollingCurlを初期化したコールバックです。 Kolbekは3つのパラメーターを受け入れます。

1. $ response-文字列レスポンス
2. $ infoはcurl_getinfo関数php.net/manual/en/function.curl-getinfo.phpの結果であり、応答httpコードから始まりアップロード/ダウンロード速度で終わるデータ転送データの配列を返します。 ただし、このチュートリアルでは、http応答コードのみが興味深いものです。
3. RollingCurlRequest $ request-リクエスト情報。 $ request-> post_dataに興味があります

関数リストのコメントはより雄弁になります。







アップデート1

jcrowは、RegistrationIdの更新中に待機する可能性がある落とし穴についてのコメントを求めます。 状況：ユーザーがアプリケーションをアンインストールし、インストールした=>再度再登録して、新しいRegistrationIdを受け取りました。 データベースには、同じユーザーの2つのレコードが既にあります。 そして、1つのレコードは古いRegistrationIdで、もう1つのレコードは新しいRegistrationIdです。 両方のRegistrationIdにメッセージを送信すると、古いものには新しいRegistrationIdが届きます。 その結果、同じRegistrationIdを持つ1人のユーザーに対して2つのエントリがあります。



その結果、データベースのRegistrationIdフィールドに一意のインデックスがある場合、エラーが発生します。 インデックスがない場合、アプリケーションユーザーは毎回2つの同一のメッセージを受け取ります。



解決策：onResponseで新しいRegistrationIdを受け取ったらすぐに、データベースでその存在を確認する必要があります。 そして、肯定的な場合、レコードの1つを削除するか、レコードと関連データの両方を他のテーブルから保持します。

次に何をする？

たとえば、メッセージが配信されたというステータスをデータベースに入れることができます。 ただし、GCMサーバーへの正常な送信は、ユーザーのスマートフォンによるメッセージの実際の受信を意味するものではないことを覚えておく必要があります。 さらに、休暇の例を思い出すと、onResponseでステータスを設定できないことが明らかになります。 それならどこ？ 選択肢は1つだけです。ポーリングでデータを受信するときにステータスを記録します。 残念ながら、ほとんどの場合、これは受信者が同じデータを2回受信することを意味します。 アプリケーションレベルで、このデータが既に受信されているかどうかを判断でき、受信されている場合は無視できます。 このアプローチの主な利点は信頼性であり、データは常に配信されます。 短所-増加したトラフィックとバッテリー消費。



公式のドキュメントを読んでいない場合は、 読むことをお勧めします。

あとがき

このチュートリアルが誰かの出発点になるだけでなく、Androidアプリケーションのバックエンドの開発時間を短縮するのに役立つことを願っています。