我可以在 Android In-App-Billing V3 上找到的所有教程都假设您有一个单一的活动来处理与计费相关的所有事情。就我而言,有多项活动需要访问帐单。我将如何最优雅地处理这样的事情?
我偶然发现的一个示例问题:在使用 Google 计费助手类时,您总是将当前活动作为参数移交。稍后在该活动上调用回调(例如 onActivityResult)。但是如果活动的活动一直在变化呢?我是否必须一直关闭并重新初始化计费?
我可以在 Android In-App-Billing V3 上找到的所有教程都假设您有一个单一的活动来处理与计费相关的所有事情。就我而言,有多项活动需要访问帐单。我将如何最优雅地处理这样的事情?
我偶然发现的一个示例问题:在使用 Google 计费助手类时,您总是将当前活动作为参数移交。稍后在该活动上调用回调(例如 onActivityResult)。但是如果活动的活动一直在变化呢?我是否必须一直关闭并重新初始化计费?
但是如果活动的活动一直在变化呢?我是否必须一直关闭并重新初始化计费?
没有什么不好的。连接到服务非常快。最重要的是能够在活动再次启动时处理 onActivityResult() 回调。
我将如何最优雅地处理这样的事情?
我不确定你写的是哪种应用程序。如果它是一个游戏,那么它很可能由一个单一的活动组成,无论如何都没有问题。如果它是具有多个活动的其他类型的应用程序,那么在我看来,最好有一个活动,用户能够看到所有应用内产品(购买和购买)。这就像一个“内部商店”活动。此活动可以连接到计费服务。其他活动应转发到“内部商店”,用户可以在其中阅读有关应用内产品的更多信息并决定购买。我觉得很方便。
另一种方法是在片段中实现您的计费逻辑,该片段可以在每个活动中重用。您只需要覆盖onActivityResult()
并将结果转发到该片段。这就是我在我的应用程序中实现它的方式。
希望这可以帮助。
在示例框之外思考一下。它不仅与您的问题有关,而且是一般性的。
我会使用通知系统,因为您有 1 个发布者和需要许多听众(您的案例 2)。一,最丑的方法可以是(但写得最快):
5th up-vote 如果有帮助或喜欢 :)