在什么情况下,应用内计费版本3服务器更改可在客户端设备上使用?



测试应用内计费版本3已经变得不可预测,因为Google Play应用缓冲来自Google Play服务器的数据,而缓冲过程没有得到很好的记录。特别是,如果购买是在一个用户的设备上进行的,它可能不会立即在同一用户拥有的不同设备上可见。

推荐的做法是应用程序在启动时检查所有购买产品的库存。但有时这种检查使用的缓冲数据已经过期,由于更新通过相同的应用程序在不同的设备,或通过谷歌Checkout(例如,退款或取消订单)。

在什么情况下,在Google Play服务器上购买数据的更改在未启动该更新的设备上运行的Google Play应用程序上可用?

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

这是我自己在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服务器上可用的数据触发缓存数据的更新。

相关内容

最新更新