Blog Infos
Author
Published
Topics
Published

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}")
    }
}

Job Offers

Job Offers


    Information Security Engineer

    MongoDB
    London, UK
    • Full Time
    apply now

OUR VIDEO RECOMMENDATION

,

Migrate to Google Play Billing v5

Google announced at Google I/O this year their new version for Google Play Billing that changes everything for In-App Subscription
Watch Video

Migrate to Google Play Billing v5

Kevin Herembourg
Head of Mobile
Purchasely

Migrate to Google Play Billing v5

Kevin Herembourg
Head of Mobile
Purchasely

Migrate to Google Play Billing v5

Kevin Herembourg
Head of Mobile
Purchasely

Jobs

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:

private fun startInAppReviewFlow() {
// from Fragment class
with(ReviewManagerFactory.create(requireContext())) {
requestReviewFlow()
.addOnCompleteListener { task ->
if (task.isSuccessful) {
launchReviewFlow(requireActivity(), task.result)
.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.
}
} else {
Log.w(TAG, "There was a problem requesting the review flow ${task.exception}")
}
}
}
}
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.

Afterthought

The In-App Reviews API from the Google Play Store is the perfect solution to get more users to rate your application. It’s faster and more direct, and does not require the users to go out of your app. Nevertheless, it is generally hard to test due to the platform’s internal decision-making when it comes to the frequency we can use these APIs on users.

If everything goes well, the solution I’ve proposed for testing should conclude our inquiry. We’ve gone over the full lifecycle, from initial integration, to best practices on when to call, and all the way to testing. Hope this article was of help, and have fun getting a lot more user reviews on your applications!

This article was previously published on proandroiddev.com

YOU MAY BE INTERESTED IN

YOU MAY BE INTERESTED IN

blog
Lots of Android apps offer in-app purchases to users for the premium features or…
READ MORE
blog
All I know is that losing items, when it happens, turns me into a…
READ MORE

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu