Exploring Firebase Remote Config
In 2010, when I have started to develop Android, I also started to write a blog to share my problems in Android. I wrote on my blog about one or two years. After this period, I have closed the blog and gave up sharing.
On 22nd March, I made a presentation about Firebase Remote Config and decided to start writing and sharing again with this topic. In this article, I’ll try to explain one of the important products of Firebase.
After Google acquired Firebase, Inc. in 2014, I needed to use Firebase in my personel projects and the projects in the company I worked for. In this period of time, lots of products are added into Firebase to develop mobile and web apps easily and Firebase Remote Config is one of these products.
Let’s start with short description of Firebase. Firebase is mobile/web development platform and provides lots of services to develop our applications. The main purpose of Firebase is to build better mobile apps and grow your business.
Firebase splits their products with developing & testing and growing & engagement.
After short description of Firebase, I want to start with answer of “What is Firebase Remote Config?”
Firebase Remote Config
- is a cloud service and placed under of developing and testing products
- provides changing appearance and behavior of your application, requires no publication nor store permission and changes are applied without user update
- can be managed from Firebase Console or Remote Config REST API
The second question is: “What can we do with Remote Config?” Answer of this question is summarized below with three key capabilities:
1st one is that you can publish your changes quickly and change your application’s defaults. For example, there is one simple image in your application to promote your products during new year period and you want to hide the image at the end of this period. You can control the image visibility with Remote Config values without waiting app stores’ permission or user updating.
2nd one is you can customize your application appearances for different user segmentation with defaults values like free/paid user or according to user properties of Google Analytics for Firebase. Think about that you have an application and know gender of users, and you set user’s gender as an user property with Google Analytics for Firebase. After that you can change your application’s theme with darker colors for men and lighter colors for women with Remote Config whenever you want .
3rd one is also an important capability of Remote Config. You can improve your application with A/B testings. For example, you want to change colors of buy button in your application but you don’t know its impact on your conversion rate. With Remote config, you can display new color of button to random percentile of the users and then decide the selection of the color which has positive effect of conversion or not.
Remote Config client SDK can be implemented easily to the application. After the implementation, the SDK will fetch safely and efficiently from server-side in a very short time and cache the values for you and new values can be used if they are activated. These values must be same name in the application and on the service-side and also these values can be changed from Firebase Console and Remote Config REST API.
When you want to implement Remote Config, you can use the below path:
- decide which part of the application is updated with Remote Config
- add parameters/define conditions (service-side)
- develop the app (client-side)
- update parameters/conditional values which of them you want to change
DON’T use Remote Config with user authantication to make update content.
DON’T store confidential data.
DON’T change the requirements of application’s platform.
Basically, Firebase Remote Config’s working strategy depends on three main terms: Parameters, Conditions and Rules. In this part, I will explain what these terms are and how they can be created on Firebase Console, with short videos.
Parameters
Parameters are basic key-value pairs to control your app-defaults. All keys and values are String type in the console, and also it’s supported casting values by client SDK with getBoolean(), getByteArray(), getDouble(), getLong(), getString() methods. On below video, you can see how to add a parameter and publish it quickly.
Conditions
Conditions can have one or multiple rules (explained below) and is used to target group of application instances. When all rules evaluate true, then the condition evaluate true and return the value of related parameter. Same conditions can be shared with different instance of parameter and then target group of app instance will be same for different parameters. How a condition can be created is displayed on below video.
Rules
Rules are used to trigger a condition and create different application instances. For a condition, you can add one or more rules and the values of these rules can be string or integer. Lots of rule types are supported and these types and supported operators are listed below:
You can see how to add rules to a condition within this video:
Remote Config supports to update more than one values in the same time. When you update one or more values on Firebase Console, the updated parameters and conditions will be bold and not updated until you click “Publish Changes” button. After publishing, changed values will be updated according to server-side and client-side priorities list.
Server-side Priorities
I will try to explain server-side priorities simply and you can see how to update sorting of conditions on video which is below the list.
- Only one condition updated: If the condition evaluates true, then parameters that are related with this condition is applied.
- One more conditions updated: When more than one conditions have been updated and evaluate true, the condition at the top of the Conditions tab on Firebase Console is firstly updated. You can change sorting of the conditions as I mentioned above.
- When a value that hasn’t any conditional values or has no condition evaluate true, then server responses with default values.
- If values that are wanted to fetch, aren’t exist or No value is set as default value, then no value is provided from server.
Client-side Priorities
- If the values are fetched and activated, then the app uses these values.
- If the values are non-fetched, then default values are used.
- If the values are fetched but not-activated, then default values are also used.
- If there is no in-app defaults, in this time static type of values are used (0, false, etc.).
Below graphic is taken from Firebase Docs and tries to summarize priorities of service and client.
Limitations are one of the most crucial parts of using Remote Config. If you want to use Remote Config without any problems, you need to consider these limitations.
- 2000 → Max parameters count
- 100 → Max conditions count
- 256 → Max chars length of one parameter key
- 500.000 → Max chars for total parameters values
- _ / A-Z / a-z → Parameter keys have to start with
- 0–9 → Parameter keys may contains
The most important advantages of Remote Config API can be summarized under three main topics:
- New applied parameters are under your control: You can update or change your default values without update or no wait app store permissions, whenever you want.
- In-app default values: This feature is also an important part of Remote Config. Because, these values are applied immediately. If your application has no connectivity or any problem to fetch values, then these values will survive your user experience.
- Efficiently fetching and activating values: The values are safely and quickly updated. When you use Remote Config, you have no need to add logic for callbacks or any handler mechanism to catch new values.
One of the strongest part of Remote Config is its’ client library. It is very easy to use and fetch new values from remote server. The library has singleton instance to manage all cycles of this implementation. When you use this implementation, you have all advantages of controlling application defaults without any update. You can create as many parameters as you need and add as app-defaults. Remote Config Library has three types of stores to keep and update parameter’s values:
- Default config: This config is previously setup and called as app-defaults.
- Active config: The values that are in active config, are used actively. These values can be gotten from get methods of client library.
- Fetched config: Fetched values are recently fetched from Remote Config, not used actively.
The following diagram visualizes types of stores and the architecture of Remote Config API:
Implementation of Firebase Remote Config for Android is very easy like other platforms. I don’t explain the implementation in deep details because of its easy implementation. I think it is clear to understand how to implement Remote Config from following code snippets with comment lines.
There are lots of strategy to implement and use Remote Config’s values in the application. In my opinion, following strategies are most common ways to use Remote Config and I have realized this while watching the video that is in Firebase Remote Config API Overview page.
Remote Config REST API has been finally announced on 13th of March, 2018. Just for now, I haven’t try the REST API yet, because of this, I want to pass shortly with mentioning main advantages of the API. If I start to use REST API, I want to share a story about this. When you use Remote Config REST API, you can;
- schedule your parameters update,
- batch import config values,
- take your own version history,
- change your configs automatically.
Lastly, I want to mention another powerful feature of Remote Config. While using Firebase Remote Config to make A/B tests, you can decide properly which feature is the best way for your user experience and which business goal is the best way to optimize the user experience.
One of the big advantages of Remote Config and the other products of Firebase is that they work with each others. Remote Config works with Google Analytics for Firebase simultaneously, and it uses the power of Analytics to randomize, segment and target users.
For example, you can simply set user property with FirebaseAnalytics instance and then you can use this property to change in-app defaults with using conditions on Firebase Console.
That’s all! I tried to explain what Firebase Remote Config is and how it can be used in your projects. I developed a sample project about this subject; you can find the project on GitHub. After five or six years, I started to write something again. If you have any thoughts or comments, I want to hear your words.
