Firebase Remote Config Realtime API を試してみて気になった点
はじめに
Firebase Remote Config Realtime APIを試してみました。
従来のRemote Configではフェッチ回数に制限があり、値を変更しても反映されるまでに時間差が発生することがありましたが、これが解消できるのであれば早く移行したいと考えています。
実装方法については公式ドキュメントや他の記事でも紹介されているため、この記事では触れません。
この記事では、iOSアプリにて試しに使ってみて気になった点を書きます。
(何か発見があったわけではないので、あまり役には立たないと思います)
資料
公式ドキュメント
Google I/O 2023の動画
気になった点
従来のfetchは不要になるのか?
Realtime APIに移行した後、仕様を実現する上で不要であれば従来使っていたfetchの方法を削除しても良いかと思っていたんですが、この記事の投稿時点でのドキュメントを見ると以下のように書いてあります。
After you fetch parameter values, you can use real-time Remote Config to listen for updates from the Remote Config backend.
一度fetchを実行した後に、値をリッスンできるようになる = fetchは引き続き呼ぶ必要があるということでしょうか。
ただ、手元で試したところ、アプリの起動時とバックグラウンドからフォアグラウンドへの復帰時、それぞれでfetchを呼ばなくても設定値が変わった場合にはRealtime APIのコールバックが呼ばれていました。
挙動からすると従来のfetchは不要にも見えますが、実際のところどうなんでしょう。
接続エラーがたまに発生する
Realtime APIのコールバック引数に接続エラーが渡され、値を変更してもコールバックが呼ばれなくなることが何度かありました。
本番導入時にも発生する可能性があるのであれば、従来のfetchも残しておいたほうが安全かもしれません。
以下のissueと同じ状況に見えるので、他でも報告されていそうです。
UX上の配慮が必要
Google I/O の動画でも触れられていますが、リアルタイム反映になったとはいえ、ユーザーが今見ている画面の内容を即座に変更するのは、誤タップや混乱を招くので一般的には避けるべきです。
そのため、値自体はRealtime APIで同期しておき viewDidAppear
等のタイミングでUIに反映させるような設計が良いのではないかと思います。
取り留めもなく書きましたが、以上です。
Discussion