【问题标题】:Android In App Billing Restore TransactionAndroid 应用内计费恢复交易
【发布时间】:2011-12-11 16:55:07
【问题描述】:

我的 In App Billing 实施方案: 1. 主屏幕显示我计划销售的产品列表。 2. 详情屏幕(在主屏幕中选择列表项时显示的屏幕)将具有购买该产品的选项。

我的理解是,恢复交易请求和检查是否支持 InAppBilling 的请求必须在主屏幕活动中完成。其余请求(启动购买等)应在详细屏幕活动中完成。这种理解正确吗?

如果是,我应该如何修改 Dungeons 示例以分离并在主屏幕活动上实现,这两组请求在我每次导航到详细屏幕活动时都不需要执行。我是否必须在这两个活动中创建购买观察者和相关类的单独实例?

【问题讨论】:

    标签: android in-app-purchase


    【解决方案1】:

    不应该频繁地进行恢复交易,可能只在应用程序的第一次运行时进行(这样如果用户重新安装应用程序等,您可以恢复购买)您不需要它来购买产品。

    BillingService 提供了单独的方法来请求购买和恢复交易。只需从相关活动中调用适当的活动即可。您只需要一名购买观察员,用户界面/活动的结构如何都无关紧要。

    【讨论】:

    • 我得到了恢复购买的方法。但在那种方法中有像“Long nonce”这样的参数。那么那是什么以及我作为 nonce 给出的价值是什么?
    • 这是您生成的随机数。检查文档和示例项目。
    • @NikolayElenkov 我同意你的观点,但你有没有在重新安装应用程序后恢复托管产品。如果是,请分享。到目前为止我发现它返回一个包含此购买信息的 json 数据。但无法找到如何获取该json。我在哪里可以在 onRestoreTransactionsResponse 方法中找到这些数据。谢谢
    • 当然,它工作得很好。这与购买onStatusChanged() 的流程完全相同,或者在通过广播接收器接收数据时将调用类似的方法(异步,因此可能需要一些时间)。
    【解决方案2】:

    在 Dungeons 示例中,如果您发出 RESTORE_TRANSACTION 请求,服务器的响应将首先调用此函数:

    onPurchaseStateChange(PurchaseState purchaseState, String itemId, int quantity, long purchaseTime, String developerPayload)

    然后: onRestoreTransactionsResponse(RestoreTransactions request,ResponseCode responseCode)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-09-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多