Photo by Reinis Birznieks on Unsplash

In App Updates

Every mobile developer has faced this scenario before: you have an application that is ready to be released, you got down all the MVP features that you want, you tested it on several devices.

You feel good to go.

Before you hit that publish button, one question still lingers in your mind:

What will happen to my users when I want to update my application?

You want to be sure that your users will have an option to update to the latest version of the application, with ease and simplicity. But, how do you do that? How do you make sure a user gets notified?

For that, we have In App Updates.

Starting from Android 5 (API 21), this feature is the solution to that question. Scroll down to understand how you can make sure your users will stay updated.

Background

When releasing an application, we never know what the response will be. Is it going to be a hit? Is it really bug free? Is there enough content there to please my audience? We (developers) would like to have the ability to combat all of these scenarios. And the solution is to use in app updates.

To the unfamiliar, in app updates, allow you to notify users when a new version of your application has been released, by presenting a popup window when they open up the application. There, they have a choice between updating or not updating. There are two types of update flows:

1. Flexible
2. Immediate

Both types require the user’s consent to update, but they differ by how the user gets to keep interacting with the application. With a flexible update, the user can still engage with the application, while the update is being downloaded in the background. Once finished, you can let the user know the update has downloaded and ready to be installed. On the flip side, immediate update will download the update (even if the user closes the application) and force the application to restart. I won’t be covering the intricacies related to Flexible updates in this article and will focus more on the immediate update.

Let’s Get Updating

Before we can do anything, we will need to import Google’s Play Core library (version 1.5.0 and above) to our project. To do this, we will add the following line to our application’s build.gradle file:

Play Core Library Dependency

Then we will add logic that does the following:

• Checks for an update to the application
• If one exists, notifies the user
• Based on the user’s choice, takes an action (download/don’t download)

The blueprint to check if an update exists

In the code snippet above you can see several things taking place:

1. We first create an instance of the updateManager so we can check through it if an update exists
2. AppUpdateInfoTask returns an intent with all the information regarding checking for a update
3. A Listener that checks if the platform allows the type of update we want (Flexible/Immediate)
4. We have reached the point where we can request the update to happen

Requesting An Update

Now that we know that an update to our application exists, we need to alert the user to it. To do so, we use the following code:

Downloading the update

As you can see, we are using the startUpdateFlowForResult method to handle the actual downloading and updating of the application. This method takes four parameters:

1. An AppUpdateInfo object
2. The type of update
3. The activity
4. A request code

The request code is a unique identifier that you create in your application.

You might be asking yourself, how will we know when the update finishes downloading/fails/the user dismisses?

We will override the onActivityResult callback, and inside it we will determine the user’s action.

Handling the result from updating the application

There are three scenarios here :

1. The update successfully downloads and installs (RESULT_OK)
2. The update is cancelled by the user (RESULT_CANCELLED)
3. The update failed, either in the download phase or the install (RESULT_IN_APP_UPDATE_FAILED)

Insert your own logic to handle each scenario accordingly. For example, if the update failed, you could add code to try it again.

If the user closes the application during the update, we need to make sure the update was installed successfully when the application is resumed. To do that, we can use the following logic:

If there was an update in the background, resume it

Photo by Brandon Style on Unsplash

One Last Thing Before We Go

The main question left now is, how do I test this before releasing to production?

For that we have FakeAppUpdateManager. No, it is not something that I made up, but a real class specifically designed to test your code for in app updates. It does not interact at all with the Play store and no UI will be shown. To use it, just swap out the instantiation of the application update manager from the previous code snippets with the fake app update manager.

⚠️ Pay heed, as this will not enable you to simulate a genuine flow where a user with an older version of your application is prompted to update to a newer version.

This article was inspired by the work I have done with the following application:

Laundry Symbols - Apps on Google Play

TomerPacific/LaundrySymbols