56
36

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.

Firebase Remote Configのキャッシュにおけるキモ

Last updated at Posted at 2017-05-05

キャッシュ

RemoteConfigのfetchは毎回は行われず、基本的に一度fetchしたらキャッシュ時間内では、再度fetchが行われることはない。デフォルトは12時間である。

参考:
public Task fetch (long cacheExpirationSeconds)
Firebase Remote Config の Android 向けサンプルアプリのチュートリアル

キャッシュ時間0とした場合の制約

仮にキャッシュ時間を0とした場合でも、1時間以内でfetch回数は5回までと制限されており、それ以上のfetchは自動的に遮断され、キャッシュされた値がそのまま利用される。
DeveloperModeをtrueにすると、最大10人までこの制約は解除される。

参考:
Github: Firebase RemoteConfigサンプル
[[Android] Firebase Remote Configを試してみる]
(http://qiita.com/hymmr/items/2fc647db04d3861cd17b)
Firebase Remote Config の Android 向けサンプルアプリのチュートリアル

キャッシュの問題点

上記を考える上で、もし仮にキャッシュ時間内に以下の2つの操作が行われた場合、それぞれ以下のような問題が発生する

  1. RemoteConfig上の値がWebコンソール上で更新される
    → リアルタイムで更新されない

  2. アプリ内部でユーザープロパティの値など条件が変更される
    → fetchが走らないので、設定した値が不変

また、RemoteConfig値は、各値ごとfetchではなく一括ですべての値がfetchされるため、それぞれの値でfetchする/しないを決めることが難しい。

対策

もし仮に以上のような問題が発生する場合、やはり以下のように現状対策するしかないのかなと考えている。。
① キャッシュ時間をゼロにする
② fetchはスプラッシュ部分など最低限しか実行しない
③ 仮にアプリ内部でユーザープロパティの値など条件が変更され、それについてのfetchを再度行う必要がある場合、その状況が起こりうるのはアプリ内で1回〜2回にとどめる

もっとうまいやり方がないものかとは思う。

その他考察

値不変

RemoteConfigにおいて、fetchされて各端末に設定されるConfig値は一定になる。
検証してみたが、RemoteConfig上での条件が変更されない限り、fetchを何度行ったとしてもアプリ内に保持されている値が変わることは基本的になかった。
つまり、もし仮に上記問題点にあたらない場合は、キャッシュ時間を長めに設定するのも手なのではと思われる。


記事をお読みいただき、ありがとうございました!
もし参考になったと感じましたら、どうか「いいね」よろしくお願いいたしますm(_ _)m

56
36
4

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
56
36

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?