Push通知機能の実装をしていて、ユーザーごとの通知設定情報(通知種類ごとの設定ON・OFF)をクライアント側かサーバー側どちらに持つべきか悩みました。結果としてサーバー側で持つことになったのですが、今回はその背景についてお話したいと思います。
なぜサーバー側に持つべきなのか
当初の想定
通知機能の実装にあたり、当初はクライアント側に通知設定情報を持っておこうと考えていました(UserDefaultとかに保存)。そして、通知が来たタイミングで設定情報を見て受信制御を行うというのが当初の想定でした。しかし、通常の通知タイプでは受信を行った際に何か処理を挟むといったことはできなくて、上記のようなことを行いたい場合にはバックグラウンドプッシュ(サイレントプッシュともいう)という通知形式を使用する必要があります。ただこの通知形式は注意が必要です。
バックグラウンドプッシュの仕様
バックグラウンドプッシュはアプリがバックグラウンド状態からでも、通知を受信して何かしら処理を行った後に通知を実行(自分でローカルpushを組み立てる必要あり)させることができます。
ただこの通知形式も、バックグラウンド状態で通知を受け取ろうとした場合、色々と制約があって具体的には以下のようなものが存在します。
- システム上、優先度が低く扱われるので必ずしも即時で実行されるとは限らない
- 通知数に限りがある(1時間に2〜3回程度まで)
- ユーザーによって明示的に終了(ホームボタンダブルクリックからアプリをスライド等)した場合、通知を受け取ることができない
結論
フォアグラウンド時は何の問題もなく通知を受け取ることができますが、バックグラウンド時には上記の制約が付きまとうので、確実に通知を送りたいといった状況の時は不向きです。今回通知で実現したかったのは、新着コンテンツが配信されたタイミングで確実にお客様へ通知を送りたいというものだったので、バックグラウンドプッシュでは実現できないということが分かり、途中で通知設定情報をサーバー側に持たせる方針へ切り替えました。設計段階で気付くべきだったのですが、学びになったとポジティブに捉えるようにします。
終わりに
一口に通知といっても色々な通知タイプが存在し、それぞれに制約だったり特徴があるので、それを理解した上で通知機能を実装することが大事なんだなと感じました(当たり前の話)
この辺りは引き続き勉強していきたいと思います。