Car*_*arl 10 android in-app-purchase in-app-billing
测试应用内结算第3版已经因Google Play应用缓冲来自Google Play服务器的数据而无法预测,并且缓存过程没有详细记录.特别是,如果在用户的某个设备上进行购买,则可能无法在同一用户拥有的其他设备上立即看到它.
建议的做法是让应用程序在启动时检查所有已购买产品的库存.但有时此检查使用的缓冲数据由于在不同设备上通过同一应用程序进行的更新而已经过时,或者通过Google Checkout(例如,退款或已取消的订单).
在未启动此更新的设备上运行的Google Play应用中,在Google Play服务器上购买数据所做的更改是什么情况？
具体来说,如何在测试期间确保使用queryInventoryAsync()(TrivialDrive示例应用程序提供的IabHelper类的方法)检查返回的数据反映了目前Google Play服务器上的内容,而不是可能过时的缓冲数据？
Car*_*arl 12
以下是我自己购买带有在Nexus 7平板电脑上运行的应用的商品的经验,然后使用在Nexus One手机上运行的相同应用来检测购买.下面描述的测试是使用针对以草稿模式(尚未发布)上载的应用程序的测试帐户执行的.测试帐户已在Developer Console上为草稿应用程序声明,并且是两个测试设备的主要帐户.
购买的是非消耗品.购买是使用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购买的项目实际上在返回的已购买项目列表中可见.
我从上面得出结论,谷歌Play应用程序试图通过在本地缓冲购买来减少它对Google Play服务器的往返次数,并且只在特定触发器发生时自行更新.我已经确定了两个触发器:1)尝试购买已拥有的项目; 2)重新启动运行Google Play应用的设备.特别地,queryInventoryAsync()并没有发起这样的更新,并且因此可以返回过期数据,如上所述.
了解上述内容可以提高测试效率,减少混淆,因为它可以故意触发从Google Play服务器上提供的数据中更新缓冲数据.
| 归档时间： |
|
| 查看次数： |
889 次 |
| 最近记录： |