Keeping all your users updated with your latest features can be tricky business.
At the moment, Google Play’s updates can be unreliable as they depend on the users to update the app independently most of the time. However, recent updates, like Google’s in-app updates, are planning to change that.
This article will explore the benefits and drawbacks of in-app updates and how we are tackling mentioned issues using one of our open-source libraries for handling updates, Prince of Versions.
What are Google’s in-app updates?
In an effort to change the current way of handling things, Google revealed a brand new way of handling updates at its I/O event last year. This concept was innovatively named Google’s in-app updates and brought us a lot of requested changes.
So, what are the new changes?
Firstly, as the name suggests, updates are now more interactive. Users will be notified in the application about an available update on the Google Play store (hence the name).
Furthermore, there is now one crucial distinction between updates. An update can be classified as flexible or as immediate, depending on various factors determined by developers or the Google Play store. The major difference between these two is the way the update is going to be handled.
On the one hand, the flexible update, recognizable by its specific UI, allows the user to keep using the application while the update is downloading in the background. Because of this, the flexible update is usually used for smaller updates, like adding a neat feature or some other non-essential bugfix.
In contrast, the immediate update is primarily used for essential app updates. Without these updates, applications probably won’t work the way they are supposed to for some or all users. Because of this, UI on immediate updates will be blocking, meaning that users won’t be able to continue using the application while the update is being downloaded and installed.
All in all, it is noticeable that this update from Google brought us some highly desirable changes that will make the entire updating process easier and more fluid for the user. Also, with Google providing its UI and handling the update, the updating process will be easier for developers, too.
How to use Google’s in-app updates, and what are the drawbacks?
Following that compellingly positive introduction, it’s time to show how to use Google’s in-app updates and what are its disadvantages.
For starters, using this new update mechanism requires the Play Core library. Furthermore, this library requires API level 21 or higher, so devices below that limit won’t be able to use it. The Play Core library offers all the mentioned benefits, meaning that after adding this library as a dependency, you are ready to go!
Checking for an update
We must begin by demonstrating how you are going to check if there is an update on the Google Play Store. The code for doing that is simple and it looks like so:
val updateManager = AppUpdateManagerFactory.create(this)
updateManager.appUpdateInfo.addOnSuccessListener {
if (it.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE &&
it.isUpdateTypeAllowed(AppUpdateType.IMMEDIATE)) {
}
}
The process begins by creating an instance of AppUpdateManager. This instance will be in charge of handling all of the update information and the flow. Within that instance, there is a method to get AppUpdateInfo task that will supply us with all the necessary information about the update state. One of the typical usages of AppUpdateInfo is checking update availability and whether that kind of update is allowed.
Now is the time to discuss the first and only shortcoming we have identified using this new library.
Essentially, at the moment of writing this, the Google Play Store offers limited means of action by which we could manually set what kind of update we are looking for. In other words, Google’s API is currently not entirely user-friendly, as it doesn’t allow publishers to easily specify update type per application version in the release track. This system could result in a possibly painful adjustment because, for the time being, Google doesn’t offer a better way of handling this matter.
Starting the update flow
After checking, depending on update availability, we can continue with the invocation of the update. To invoke the update flow, we use the following code:
updateManager.startUpdateFlowForResult(
appUpdateInfo,
AppUpdateType.IMMEDIATE,
this,
REQUEST_CODE_UPDATE)
As we can see from the code snippet above, the AppUpdateManager invokes the update flow. To invoke it, we need to pass a couple of parameters.
Firstly, we are passing appUpdateInfo, which is Google’s object that we got from the update check itself. Moreover, we are sending some application-related parameters like the current activity and the request code to monitor the update process later. Lastly, there is AppUpdateType.
With this parameter, we are ultimately deciding on what kind of update we will invoke on users’ phones. That means that just by knowing what kind of an update we have on Google Play Store, we can “ask” Google for it through this parameter.
Currently, Google only allows for priority change per release, whereas naturally, developers would welcome the ability to change priority per version. For this inconvenience, we can use this mentioned parameter to our advantage.
Our solution was to find a way of knowing what kind of update we are putting on the Google Play Store. If we know what kind of update we are putting there, we can “ask” Google for it.
In other words, we will know exactly what update is there on Google Play Store, and by knowing it, we are going to invoke that kind of update through the AppUpdateManager instance.
Now how exactly are we going to do that? With Prince of Versions.
Prince of Versions == Solution?
Prince of Versions is an open-source library for practical and easy update handling. It was created a few years ago, with the desire for an improved way to classify updates.
As mentioned, Google’s past way of handling updates was not satisfying because it relied too much on the user. As a partial solution to this, Google presented its new in-app way of handling updates. Nevertheless, as we saw, it still has a few significant issues.
In our pursuit of an ideal combination of Google’s fancy UI and Prince of Versions’ reliable update handling, we have decided to merge these two into the latest Prince of Versions sibling: Queen of Versions.
So, how will Queen of Versions solve Google’s issues?
Firstly, we need to understand how the Prince of Versions operates. It works by fetching the JSON file and then parsing it to retrieve all the necessary details about the current update. The details comprise of information like the latest application version, minimum required version, and any additional data that we would need.
Example of the JSON file:
"android": {
"required_version": 12,
"last_version_available": 12,
"notify_last_version_frequency": "ONCE"
}
Afterward, Prince starts the update classification process. It begins by making several comparisons between extracted JSON values, and it finishes with one of three classification outcomes – required (immediate), new (flexible), or no update. The code for starting that process is nicely explained here.
There, we can notice a similarity with new Google’s in-app updates. Their main feature is the latest update classification. However, this is also Google’s most significant shortcoming. To reiterate, Google currently doesn’t offer an easy way of specifying update type per application version in the release track.
The proposed solution
To begin with, we have to push our latest update on Google Play. In the meantime, all the update information should be accessible through the JSON file somewhere on the internet. This step usually consists of just writing some new numbers in the JSON and uploading it somewhere on the internet ( e.g. your server/API/any public domain ). This last step ends our job outside of the application.
Inside the application, we begin by utilizing Prince’s ability to acquire update information from a JSON file. Thus, with Prince’s help, we have all the essential information about an update which is also on the Google Play Store at that same moment.
In other words, we know precisely whether the update is required or optional. With that knowledge, we can “ask” Google for precisely what we want. Finally, we proceed by requesting the desired type of update with Google’s Play Core API.
In a nutshell, that is it – we have successfully bypassed Google’s complicated API and created a simplistic way of specifying the right kind of an update.
Naturally, there is a lot more to this story. We have created a rich library with a user-friendly API that offers a bundle of update handling customization and runs on top of this latest Google’s in-app update.
A step towards the desired way of handling updates on Android
Overall, Google’s in-app updates are the right step toward the desired way of handling updates on Android. Certainly, there is still a lot of room for improvement, as there are some drawbacks to the current practice of handling things.
If you favor the simplistic update handling and want to try something different, feel free to try out our Queen of Versions and let us know your feedback. Whether you love it or if there is something else you would like to see in our next update, please let us know.
