购买耗材时的应用内结算问题

时间:2014-11-19 00:02:34

标签: android in-app-purchase in-app-billing

我有几个销售订阅的应用程序,但现在我正在销售消费品,而且它的工作效果不太好。我出售消耗品,订单确实经过但我的代码立即消费和供应不起作用。 。

public void btnTranslations_Clicked(View v)
{
    String payload = "";
    DebugLog.debugLog("Launching translations purchase flow", false);
    mHelper.launchPurchaseFlow(this, SKU_TRANSLATIONS, RC_REQUEST,
            mPurchaseFinishedListener, payload);
}
    // Callback for when a purchase is finished
    IabHelper.OnIabPurchaseFinishedListener mPurchaseFinishedListener = new IabHelper.OnIabPurchaseFinishedListener() {
        public void onIabPurchaseFinished(IabResult result, Purchase purchase) {
            DebugLog.debugLog("In Purchase finished: " + result + ", purchase: " + purchase, false);

在上面的例子中,购买流程已成功启动,但控制权永远不会返回到PurchaseFinishedListener CallBack。我知道因为调试语句永远不会执行。

幸运的是,当应用程序再次启动时,以下代码

mHelper.queryInventoryAsync(mGotInventoryListener); 

工作正常,因为回调有效,用户在上次执行时购买的耗材被消耗和配置。

所以问题是为什么IabHelper.OnIabPLurchaseFinishedListener永远不会被执行? 谢谢, 迪安

1 个答案:

答案 0 :(得分:2)

好吧,我在这里再次回答我自己的问题。我不知道我的问题是否变得越来越难,或者这个论坛变得越来越没用了。

问题是Google文档中的错误和遗漏,this

文档完全没有说明需要以下方法来立即进行消费和配置工作。 。

   @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        Log.d(TAG, "onActivityResult(" + requestCode + "," + resultCode + "," + data);
        if (mHelper == null) return;

        // Pass on the activity result to the helper for handling
        if (!mHelper.handleActivityResult(requestCode, resultCode, data)) {
            // not handled, so handle it ourselves (here's where you'd
            // perform any handling of activity results not related to in-app
            // billing...
            super.onActivityResult(requestCode, resultCode, data);
        }
        else {
            Log.d(TAG, "onActivityResult handled by IABUtil.");
        }
    }

对mHelper.handleActivityResult的调用会以某种方式导致mPurchaseFinishedListener回调执行。 TrivialDrive示例代码有这种方法 - 他们只是认为不适合将它放在操作指南中。还有其他错误,例如如何正确包含aidl文件。

这些邋doc的文档将这几个小时的任务变成了几天的任务,因为他们的每一个遗漏/错误都需要进行研究。

也许这些文档的下一个受害者会穿越这篇文章并节省一些时间。 迪恩