应用内购买非托管项目与购买状态更改通知之间存在显着延迟
我在 Android 市场上拥有一款具有应用内信用购买功能的应用程序已有好几个月了。我们的第一个问题是成功完成非托管购买并计费的用户，但无论出于何种原因，我的客户端应用程序都没有将其记录到我们的服务器上。这种情况不会 100% 发生，大多数购买都会成功执行，如果由于连接问题或其他原因无法将成功的购买上传到服务器，我们有非常积极的重试逻辑。
最近，我们目睹了一个场景，其中对非托管项目进行了应用内购买，但是 onRequestPurchaseResponse 方法（在示例代码中定义 PurchaseObserver.java，我们的代码基于它），实际上并没有被调用60秒。
我现在怀疑，在这些成功购买未上传到我们的服务器的情况下，onRequestPurchaseResponse 要么永远不会被调用，要么用户在通知发生之前退出应用程序，因为通知太延迟了。
现在，每次用户从 Android Marketplace 应用程序返回后调用 onResume 时，我都会显示一个 ProgressDialog，以防止用户过快离开，从而阻止我们记录购买情况。
谁能告诉我成功购买后是否存在任何涉及 Android Marketplace 应用程序延迟或丢失通知的已知错误，如果有，您部署了哪些解决方法？
I have had an app on the Android marketplace with in-app credit purchase ability for many months now. Our #1 issue is users who successfully complete their unmanaged purchase and are billed, but for whatever reason my client app is not recording it to our servers. This doesn't happen 100% of the time, most purchases are executed successfully, and we have very agressive retry logic if a successful purchase can't be uploaded to the server due to connectivity issues or whatever.
Recently we witnessed a scenario where an in-app purchase of an unmanaged item was made, but the onRequestPurchaseResponse method (defined in the sample code PurchaseObserver.java, on which our code is based), was not actually called for over 60 seconds.
My suspicion now is that in these cases where successful purchases are not uploaded to our servers, onRequestPurchaseResponse is either never called or the user exits the app before the notification happens because it is so delayed.
I now show a ProgressDialog every time onResume is called after the user returns from the Android Marketplace app, to prevent users from navigating away too quickly and thereby preventing us from recording the purchase.
Can anyone tell me if there are any known bugs involving either delayed or missing notifications from the Android Marketplace app after a successful purchase, and if so, what workarounds you have deployed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
延迟不是错误。交易处理系统不是实时的，而且几乎没有一个具有公共 API 的系统能够对处理交易或将成功购买报告给商家所需的时间提供可靠的保证。
但是，我不确定我是否看到了这个问题。只要用户最终再次运行您的应用程序，就应该在某个时间点收到回调通知。当然，假设谷歌将其购买通知排队，直到确信它们至少已发送一次。我认为他们会的。
无论如何，我认为您有几个选择：
让您的客户始终假设购买成功，除非/直到听到相反的消息。然后，您不需要应用程序在购买发生时告诉服务器，您只需要它在您认为发生的购买没有发生时告诉服务器即可。此方法与当前方法具有相同的延迟问题，但副作用对用户的危害较小。
只需等待最终出现的通知回调，然后发送即可。不要锁定整个应用程序以阻止用户离开，只需将其购买状态显示为“等待 Google 确认”，直到收到回调（根据用户的操作，可能会在几分钟内发生）实际购买后、几小时或几天）。然后将信息发送到您的服务器，并在发送到服务器成功时更新应用程序中的购买状态。
A delay is not a bug. Transaction processing systems are not real-time, and virtually none of the ones with public API's provide a solid guarantee on the amount of time it will take either for a transaction to be processed or for a successful purchase to be reported back to the merchant.
However, I'm not sure I see the issue. Your app should receive the callback notification at some point in time, so long as the user runs it again eventually. Assuming, of course, that Google queues its purchase notifications until it is confident that they have been delivered at least once. Which I would assume they would.
In any case, I think you have a couple of options:
Implement your client to always assume that a purchase was successful unless/until it hears otherwise. Then instead of needing the app to tell the server when a purchase has occurred, you just need it to tell the server when a purchase that you thought occurred did not. This approach has the same issues with delay as your current approach, but the side-effects are less detrimental to users.
Just wait for the notification callback that should come eventually, and send it then. Instead of locking your entire app in an attempt to keep the user from navigating away, just show their purchase with a status of "Pending confirmation from Google" until you get the callback (which, depending upon what the user does, may happen some minutes, hours, or days after the actual purchase). Then send the information to your server and update the purchase state in app when the send to the server succeeds.