#android #google-play #google-play-services #google-play-core
#Android #google-play #google-play-services #google-play-core
Вопрос:
В документации указано, что объект ReviewInfo действителен только в течение ограниченного периода времени:
Примечание: Объект ReviewInfo действителен только в течение ограниченного периода времени. Ваше приложение должно запросить объект ReviewInfo заранее (предварительный кэш), но только после того, как вы будете уверены, что ваше приложение запустит поток проверки в приложении.
Как долго (примерно) действует объект ReviewInfo?
Например, может ли игра получать ReviewInfo при запуске (если пользователь играл достаточно долго), а затем запускать поток рецензирования, только если пользователь наберет свой высокий балл, который может составлять 5, 10, 30 минут в будущем?
Ответ №1:
Итак, я провел некоторое тестирование по этой проблеме и обнаружил, что ReviewInfo оставался действительным более 2 часов, но менее 3.
Я протестировал это, загрузив объект ReviewInfo в процессе запуска приложения, и, пока приложение было открыто, я увеличил время работы устройства на 3 часа. В этом случае это не сработало, но это сработало, когда я использовал 2.
Я также тестировал его в течение нескольких часов (даже дней), и это так и не сработало, но при возврате к 2 часам диалоговое окно отображалось нормально, поэтому я думаю, что это их текущий порог. Обратите внимание, что, согласно документации, они могут изменить это в любое время, поэтому торгуйте осторожно.
Ответ №2:
Как указано в документах:
https://developer.android.com/guide/playcore/in-app-review/kotlin-java#request-review-info
Примечание: Объект ReviewInfo действителен только в течение ограниченного периода времени. Ваше приложение должно запросить объект ReviewInfo заранее (предварительный кэш), но только после того, как вы будете уверены, что ваше приложение запустит поток проверки в приложении.
Хотя вы потенциально можете обнаружить TTL, это деталь реализации, поэтому ретрансляция на нем может иметь неприятные последствия.
Я бы не рекомендовал загружать при создании приложения, вместо этого используйте некоторую логику для защиты запроса.
Например, обычной практикой является попытка отобразить запрос после перехода на экран, как только пользователь успешно выполнил действие или любую другую логику, которую вы хотите применить. Это означает, что на предыдущем экране вы уже могли запустить запрос и только после появления нового экрана запустить поток.
Смотрите пример PlayCoreKtx для примера https://github.com/android/app-bundle-samples/blob/master/PlayCoreKtx/app/src/main/java/com/google/android/samples/dynamicfeatures/state/ReviewViewModel.kt