YAC - Firebase remote config
July 08, 2017
Part-1: Why I decided to develop a cleaner
Part-2: Why I chose Min Sdk 21 and Kotlin
Part-3: How kotlin reduced boilerplate code in YAC.
Part-4: Some tips and trips about working with Kotlin.
This part starts a 3 part sub-series about my developing experience about YAC. And in these 3 parts I will focus about how I have solved some problems using Firebase, and how. In this part I will discuss about how Firebase remote config solves couple of interesting problem in interesting ways.
YAC does frequent scanning to check any new files, scan periods currently are 12 hours for new files and 24 hours for whether given directory has any files or not. When I started writing scanning code, I wanted to determine What duration between two scan period is both quick and efficient? My assumption was to have anything between 1 hour - 12 hours for new files. I had 4-5 early alpha members who are willing to test, and In same APK I wanted to gave each of them unique values to test.
Currently you can scan 5 directories for free, I wanted to give early adopters more tabs for free. All these without having any separate apk.
The FAQ section was launched in v 0.6, but users could not ask questions till v 0.7. The code was still there since first time this feature is being developed. But I wanted to have a slow rollout to my users.Without having another apk.
As a solution to all these problem, I needed a server which can give me values. Have a web api which can give me some values regarding to above problems. When I needed to change values in App, I need to change value in my server and give updated values to client. All you need to have is A server, a database and a webservice.
But there are couple of problems with this approach. First these webservices give all the data by reading from a database or config file stored somewhere in server. To make these webservice return different values based on different condition (true for some users, false for others) it’s a different task in itself. And Slow rollout (changing values for random % of users) is also another manual task, which many apis can not do. And even if there is some code which can do that, I still need a server. Not only a machine, but a server software like node js. And problem here is I didn’t have a server and even if I did, I still don’t know much about handling one. That’s where firebase comes handy for solo developers like us.
When Firebase launched it’s new avatar in Google I/O 16. I was bit sceptical about it’s longetivity, because Parse happened. But I was easily convinced that Remote config is the thing I want. The firts thing I did after I/O 2016 was to implement Remote Config SDK. My idea of what should be there in first alpha was just taking shape, and having remote config helped me a lot. From providing simple solutions to having more complex solutions for problem described above became more easy as I kept playing with remote config. Here is how I solved each of my problems.
Let me tell you one thing here. Analytics is a key here. Every data you feed to analytics, will open possibilities to create as many conditions for Remote Config and FCM. So I fed analytics with many properites. For the record I fed analytics about every user interaction (whether button pressed, new tab created, faced any error etc…) without identifying user data and even File and directory name.
And these data helped me solved the problems stated above. For scanning time testing (Problem 1 above), I created a user property which picks a random number from 1-5, and based on that I created 5 conditions with 5 different values. My default value to scan was 12 hours from start. Based on that when they start app (sometimes after) I published the values, they can see different scan timings (2,4,6,8 and 12 hours respectively for each tester). The test ran for a week, and after that I reverted to default values using remote config.
For giving more tabs, it’s nearly the same. Shortly after publishing the app in Play store, and before starting new work, I increment version code and have new version name. Apart from using a boolean user property, which is only true in debug builds, I added one more condition of having a specific version code. Thus having more then 5 tabs is only possible in debug builds I test and given to 2 close family members.#2
And for slow rollout using remote config. I have followed this post from Rebecca Franks.
I recommend you to read the post, but still for tl;dr lovers, here is the gist: Create a default value in console with
false value. Define a condition, in
Applies if... use
Users in random percentile, and put a small value there. Change the value for this condition as
true and rollout.
Once you’re happy with initial results, increase the percentage. And once you have full confidence, remove the condition entirely and change default value to
true. Within 12 hours of initial publishing, your clients will have got these updates.#1
comments powered by
If how and when to load remote config values is a question, I recommend watching this video from Firebase. Though this video is from iOS series, but content here applies as a general strategy.
I was planning to allow users to more tabs in early beta versions, but it turned out only 2 users ended up having 4 tabs. Apart from me, I had max 10 users having more then one tab. This was because a basic UX problem in the App. I am still open to allow users to have more tabs, and it will be live once I solve that UX prblems.