We recently faced a problem with our application getting updated and reaching slowly to people’s devices which was becoming a big issue because sometimes when you wish to push some big feature update or a major bug fix and it doesn’t reach the target audience, it’s quite frustrating. To fix this issue we wanted to implement an in-app update that is provided as a library from android. I won’t be covering the whole implementation since it’s quite simple and beautifully explained on the android developer’s website. In this article, I will be covering how to control the update type.
According to the documentation and about 100 different articles and youtube tutorials on this particular subject, the only way to control it is via the Publishing API from google which is a part of Google Play Developer API. This particular library needs to be implemented in the google cloud project that is generally linked to the firebase project of the app. This created a hurdle for us as none of our team members were familiar with google cloud (we use AWS 😋). This caused a serious issue. We implemented the in-app feedback and published our app on the play store only to discover that we have mistakenly pushed a bug that will crash the app every time a notification is issued. This caused a huge jump in our crashes and created a panic. We immediately resolved the bug and published the fix only to realize that it was a flexible update. It took around a couple of weeks for almost all users to move to the latest app and end the crash nightmare.
This nightmare forced us to bring up some kind of workaround. A very viable solution existed which involved popping up a non-dismissible dialog that had a button to redirect to the play store but honestly it look bad whereas google play’s prompt looked seamless.
The problem statement was now to find a solution that keeps the in-app update in place but allows us to trigger immediate updates without the use of Publishing API.
We first figured out that even without using Publishing API we could issue IMMEDIATE updates. We just needed to change the AppUpdateType which is sent to AppUpdateManager
| appUpdateManager.startUpdateFlowForResult( | |
| // Pass the intent that is returned by 'getAppUpdateInfo()'. | |
| appUpdateInfo, | |
| //'AppUpdateType.FLEXIBLE' for flexible updates or 'AppUpdateType.IMMEDIATE' for immediate update. | |
| AppUpdateType.IMMEDIATE, | |
| // The current activity making the update request. | |
| this, | |
| // Include a request code to later monitor this update request. | |
| IN_APP_UPDATE_REQUEST_CODE | |
| ) |
This was a code side change which meant if we set it to flexible all the updates would be treated as FLEXIBLE and if set to immediate then all updates are treated as IMMEDIATE. So, it proved to be only half of the required solution,
Now we needed a value that can be changed remotely, which redirected us to, as you could have guessed, firebase’s remote config. We created a boolean value and named it forceUpdate. We obtained the value in our activity from firebase and performed a check
| override fun onCreate(savedInstanceState: Bundle?) { | |
| .. | |
| forceUpdate = remoteConfig().getBoolean(FORCE_UPDATE) | |
| remoteConfig().fetchAndActivate().addOnSuccessListener { | |
| checkInAppUpdate() | |
| } | |
| .. | |
| } | |
| private fun checkInAppUpdate(){ | |
| .. | |
| appUpdateManager.startUpdateFlowForResult( | |
| appUpdateInfo, | |
| if(forceUpdate) AppUpdateType.IMMEDIATE else AppUpdateType.FLEXIBLE, | |
| this, | |
| IN_APP_UPDATE_REQUEST_CODE | |
| ) | |
| .. | |
| } | |
| override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { | |
| super.onActivityResult(requestCode, resultCode, data) | |
| when (requestCode) { | |
| IN_APP_UPDATE_REQUEST_CODE -> { | |
| when(resultCode){ | |
| //close the app if user closes immediate update | |
| Activity.RESULT_CANCELED -> { | |
| if(forceUpdate) finishAffinity() | |
| } | |
| } | |
| } | |
| } | |
| } |
This code works by first getting the value from firebase’s remote config and then triggering the checkUpdate function. This way we were able to control if we wanted our release to be an immediate update or a fixed update. The only drawback was that this method didn’t allow us to set up a priority with each release which didn’t affect our use case.
Thank you for taking the time to read this! If you feel to express your views feel free to leave a comment 💬
If this article proved useful, make sure to show your love by giving it 50 👏
This article was originally published on proandroiddev.com on June 30, 2022
