• このエントリーをはてなブックマークに追加
  • このエントリーをはてなブックマークに追加

Androidのプッシュ通知の基盤であるGCM(Google Cloud Messaging)では、配信先の端末をレジストレーションIDで識別しています。

端末ごとのレジストレーションIDは変更される場合があり、変更前後のレジストレーションIDが共に配信対象となると、プッシュ通知が重複して配信される場合があります。

これに対してGrowth PushではレジストレーションIDの変更に対する対応をクライアントサイドとサーバサイドの双方でおこなっています。

  • クライアントサイドでの対応
  • サーバサイドでの対応

クライアントサイドでの対応

Growth PushのAndroid SDKは、レジストレーションIDの変更をクライアントアプリ内で検知し、Growth PushのサーバへレジストレーションIDの変更要求をします。

https://github.com/SIROK/growthpush-android

この処理のフローは次のようになっています。

  1. ユーザーがアプリを起動します。
  2. レジストレーションIDを取得します。
  3. 端末に保存したレジストレーションIDと比較して変更を検知します。
  4. レジストレーションIDが変更されていた場合は、Growth PushサーバにレジストレーションIDの上書きを要求します。

このような手順を踏むことによって、レジストレーションIDが変更された場合に、古いレジストレーションIDを新しいレジストレーションIDで上書きすることで、配信対象に新しいレジストレーションIDのみが入るようにしています。

サーバサイドでの対応

通常はクライアントサイドでの対応で十分ですが、アプリのアンイストールとインストールを繰り返すなどによって、Growth Pushの配信対象に古いレジストレーションIDと新しいレジストレーションIDの双方が登録されてしまう場合があります。

この対応のために、プッシュ通知の配信時にサーバサイドで、重複の除去をおこなっています。

  1. プッシュ通知を配信します
  2. レジストレーションIDの変更があるか判定します。
  3. 変更があった場合、古いレジストレーションIDをもつクライアントは無効(inactive)のステータスにし配信対象から除外します。
  4. 新しいレジストレーションIDが未登録の場合は、配信対象から除外するのではなく、上書きすることで次回以降は新しいレジストレーションIDを使用するようにします。

複数のプッシュ通知が届く場合

このようにクライアントサイドとサーバサイドの双方で対処をおこなっていますが、アプリのアンイストールとインストールをおこなっている端末の場合に、複数通のプッシュ通知が届く場合があります。

これは、サーバサイドの重複除去処理を、実際にプッシュ通知の配信をおこなった結果を元におこなっているためです。配信が完了すると、重複する端末は無効(inactive)となるので、次回の配信以降では重複して受信しなくなります。