3 important lessons learned after using Firebase Remote Config on Android

Maxi Rosson

Follow

Mar 24 · 4 min read

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.

Firebase.remoteConfig.apply {
    setDefaultsAsync(mapOf(
        "key" to "default_value"
    ))
}

Lesson #2: Retry the fetching with WorkManager

ThefetchAndActivate() or 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

Using the 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, REMOTE_CONFIG_PUSH:

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 afterFCM registration.

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 remote_config_stale as 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 true.

After a successful fetching, you should mark the remote_config_stale shared preference as false. The 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 REMOTE_CONFIG_PUSH

• 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.

This data is available for all messages with a notification payload and all labeled data messages. To learn more about labels, see Adding analytics labels to messages.

If you enjoyed this article, you might get value out of these ones as well!