12
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Parse.comからNIFTY Cloud mobile backendへプッシュ通知を移行する際の注意点

Last updated at Posted at 2016-02-24

 Parse.comのサービス終了が予告されています。

 mBaaSサービスの移行先についてはこちらこちらなどで既にまとめられていますので、この記事ではParse.comが提供している機能のうちプッシュ通知機能をNIFTY Cloud mobile backendへ移行する方法と注意点についてまとめます。

 iOS/Androidそれぞれの移行の具体的な実装は別記事をご覧ください。

移行における注意点

(1) 移行期間を設ける必要がある

 Parse.comからプッシュ通知機能を移行する場合、「Installation(配信端末)のデータ移行」と「アプリのSDK入れ替え」の2つの作業が必要ですが、注意が必要なのは「アプリのSDK入れ替え」です。

 移行期間を設けない場合は、下の図のようにあるタイミングでアプリ内のSDKと対応するバックエンドを切り替えて、プッシュ通知の配信処理も移行先で行うようになります。

移行期間無し.png

 しかし、実際のところアプリのアップデートは一斉には行われず徐々に広がっていくため、下の図のようにアプリのバージョンに依って異なるバックエンドへのリクエストが発生することが想定されます。すると、データ移行したinstallationに差分が発生し正確なプッシュ通知の配信が行えなくなる可能性があります。特にアクティブユーザーに対するセグメント配信を行っている場合は注意が必要です。

移行期間無し_問題点.png

 そこで移行期間を設けてこの問題を解決します。
 移行期間中はParse.comのSDKとmobile backendのSDKの両方を組み込んだアプリ(v2)を提供します。この期間中は、Parse.comのSDKだけしか組み込まれていないアプリ(v1)とParse.comのSDK&mobile backendのSDKの両方が組み込まれたアプリ(v2)が共存することになるので、プッシュ通知を送る際は完全なinstallationを保持しているParse.comから送ります。
 暫くの期間が経過したらParse.comとmobile backendのinstallationの件数を見比べていただき、十分に移行されたと判断したら完全移行を行います。一般的なアプリのアクティブ率を考えると100%の移行は難しいと思うので、80%や70%など適当なタイミングで完全移行することになるかと思います。
 完全移行したらプッシュ通知はmobile backendから送るようにし、Parse.comのSDKを外したアプリ(v3)を提供します。

移行期間あり.png

 この方法を採用するとアクティブユーザーに対するプッシュ通知の失敗を低減できますが、アプリアップデートしてくれないような非アクティブユーザーは取りこぼしてしまうので、移行期間中にアップデートを促したりするといいかもしれません。

(2) Android端末のInstallationがそのまま移行できない場合がある

 Parse.comからプッシュ通知機能を移行する場合、Android端末のInstallationの移行について特に注意が必要です。

 プッシュ通知の送信にあたりiOSの場合はAPNs用の証明書、Androidの場合はGCM用のAPI KeyとSender IDが必要です。installationのdeviceTokenはこれらの証明書やAPI Key&Sender IDと関連性があり、deviceTokenと関連性の無い証明書やAPI Keyでは送信することができません。

 iOS向けプッシュ通知は、Parse.comの管理画面でAPNs用の証明書をアップロードしてプッシュ通知機能を利用していたかと思いますので、同じ証明書をそのままmobile backendにアップロードすれば証明書とdeviceTokenの組み合わせが適合するため、Parse.com側に蓄積されたdeviceTokenがmobile backendでもそのまま利用できます。

APNsの場合.png

 一方、Android向けプッシュ通知に関して、Parse.comでは特に設定していない場合Parse.com側で用意したGCMの情報(Sender IDとAPI Key)を使用してプッシュ通知を実現します。この場合、GCMから取得されたdeviceToken(GCMではregistration tokenやregistration IDと呼ぶ)はParse.comが用意したGCMの情報に紐づくため、そのdeviceToken宛にプッシュ通知を送るには対応するAPI Keyが必要です。

 Sender IDは公開されているようですが(当たり前ですが)API Keyは非公開なので、Parse.comが用意したGCMの情報に紐づくdeviceTokenはParse.com以外では使えません。

GCMの場合.png

確認方法

 Parse.com側が用意したGCMの情報を使っているかどうかは以下のポイントを確認してください。

  • Parse管理画面の Settings > Push > GCM Push Credentials
    • Sender IDとAPI Keyを設定していない場合はParse.com側が用意したGCMの情報を使っている可能性があります
  • アプリのAndroidManifest.xml
    • 以下の項目が無い場合はParse.com側が用意したGCMの情報を使っている可能性があります(「YOUR_SENDER_ID」は数字の羅列)
AndroidManifest.xml
<meta-data android:name="com.parse.push.gcm_sender_id"
           android:value="id:YOUR_SENDER_ID" />

 上記の条件に合致してしまった方は、Android端末に関してParse.comからそのままInstallationをエクスポートして移行先にインポートする方法は使えない可能性が高いです。このため、自身で新たに取得したAPI KeyとSender IDでGCMから改めてdeviceTokenを取得するような実装が必要です。
 (2)に関しても(1)で挙げた移行期間を設ける方法を使うことで解決できます。移行期間中はParse.comでプッシュ通知を送り、その間にmobile backendに改めて取得したdeviceTokenを蓄積するのです。

関連リンク

12
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?