What can we do with Firebase Remote Config?

So in a nutshell, Remote config essentially allows us to publish updates to our users immediately. Whether we wish to change the colour scheme for a screen, the layout for a particular section in our app or show promotional / seasonal options — this is completely doable using the server side parameters without the need to publish a new version.

We can even do this for a selected group of users, allowing us to change our chosen parameter for segmented users, application versions, Audience groups from Firebase Analytics, user language and more. This gives us extremely flexible control over who sees these changes. Alongside these, we can also use Remote Config to A/B test our changes with random percent targeting from Firebase Analytics or even feature switch when shipping new components within our application.

Remote Config gives us the power to:

Quickly and easily update our applications without the need to publish a new build to the app / play store. For example, we could easily switch out a rebuild of a component in our application for a select set of users based on the conditions that we specify.

We can effortlessly set how a segment behaves or looks in our application based on the user / device that is using it. For example, we may wish to switch out a component for users in Europe than one that may be shown for users in the US.

Following on from the above, we can use Remote Config to A/B test parts of our applications with a defined set of users before you decide to release something to your entire user base.

Remote Config Process Flow

Remote Config works by primarily using in-app defined values to decide how the it is you’re configuring is to be configured. Then using the Firebase Console we can alter the values of these remotely, which will then cause the configuration to be changed for our defined set of users. Remote Config itself essentially only requires four simple steps in it’s setup and maintenance flow:

Parameters, Rules and Conditions

Within Remote Config we define key-value pairs which are known as parameters. These parameters are then used to define the configuration values that are to be used within our app — such as the colour of a component, the text to be displayed in a view or even using a property of the user or device to determine what component should be displayed.

And to cover cases when these parameters may not be set on or available from the server, we also provide default values within our application.

This key-value pair provides our application of what the parameter is for (key, the identifier) and the how for what it is which we’re applying the configuration to (value, the configuration).

key — The key is a String used to define the identify for the parameter

— The key is a String used to define the identify for the parameter value — The value can be of any other data type and is used to represent the value of our defined parameter.

Conditions

Conditions are a collection of rules that we can use to target specific app instances —for example, we may wish to only make configuration changes for users who are female or for users who don’t have a paid-for plan. If all of the rules that are specified for a condition are satisfied, then the configurations are applied to the app instance.

The conditional value itself is also represented as a key-value pair, it’s made up of:

condition — The condition to be satisfied for the value to be used

— The condition to be satisfied for the value to be used value — The value to be used if the condition is satisfied

We can use multiple conditional values for each parameter that we define in our Remote Config setup, this allows us to declare multiple rules which much be satisfied for a parameter value to be applied to an application instance.

Priorities

If we do have multiple conditional values setup, then how does our application know which value to use? Well, Remote Config uses a collection of rules to specify which value is to be retrieved from the Remote Config Server as well as the actual value to be used within an app instance.

When we request the value from the server conditional values are applied to determine if the given application instance satisfies any of the conditions that have been defined. If only a single condition is satisfied, then the value for it is returned. On the other hand, if multiple conditions are satisfied then the one with the highest dominance (basically, the one at the top of the list in the Remote Config Console) is returned. However, if there are no conditions values that are satisfied then the default value defined on the server is returned. Note: If this default value is not defined then no value is returned when requested.

So we have all of these values set within our app and also within the Remote Config console — how does the Remote Config SDK know which one is to be used? Well, this is where the set of priority rules come into play. Both the client and server-side has a defined set of rules — the server needs to decide which value should be returned, and then once the app receives the value from the server it needs to know whether to use that or one of the values defined in the application itself. This definition of these rules looks like so: