在应用程序购买中,用户在后台应用时取消tx:tx状态继续购买 [英] In App Purchase user cancels tx while app in background: tx state stays on purchasing

查看:120
本文介绍了在应用程序购买中,用户在后台应用时取消tx:tx状态继续购买的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在应用程序购买(沙箱环境)中有用户取消时有一些奇怪的行为,而应用程序在后台并且用户尚未登录到商店:

I have some odd behavior with User canceling in App Purchase (Sandbox Environment) while the app is in background and the user is not yet logged in to the store:

流程如下:


  • 用户未登录/未在设置>商店中设置应用ID

  • 用户点击购买按钮。这会调用 [[SKPaymentQueue defaultQueue] addPayment:payment];

  • 用户立即提供主页按钮(应用程序转到后台)

  • 出现Storekit弹出窗口,要求确认购买。用户取消

  • 应用程序再次激活,预计会收到 - (无效)paymentQueue:(SKPaymentQueue *)队列updatedTransactions:(NSArray *)交易,但没有。 TX仍处于国家采购阶段。

  • User is not logged in/App Id is not set in Settings > Store
  • User clicks buy button. This calls [[SKPaymentQueue defaultQueue] addPayment:payment];
  • User immediatly preses home button (app goes to background)
  • Storekit popup appears asking to confirm purchase. User cancels
  • App is activated again and would expect to recieve - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions, but does not. The TX is still in state purchasing.

如果testuser已经登录到商店,则此过程会有所不同。在这种情况下,上述过程按预期工作。

This process is different, if the testuser is logged in to the store already. In that case the above process works as expected.

另一个评论:完成上述步骤后,我实际购买了另一个应用内商品(包括登录到appstore)。在此之后,我将应用程序发送到后台并重新激活它,它将处理缺少缺失的取消交易。

Another remark: After the above steps, I actually buy another in-App item (inlcuding logging in to the appstore). After this I sent the app to backgrounding and reactivate it and it will process the fomerly missing cancel transaction.

结论:
用户在应用程序处于后台并且未登录到商店时取消付款tx会导致storekit回调延迟交付。在用户实际登录到appstore之后完成交付,并且通过重新激活应用程序来触发PaymentQueue进程。

Conclusion: A user canceling a payment tx while the app is in background and not being logged in to the store results in late delivery of the storekit callback. Delivery is done after the user actually logged in to the appstore and the PaymentQueue process gets triggered by reactivating the app.

这种行为似乎是错误的,如果它实际上是在真实环境中,我可能会认为这是一个Storekit错误。有人经历过相同的行为,或者可以指出某些东西可以防止tx在购买状态下挂起吗?

This behavior seems to be wrong and if it is actually like that in real environment, I might consider this a Storekit bug. Has someone experienced the same behavior or can indicate something to prevent a tx "hanging" in purchasing state?

谢谢,
Marcus

Thanks, Marcus

推荐答案

在商店套件方面,我不相信你可以指望任何事情。在按下购买按钮后,不要等待等待交易排队,而是继续关注您的业务。当您收到有关交易(可能是明天)的通知时,请处理它们。我相信在文档中有这样的评论 - 你的应用程序应该在它启动时注册SK通知,并且它应该随时可以获得它们。因此,对于Store Kit,不要在应用程序中建立任何状态意识。只需在交易到达时处理。

I don't believe you can count on ANYTHING when it comes to Store Kit. Rather than "waiting expectantly" for the transaction to be queued after the "Buy" button is pressed, just go on about your business. When you are notified that there are transactions (which could be tomorrow) process them. I believe there's a comment to this effect in the documentation -- that your app should register for SK notifications when it's launched and it should expect to get them at any time. So don't build any awareness of "state" into your app when it comes to Store Kit. Just process the transactions as they arrive.

这篇关于在应用程序购买中,用户在后台应用时取消tx:tx状态继续购买的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆