This is a companion discussion topic for the original entry at https://www.raywenderlich.com/20065814-android-in-app-review/lessons/9
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/20065814-android-in-app-review/lessons/9
Thanks for the course, but I would like to point out a few things that might not work as expected in production, as In-App review has some restricted usage for the final user.
First of all, the documentation states that:
Your app should not ask the user any questions before or while presenting the rating button or card, including questions about their opinion (such as “Do you like the app?”) or predictive questions (such as “Would you rate this app 5 stars”).
Even though I agree that asking the user if they want to review the app with a separate dialog, it might not always work the way that it was implemented, as both calls to launchReviewFlow() and requestReviewFlow() can and will potentially return isSuccessful even though nothing was shown to the user.
In that case, if trying to call the In-App review API for user that the API decides not to to show the In-App review flow, the app will get a isSuccessful and nothing will happen. In other words, the app will not fallback to open the Play Store as per the implementation.
The code might be working in the same device because of the of the shared preferences that prevents from asking the user to review the app again, but with the simple step of clearing the app datas and reseting the shared preferences, you will be able to test that the Play Store will never be launched and neither In-App review will show.
Also, in order to fully test it, don’t rely too much on “Internal App Sharing”, as it will allow the In-App review to show more often than it shows to the end user. I mean, we can’t test it only in production, but having a call-to-action button to show In-App review might result and some unexpected results.
Hey @rafael_affinitycu!
I appreciate your comment, however I feel like there might some misunderstanding in what I was trying to achieve and what the documentation says.
You mention that my implementation is against the documentation because I’m asking questions before the prompt.
My text is: “Congratulations on completing this course! / Next, take a moment to rate your experience with the app.”
I’m not actually asking questions, instead it’s a contextual UX design that’s both acknowledging the user for their accomplishments and letting them know they might want to rate said experience. Both are statements and simple sentences to guide the user to what’s happening.
I don’t think that not giving the user any context before showing a rate prompt is a good user experience, as they’d randomly see a rating prompt every now and then until they rate the app. That’s very bad experience as we’re not taking users’ opinion into the equation and we’re effectively spamming the user without their consent.
It’s very common practice to let the user know what can happen and if they’d like to rate the app or not.
Furthermore, I mention clearly in the course that no matter when or how you call the function to launchReviewFlow() or requestReviewFlow() it’s most likely going to return success, even if it doesn’t show anything.
I specifically point that out, when I talk about testing and the user experience. I also mention how the fallback for the Play Store is there in case something goes horribly wrong. The API breaks, the device/user is broken in a way or something else. I do mention that that’s not a likely case, so I don’t see how that’s an issue there!
–
Finally, your point:
"Also, in order to fully test it, don’t use “Internal App Sharing”, as it will allow the In-App review to always show on the device, as the quota limits are not enforced in this method.
In other words, the problem will only happen in production or if the Google Account that is testing the app is not a “Internal Tester”."
Doesn’t make much sense to me, or I might not understand it, as the Internal App Sharing/Internal Testing is one of the only ways to test the API. Certainly it’s better than testing in real production, right? Additionally, I tested with Internal App Sharing, and the In-App Review didn’t always show on the device, like you mention. So the API or the documentation is not always the most accurate.
Thanks for bringing up this discussion! I hope I didn’t offend you in any way or that I didn’t cause confusion!
I do agree that not giving a context to the user is not a good practice, but this is what the In-App review offers, there is nothing we can do.
The problem is not much related to having a question or not, but having a call-to-action that triggers In-App review.
I know that without In-App review, it’s really common practice to ask before redirecting the user to the store. But that is only possible without In-App review, because In-App review can and will return “success” even if nothing was shown.
And, in the code, the review prompt has a button “Leave a Review”. If I user taps that button they will expect to see a way to leave a review. However, using In-App review, the following scenario can happen:
- User clicks “Leave a Review”
- App call In-App review
- In-App review does not show anything and return success (because the user has already reviewed the app)
- Nothing happens after the user clicks “Leave a Review”
That is why, unfortunately, we can have a call-to-action to use In-App review, as mentioned here:
"
Because the quota is subject to change, it’s important to apply your own logic and target the best possible moment to request a review. For example, you should not have a call-to-action option (such as a button) to trigger the API, as a user might have already hit their quota and the flow won’t be shown, presenting a broken experience to the user. For this use case, redirect the user to the Play Store instead.
"
So, if there is a call-to-action, it’s impossible to determine if anything was shown or not, so if the app has a call-to-aciton, the only possible way to request a review is to redirect to the Play Store and not use the In-App review API at all.
I also don’t agree and I am not happy with the way it was implemented, but that is how it works.
And about using the app with “Internal App Sharing”, if you are logged with a Google Account that is registered as “Internal Tester” (internal test track), the In-App Review does show every time you call it, as “The quota limits are not enforced if the app is downloaded from the internal test track.”. I have tested it and I have it working 100% of the time.
Hey @rafael_affinitycu!
Thanks for clarifying, it might’ve been my state of mind or the tone that I drew from the text but it was my mistake, so sorry for feeling that way.
I’ve edited my comment to reflect what I actually meant, in a nicer way.
I do agree that there can be a situation where the user taps on “Leave a Review” but nothing happens. That’s why I used SharedPreferences to store the info and not show the user the dialog more than once.
In any way, the dialog should show the first time, as well as the prompt. The first time should be the happy path so there shouldn’t be any issues.
Then if the user doesn’t leave a review, we won’t spam the user anymore and things should go back to “normal”.
I’m kind of sad the API doesn’t allow better testing and/or result propagation for us to handle if the dialog truly was shown or not. Doesn’t seem like it’s bad info to get that the dialog was shown or not, but that’s a Google API, so they probably have a reason for that.
Either way, thanks for sparking this discussion and helping the community get more info about this.
Again, I’ve edited my comment, so you can edit yours to reflect that and we’ll have a nice and happy discussion!
Thanks once more!
Yeap, I agree that the API is not the more elegant to deal with that.
But what I was trying to say is that, even if you control that with a SharedPreferences, there is a potential risk that the In-App review will not show anything neither in the first attempt you try to show it. When using In-App review we have to consider that the user might have already reviewed the app in another device or had reinstalled the app (cleaning the app’s data).
I mean, the solution would work 99% of the time, but as the documentation says, we can’t have a call-to-action to call the In-App review API, because we can’t control if something happened or not, creating the scenario where the user clicks on a button and nothing happens.
1 Like
Those are really good points to show!
Thanks for the comments. Once we decide to update the course, I’ll mention how there are different approaches you can take here.
I’ll probably just completely revise this episode and put more notes and instructions on how to handle the logic in case something goes wrong.
Thanks!