Fetching Firebase Remote Config parameters properly using a loading screen
One of the most powerful features of Firebase is Remote Config. With the help of Remote Config, you can not just change your production app behavior remotely at any time, but you also can easily run A/B tests. Oh, and did I already mention that it's absolutely free?
Implementing and using Remote Config is quite easy, but as I experienced it’s not so obvious how to fetch these params properly. In this article, I’m going to show you how to fetch Firebase Remote Config parameters safely and also keep your app behavior consistent. The examples were written in Kotlin with RxJava 2 for Android but the concept is relevant on the other platforms too.
If you are not familiar with the concept and basics of Firebase Remote Config, you can get more info here.
The problem
Let’s say that you are Han Solo, the pilot of Millennium Falcon. You have an application which you can use to define the target of your next flight. Just simply open the app before you start your engines, check the destination and click on the button to start your journey! 🚀
Well done, have a good flight to Tatooine! 👽
But as the application owner, you have a concern: What if most of your users are more adventurous and prefer another destination more? For example, maybe they want to visit the Death Star.
No worries, we can change the behavior of our app with Remote Config! We will set Tatooine as the local default value in our app, but we can override this behavior by setting a value that we load up and apply through Remote Config.
The code below shows how to initialize Remote Config and then fetch the parameters. In the final step, we set the fetched target as the text of the button.
The result is the following:
It works, but as you can see the text of the button starts as the default value until new data arrives from the server, which can take seconds. It’s a pretty bad user experience, you should avoid this inconsistency.
A better way
In an official Firebase blog post, you can see different strategies for Firebase Remote Config loading. I prefer this one:
In this case, the application can work with the latest parameters simply by waiting until values are retrieved before proceeding. Since many applications perform long initialization tasks on start, putting this fetching mechanism at the start and then putting it all behind a loading screen is a good strategy. The chart also talks about a loading screen, which will be a splash screen in our case.
When the app opens and the splash screen starts, we want to:
- Run Remote Config parameter fetching and our long-running init task parallel and…
- Navigate forward if both streams terminate either with success or failure.
We use Completables (from the reactive world), because we’re only interested in success or failure. In this case, what we need is Completable.mergeArrayDelayError(), because it waits until every stream ends even if at least one of them fails.
It’s also recommended to set a timeout and terminate the stream otherwise you can be stuck on the splash screen for a very long time.
The doSomeOtherInitStuff() method just simply simulates the initialization tasks (e.g. init app from the cache, get data from a server, init third-party SDKs, etc.) and as I already mentioned, it returns with a Completable.
The other method is RemoteConfigUtil.initAndFetch(). First, we create a Completable where we initialize Remote Config with the defaults (which is Tatooine in this case) and then we start to fetch the values from Firebase (the Death Star, if you remember).
We also set an expiration time in seconds for the Remote Config cache. It means that new values won’t be fetched until the given amount of time has elapsed. The idea behind this is that changing Remote Config parameters usually happen quite rarely so it’s not necessary to fetch them every time your app starts up. Of course, during development we don’t want to wait until the given time elapses, that’s why we check for isDeveloperModeEnabled.
If the new values arrive, they won’t be “live” automatically, so we also call activateFetched() to activate the values.
Finally we just simply return either onComplete() or onError().
And that’s it! 😎 Look at the result:
If you want to see the code snippets in context, you can find and get the project on GitHub.
Also, feel free to ask or add observations with a response below! 👂
I usually tweet about tech, leadership, product and self improvement. Don’t hesitate to follow me! 👊
