Firebase Remote Config: 3 lessons learned
3 important lessons learned after using Firebase Remote Config on Android
Lesson #1: Define in-app default parameter values
You can set in-app default parameter values in the
Remote Config object, so that your app behaves as intended before it connects to the
Remote Config backend, and so that default values are available if none are set in the backend. Please, don’t forget to do this.
"key" to "default_value"
Lesson #2: Retry the fetching with WorkManager
fetch() functions on
FirebaseRemoteConfig can fail if the user is not having an internet connection when invoking them. If the fetch failed, then you are going to get the following exception:
com.google.firebase.remoteconfig.FirebaseRemoteConfigClientException: The client had an error while calling the backend!
It’s a good idea to add a retry logic, so you guarantee that as soon as the internet connection is back, the fetch is executed.
For doing that, nothing better than using
WorkManager. You can configure a worker to be triggered when the device is connected to the internet and retry if there is any connection issue when fetching.
Lesson #3: Propagate Remote Config updates in real-time
Remote Config background function triggering provided by Cloud Functions for Firebase along with FCM, you can propagate
Remote Config updates in real-time. You create a function that triggers when you publish or roll back your
Remote Config template from the dashboard or the API. The template update triggers the function to send an
FCM message to let clients know that their existing config is stale and that their next fetch should be from the server:
Just follow these four steps:
1. Subscribe client app instances to an FCM topic
For targeting an
FCM message to a large group of client app instances such as your entire user base, topic messaging is the most efficient mechanism. Each app instance that should receive real-time
Remote Config updates must subscribe to a topic name like, for example,
This is going to work fine for new users, because
onNewToken will be invoked on their first app start. But not for your previous users, unless you wait until all of them have their token refreshed. So, you should also subscribe to that topic on any other place, like app startup or after
2. Create a function to send an FCM ping on template updates
You can trigger a function in response to
Remote Config events, including the publication of a new config version or the rollback to an older version. To propagate template updates in real-time, create a function that listens for template publication events, and then use the FCM Admin SDK from your function to send a silent ping to client app instances:
This function sets a
REMOTE_CONFIG_STATUS parameter, and then sends that as the data payload of an FCM message to all clients subscribed to the
REMOTE_CONFIG_PUSH topic. It also includes an analytics label, so you can see the pushes on the Reports tab in the Firebase console.
3. Set the Remote Config state on the client
When the clients receive a push with a
REMOTE_CONFIG_STATUS parameter, they should set the shared preference
true. This indicates that the Remote Config template already stored on the app is now stale due to the creation of the new, updated template whose publication triggered the function. Update your notification handler to test for this condition:
4. Fetch the Remote Config updates on app startup
Add logic to your app to force a
Remote Config fetch from the network (ignoring local storage) when
remote_config_stale shared preference is
After a successful fetching, you should mark the
remote_config_stale shared preference as
RemoteConfigFetcherWorker showed on the previous section is already doing that on lines 23 & 24.
Message delivery reports
You can evaluate whether the
Remote Config pushes reached your users. In the Reports tab in the Firebase console, pick
Data and filter by the label
- Sends: The data message or notification message has been enqueued for delivery
- Received: The data message or notification message has been received by the app.
If you enjoyed this article, you might get value out of these ones as well!
Stop generating the BuildConfig on your Android modules
Why generating the BuildConfig class is a bad idea
Say bye-bye to Android Jetifier
6 steps to stop using Jetifier and increase your build speed