After the breakup of the Google Play Store library, it is now easier and lighter than ever to integrate its different features by themselves. These features can serve as your app’s interface with the Google Play Store, and allow you to take a series of actions directly inside the app, that would otherwise take the users out of your application.

In this article, we will look over one of these such libraries, specifically the In-App Reviews feature, and APIs. We’ll start by simply explaining how to bring it into your application, triggering its flow, and follow up with best practices alongside some testing suggestions as well.

Getting Started

As it was mentioned already, integrating this individual Google Play Store feature library is fairly simple. Start by locating the app-level build.gradle file, and add one of the following lines of code, depending on your project’s programming language of choice.

// app:build.gradle
...
dependencies {
    ...
    // Java
    implementation 'com.google.android.play:review:2.0.1'
    // Kotlin 
    implementation 'com.google.android.play:review-ktx:2.0.1'
}

Deciding When To Request

Next, we have to decide when we want to request an in-app review from the user. The official guidelines suggest that we only request a review after the user has experienced enough of the application or game so that they are capable of providing useful and insightful feedback.

Android also has two more propositions on when it is appropriate to request a review. They insist not only to limit the number of times and frequency that reviews are requested, but they also instruct that the user is not presented with any questions either whilst or before the review is displayed to the user.

Setting Up the Review Flow

Let’s get back into code. Once we identify the right trigger to initiate our review flow, it’s time to put together a simple function to trigger the in-app review.

First off, we’ll create a ReviewManager from the ReviewManagerFactory, which will be responsible to initiate the task that may lead to an in-app review flow.

val manager = ReviewManagerFactory.create(context)

Next up, we’ll use the instance of the ReviewManager to request a review flow object directly from the OS. If the review task is successful, the callback will return with an instance of a ReviewInfo that may be used to start the review flow.

val request = manager.requestReviewFlow()
request.addOnCompleteListener { task ->
    if (task.isSuccessful) {
        // We got the ReviewInfo object
        val reviewInfo = task.result
    } else {
        Log.w(TAG, "There was a problem requesting the review flow ${task.exception}")
    }
}

There is a time-bound quota that Google Play imposes on how often a user can be shown the review dialog, and they reserve the right to change this variable as willed. Due to that, following the guidelines from the last section is highly encouraged, especially when trying to show a dialog leading up to the review flow.

The ReviewInfo object is only valid for a limited amount of time. Your app should request a ReviewInfo object ahead of time (pre-cache) but only once you are certain that your app will launch the in-app review flow.

— Android developers

Starting the Review Flow

The only thing left to do is to use the successful task’s result variable to launch the in-app review flow. Note that regardless of what action the user takes while inside the in-app review Dialog, the flow completion callback will be called without any kind of information about the user’s actions. This is meant to protect the user’s information and opinions from being used further for any kind of marketing or other targeted campaigns.

manager.launchReviewFlow(activity, reviewInfo)
    .addOnCompleteListener { _ ->
      // The flow has finished. The API does not indicate whether the user
      // reviewed or not, or even whether the review dialog was shown. Thus, no
      // matter the result, we continue our app flow.
    }

The app should continue normally as soon as the review flow is completed.

If an error occurs during the in-app review flow, do not inform the user or change your app’s normal user flow. Continue your app’s normal user flow after onComplete is called.

— Android developers.

Putting It All Together

With a little bit of cleanup, plus a flare of functional programming design, the condensed function that you can copy-paste into your project looks something like this:

On Testing

Now that we’ve successfully set up the In-App Reviews API in our application, the only lingering questions should be: How do we test it?

As it was previously mentioned, The Android OS reserves the right to dose the usage of this API at their discretion, which means that the in-app review flow may only be tested successfully in very particular ways.

Google offers a few methods to achieve this. When it comes to Unit and Integration tests, they recommend that we use the FakeReviewManger in order to fake the behavior of the API. The regular ReviewManager that we used in our implementation above should be replaced with the FakeReviewManager to test this case. Unfortunately, this testing solution will not simulate the UI/UX interaction.

If instead, we want to test the flow visually, we would then turn to the Google Play Console and its different methods of internal app testing. For this alternative, there are yet two further options to choose from. We can use the traditional internal testing track inside the Google Play Console — like testing a pre-alpha version of your application — or instead, we could opt to use the Google Play Store’s Internal App Sharing feature.

In this other article, I go over the differences between these two further options, and then follow that up with a step-by-step guide on how to upload, distribute, download, and test an app build using the Play Console’s Internal App Sharing.

Testing Explained

For the purpose of this writing, however, we’ll be closing up by explaining how to use the contents of my other article, as mentioned above, to test the In-App Reviews implementation from the earlier sections.

Jumping back to where we left off, after implementing the resulting method from far above into your codebase, make sure to locate the trigger of the review flow, or add a manual one for the purpose of the testing session. After that, we should then follow the Developer Side of the other article to upload a version of the application that we want to test.

Next up, following the Tester Side of the parallel piece should end with the test build of the app installed into our device of choice. Open the app normally, and follow the flow we previously located as to trigger the In-App Reviews dialog.

This article was previously published on proandroiddev.com