YAC - Firebase remote config

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

Problem

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

Abstract Solution:

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.

Firebase Solution:

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

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