2013-03-13 14 views
10

测试应用内结算版本3由于Google Play应用缓存来自Google Play服务器的数据而导致无法预测,并且缓冲过程未详细记录。特别是,如果在用户的某个设备上进行购买,它可能不会立即在该同一用户拥有的其他设备上可见。在什么情况下应用程序内结算版本3服务器更改在客户端设备上可用?

建议的做法是让应用程序在启动时检查所有购买的产品的库存。但有时候,此检查使用的缓冲数据由于通过同一应用在不同设备上进行的更新而失效,或者通过Google Checkout(例如退款或取消的订单)进行更新。

对于在未启动该更新的设备上运行的Google Play应用,在Google Play服务器上购买数据所做的更改有何变化?

具体来说,如何确保在测试期间使用queryInventoryAsync()(TrivialDrive示例应用程序提供的IabHelper类的方法)检查​​返回的数据反映了Google Play服务器上的当前内容,而不是可能的陈旧的缓冲数据?

回答

12

以下是我自己的体验,购买Nexus 7平板电脑上运行的应用程序,然后使用Nexus One手机上运行的相同应用程序检测该购买项目。下面描述的测试是使用以草稿模式(尚未发布)上传的应用程序的测试帐户执行的。测试帐户是在开发者控制台中为草稿应用程序声明的,并且是两个测试设备的主帐户。

所做的购买是非消耗品。该购买是使用TrivialDrive示例应用程序提供的IabHelper类的变体进行的。被调用来进行购买的IabHelper方法是launchPurchaseFlow()。

购买产品后,当随后使用IabHelper的queryInventoryAsync()方法时,该产品被添加到返回到同一设备的已购产品列表中。

但是,由同一个帐户拥有的单独的Nexus One设备启动时会执行对queryInventoryAsync()的调用,但在使用该方法返回的已购买物品的库存中未收到购买的物品。

但是,如果使用Nexus One设备通过launchPurchaseFlow()启动购买同一商品,则会返回一条消息(在显示屏前弹出的对话框中,该对话框将用于制作表示该项目已被拥有,因此无法购买该项目。这发生在从Nexus 7购买后不到15分钟,显示该数据在Google Play服务器上相当及时可用,但不会自动在Nexus One上提供,直到尝试重新购买来自Nexus One设备的物品已启动。

继此尝试购买已拥有的项目后,项目确实出现在Nexus One的queryInventoryAsync()的后续调用中。这表明尝试购买该项目会触发Nexus One Google Play应用的缓冲数据与Google Play服务器上可用数据的同步。这是由queryInventoryAsync()本身触发的而不是

我测试了第二种方案,其中不是试图从Nexus One购买已拥有的物品,而是删除了Google Play应用中的缓存。这样做而不是启动由queryInventoryAsync()返回的数据的更新;数据保持不变。

我测试了第三种情况,在这种情况下,我只需关闭Nexus One,然后重新上电,而不是尝试从Nexus One购买已拥有的物品。在此之后,当我运行相同的应用程序并执行queryInventoryAsync()请求时,从Nexus 7购买的商品实际上在购买物品的返回列表中可见。

我从上面得出的结论是,Google Play应用程序试图通过在本地缓存购买行为并在发生特定触发事件时仅更新自身来减少它对Google Play服务器的往返次数。我已经确定了两个触发器:1)尝试购买已拥有的物品; 2)重新启动运行Google Play应用的设备。特别是,queryInventoryAsync()不是而是发起这样的更新,因此可能会返回陈旧的数据,如上所述。

了解上述内容可以使测试更高效且更容易混淆,因为它允许人们故意触发Google Play服务器上可用数据的缓冲数据更新。

+0

感谢您分享您的体验。 – elirigobeli 2015-03-23 20:11:26

+0

使用沙箱和测试账户,我目睹了IABv3行为的转变(从一个工作和有意义的角度)。最初的开发中,getBuyIntent预先产生了“purchaseToken”(预期交易),我整合并关注该功能,成功完成测试付款,并在付款后查看getPurchases中的适当数据。一周后,getBuyIntent产生null purchaseData(所以没有purchaseToken),getPurchases即使在购买成功后(在popup,相同设备中)也会每次返回相同(陈旧的)数据。令人费解! – straya 2016-08-11 01:42:43

相关问题