У меня есть приложение, которое реализовало в App Billing для премиальной версии моего приложения. При запуске я проверяю, приобрел ли пользователь продукт с помощью IabHelper
. Когда я загружаю свою следующую деятельность, мне нужно снова проверить покупку, чтобы решить, показывать или не показывать определенный контент в меню. Я не хочу сохранять результат вызова при запуске в настройках или локальном db по соображениям безопасности и понимать, что информация о воспроизведении кэширована в любом случае. Является ли мой лучший вариант во втором действии создать новый экземпляр IabHelper
и позвонить startSetup()
, а затем queryInventoryAsync()
? Проблема в том, что, поскольку вызов асинхронный, я не уверен, когда ответ вернется, чтобы обновить меню пользовательского интерфейса.Вызов IAB через несколько видов деятельности
3
A
ответ
2
Это то, что я сейчас делаю. Я использую асинхронный обратный вызов для обновления ранее сохраненного объекта меню, чтобы показать/скрыть вариант покупки, который на самом деле никогда не видел скорость возвращаемого вызова.
Чтобы ускорить процесс, если вы вызываете queryInventoryAsync(false, mGotInventoryListener);
(отметьте фальшивый флаг), вы будете использовать только локальный кешированный инвентарь, который намного быстрее реагировать.
Да, это то, что я собираюсь делать, просто задавался вопросом, была ли задержка в ответе. Плюс к каждой деятельности, вызывающей IabHelper, есть много дублированного кода, который я действительно думал о превращении в одноэлементный? – Carl
Мне не нравится дублирование, но с обратными вызовами он будет очень беспорядочным, как один сингл, поскольку вам понадобится хотя бы некоторые из этих обратных вызовов, чтобы указать на текущую активность. Вы также не можете гарантировать входную точку вашего приложения, поэтому активация в основном действии не будет работать. – CodeChimp