Firebase Remote Config

Overview

Thinking to have good control over your app even after the app is released into the wild? You have hit the correct link, my friend.
We always want to keep our users more engaged with our app as possible. As a user, I’ll probably not stick around with an app that is the same as it was a year ago. Providing regular updates play a major role here. But re-configuring/re-designing an app at regular intervals can be too costly. Google’s Firebase to the rescue!
For those who are not familiar with Firebase, it is a platform for mobile app teams to develop, grow and sustain in the app-world. It has all the app-tools that one can think of. From analytics to A/B testing for app search optimization, they have got it all. The tool that’ll be useful to solve our issue is Remote Config.

What is Remote Config?

Remote config can be thought of an API or cloud service that provides the app with dynamic parameters based on which the app can be configured. Speaking practically, suppose an app has a red theme and we need to change the theme to blue without re-developing it. To achieve this, we’ll define a parameter for the theme in remote config console, the app will fetch the parameter from the console when it is launched and if programmed correctly, it’ll change its theme in runtime based on the value of parameter received. This will make the app-theme completely dynamic as we have control over the parameter.
This is just one simple use case of remote config. It can be used in million other ways, depending on app requirements. Let me elaborate it with a practical approach. I’ll demonstrate a scenario wherein a user needs to forcefully update the android app if an update is available.

Practical

Create a project and add firebase support into it. As I don’t wish to get into details to make this post longer, you can refer this link for it.

To add remote config into the app, add following line in app’s gradle file.

implementation 'com.google.firebase:firebase-config:16.1.2'

As app updates are controlled by version number, the dynamic parameter for this demo is the app version. Let’s define it in the firebase console.

1. Go to remote config section in firebase console and click on Add your first parameter.

2. Define name of your parameter and its value. In my case, I have app_version and 1.0 respectively.

3. Don’t forget to publish the changes.

Now, we need to fetch the parameter value in the app. A good place to write this code will be Application class as it executed in the very beginning when the app gets launched.
Add following code in application class’ onCreate( ) method

class BaseApp : Application() {
    override fun onCreate() {
        super.onCreate()

        val remoteConfig = FirebaseRemoteConfig.getInstance()

        val remoteConfigMap = mutableMapOf<String, String>()
        remoteConfigMap[parameterKey] = getCurrentAppVersion(this)

        remoteConfig.setDefaults(remoteConfigMap as Map<String, Any>?)
        remoteConfig.fetch()
                .addOnCompleteListener { task ->
                    if (task.isSuccessful)
                        remoteConfig.activateFetched()
                }
    }

    companion object {
        val parameterKey = "app_version"
        fun getCurrentAppVersion(context: Context): String {
            try {
                return context.packageManager.getPackageInfo(context.packageName, 0).versionName
            } catch (e: PackageManager.NameNotFoundException) {
                e.printStackTrace()
            }
            return ""
        }
    }
}

The above code basically fetches parameter from remote config and stores its value with the key that is set in FirebaseRemoteConfig object. Remember, the key should match with the parameter name defined in remote config (here, app_version)

We need to compare the fetched value with the current app version of the app. The code for it is written in launcher activity of the app (shown below). If the fetched value of version and the current version are not the same, it implies that the app-update is available and we should take actions accordingly, redirecting the user to play store, for instance.

class MainActivity : AppCompatActivity() {

   private lateinit var currentAppVersion: String
   private lateinit var playStoreAppVersion: String

   override fun onCreate(savedInstanceState: Bundle?) {
       super.onCreate(savedInstanceState)
       setContentView(R.layout.activity_main)

       currentAppVersion = BaseApp.getCurrentAppVersion(this)
       playStoreAppVersion = FirebaseRemoteConfig.getInstance().getString(BaseApp.parameterKey)

       tvVersion.text = "v: $currentAppVersion"

       if (isUpdateAvailable()) {
           //stuff for redirecting user to play store

           val alertDialog = AlertDialog.Builder(this).setTitle("App update is available v: $playStoreAppVersion")
                   .setCancelable(false)
                   .setNegativeButton("Ok") { p0, p1 -> finish() }.create()
           alertDialog.show()
       }
   }

   private fun isUpdateAvailable(): Boolean {
       return !playStoreAppVersion.equals(currentAppVersion, true)
   }
}

Here, an alert dialog will be shown, if the app update is available.
It may be stating the obvious, but we need to edit the parameter value in remote config after we release the app update and change it to latest app version.
That’s it. It’s a doddle, isn’t it?

Credits: medium.com

The gif below shows the complete process on the user’s side: the app that is up-to-date and the app after the value of the parameter is changed.

Please note: Here, I have cleared app’s data to have immediate parameter-change effects. The effects can be achieved normally but it might take a while.

Conclusion

This feature of firebase can be very handy when it comes to dynamic apps. We can have apps that change their appearance, their features, and the UX over time. This is a strong weapon to grow and retain the user base of our apps.