4.4.9
.62.2
iOSのみ。 Androidではまだテストしていません。
購入ダイアログがポップアップして購入が完了し、purchaseUpdatedListenerが呼び出されます。
requestSubscription()を呼び出します。 購入ダイアログはありません。 PurchaseUpdatedListenerは、購入ダイアログや有効な領収書なしですぐに呼び出されました。
TestFlightを使用した実際のiOS14デバイス。
RNIap.requestSubscription()を呼び出します。
ノート:
こっちも一緒。 誰でも助けることができますか?
ぶら下がっていませんが、 []
返します
私たちの場合、購入ダイアログが表示され、購入リスナーは正しく呼び出されますが、 requestSubscription
呼び出しは、解決されない約束を返します。
これはここで解決されたようですhttps://github.com/dooboolab/react-native-iap/pull/1064
以前にそのpromise修正を適用したので、ここでは問題ではありません。
iOS14で私のために動作します、これが私がそれをした方法です:
// request purchase, listener registered above will receive notification when processing done
RNIap.requestSubscription(this.productIds[0]).catch(err => {
console.log(err.code, err.message);
});
ブールパラメータfalseを指定してメソッドを呼び出していましたが、これが推奨事項だと思います。 私はそれを削除しましたが、メソッドをどのように呼び出してもiOS14で非常に奇妙な動作が見られ、TestFlightを介してiOS13を実行しているiPhoneとiPadで正常に動作します。 ブール値の有無にかかわらずrequestSubscriptionをテストしましたが、iOS 14で購入ダイアログが表示されません。ほとんどの場合、無効なレシートのように見えるものですぐにRequestUpdatedListenerを呼び出します。
TestFlightを使用したiOS14およびxCode12でのサブスクリプションに問題がない他の人はいますか?
ねえ、 requestSubscription()
直前にgetPurchaseHistory()
またはgetAvailablePurchases()
を使用している人はいますか? もしそうなら、これはiOS14の問題のようです。
フローの早い段階でgetAvailablePurchases()を実行します。アプリの読み込み時に、サブスクリプション画面の直前の画面です。
残念ながら、これはiOS14のバグのようです。このプラグインに問題はありません。 ネイティブコードをチェックインしましたが、同じ問題です。
それが問題でした。 getAvailablePurchases()の呼び出しを削除すると、購入ポップアップが表示され、購入が成功しました。 残念ながら、App Loadでサブスクリプションのステータスを確認するため、getAvailablePurchasesを呼び出す必要があります。 では、これを修正するためにiOS 14パッチを待つ必要があるように見えますか? 他に誰もできることはありませんか? ちなみに、theDev23ありがとうございます!
どういたしまして。 最善の策は、おそらくサーバーベースのチェックに依存することです。
私はサーバーにこれを行わせないようにしたいと思っていました。 反応からFirebaseCloud Functionのようなものにコードをコピーするのと同じくらい簡単ですか? それとも、これは再構築する必要があるものですか? おそらくばかげた質問ですが、ちょっと..私たちは皆、ばかげた質問をすることから始めました。 :)
@ the- dut iaphubを使用して、サーバーの受信確認を処理できます
米国中西部にいる場合は、お好みの飲み物をお選びください。 :)
ここで同じ問題がライブユーザーに影響します。 @ theDev23 iOSの問題についての議論へのリンクがありますか? 修正のタイムラインはありますか?
@nicknjpconsultingllcリンクがありません、ごめんなさい。 私は自分で掘りました。
@ the-dut私はFirebaseCloudFunctionsも使用しています。 このリポジトリをチェックしてください。
購入が成功すると、purchaseUpdatedListenerでレシートをデータベースに保存し、アプリの読み込み時にデータベースからレシートをプルして再度検証し、有効期限が切れているかどうかを確認します。 これにより、getAvailablePurchases()の呼び出しを取り除くことができました。これは、iOS14でうまく機能します。 これまでのところ非常にうまく機能しており、はるかに高速です。 今、私がこれをどこまで取る必要があるかについての質問。 これがすべての場合、トランザクションが完了するまで、サブスクリプションのすべての更新(基本的には自動更新)でUpdatedPurchaseListenerが呼び出されますか? または、自動更新の通知を受け取るためにサーバー間通知を実装する必要がありますか? サーバー間の統合が完全ではないことを読んでいるので、UpdatedPurchaseListenerを使用する方がより良い(そしてより単純な)ソリューションであるように思われます。
getPurchaseHistoryを削除し、promise修正を適用した後も、この問題が発生します。 購入ダイアログをポップアップさせることができません。 誰か助けてもらえますか?
購入をリクエストする前に、AIPに対して行っているすべての通話を確認してください。 getAvailablePurchases()も呼び出していますか?
getAvailablePurchases()とgetPurchaseHistory()の呼び出しを除外することはできませんが、requestSubscription()にこれらの呼び出しで購入メニューをポップアップさせる方法はありますか?
こんにちは@ HamzaIkram2727 、私が間違っていなければ、新しいサンドボックスアカウントを作成して、古いアカウントを使用および削除できます。 動作するはずです。
@ the-dut getAvailablePurchases()およびgetPurchaseHistory()呼び出しを使用していなくても、同じ問題に直面しています。 購入ダイアログは表示されませんが、購入は自動的に成功します。
また、finishTrsanactionIOS関数とfinishTransation関数を呼び出しています
アプリを終了して、iOSネイティブの購入ダイアログを表示することができました。 これは、いくつかの約束が最終的に解決されたように私には見えます。 react-native-iap
promiseの依存関係があるかどうかはわかりませんが、動作がおかしいようです。 requestSubscription
を呼び出すとアプリで解決しますが、アプリを終了するまでダイアログは表示されません。
getAvailblePruchases()でも同じ問題が発生しています。ほとんどの場合、promiseは解決または拒否されません。 iOS14デバイスでテストしたときに発生し始めました。
私は同じ問題を抱えています
getAvailablePurchaseを削除しましたが、どうやら問題なく動作します
更新はありますか?
本当に奇妙な振る舞いで、私が気付いているのは、iOS14だけでなく...何が起こっているのかを理解するためにアップルに連絡しています。パッケージに関連する問題ではないと思います。自己。
ここで私が同じ問題に直面していると言うだけです。 私はすでにiOS12でテストしましたが、うまく機能しています... iOS14はバグがあります。
私のrequestSubscriptionの呼び出しは永遠に続きます...そしてそれは本番環境でバグを抱えています!
さて、「楽しんで」一日を過ごした後、これは私がこれまでに結論付けたものです...私はさまざまなOSバージョンでさまざまなデバイスを持っていますが、それぞれにこの問題があります。 私はこれに関してAppleに連絡しました、そして私達はまだ事件をフォローアップしています、しかし、確固たる結論はありません。 私はそれがパッケージの問題であるとは思わない、それはアップル側の何かであるに違いない。 私は、このスレッドや同様の問題を報告している他のスレッドで人々が言及しているすべてのことを試しました。 [アプリ内購入]ダイアログの表示に一貫性がなく、結果が常に異なるため、これまでは正当な理由を見つけることができませんでした。 E_UNKNOWNエラーが発生する場合もあれば、フィードバックがゼロになる場合もあります。10分待った後にポップアップが表示される場合もあれば、正常に機能する場合もあります。サンドボックスユーザー、非サンドボックスユーザーで試してみましたが、同じユーザーとデバイスに対して同じ異なる結果が表示され、エラーや決定的/洞察に満ちたログも表示されません。 何も見つからないので、デバッグするのはイライラします...ええと、何かアドバイスや洞察があれば、私は聞いています...それまでの間、Appleからのニュースがあれば、私はあなたを投稿し続けます...
PS編集。 最後のコメントを読んだ後、一貫性があり、確認できます。iOS14では、これをテストしたすべてのOSバージョン(12、13.7、14)で発生しますが、一貫性がないように見えます。 しかし、私はまだ問題がOSのバージョンだけに関係しているのではないという印象を持っており、それがSandboxサーバーまたはApple側の他の何かに関係しているに違いないと私が考えている理由です。
App Storeで承認されたビルドを使用してアプリパッケージをテストしましたが、iOSバージョン14以降では不整合がより顕著に発生するようです。
私たちの結論は、AppleがiOS14以降でレシートを確認する方法は少し異なるということです。
すでに購入したアカウントで発生します
それは奇妙だ。 ライブラリコードを確認していて、テスト用にいくつかのログを追加しました。 そして、私は次のものを手に入れました
-(void)paymentQueueRestoreCompletedTransactionsFinished:(SKPaymentQueue *)queue { //////// RESTORE
NSLog(@"\n\n\n paymentQueueRestoreCompletedTransactionsFinished \n\n.");
NSMutableArray* items = [NSMutableArray arrayWithCapacity:queue.transactions.count];
NSLog(@"Number of items in my array is: %d", [queue.transactions count]);//this will return (5)
for(SKPaymentTransaction *transaction in queue.transactions) {
if(transaction.transactionState == SKPaymentTransactionStateRestored
|| transaction.transactionState == SKPaymentTransactionStatePurchased) {
[self getPurchaseData:transaction withBlock:^(NSDictionary *restored) {
[items addObject:restored];
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
}];
}
}
NSLog(@"\n finished paymentQueueRestoreCompletedTransactionsFinished ");
[self resolvePromisesForKey:@"availableItems" value:items];
}
ここでは、トランザクションサイズをログに印刷し、 23個のアイテムを取得しました
case SKPaymentTransactionStateRestored: {
NSLog(@"Restored ");
NSLog(@"\n paymentQueue transaction : %@", transaction.transactionDate);
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
break;
}
resolvePromisesForKeyはrestorePurchaseを完了します
requestSubscription関数buyProductの呼び出しを開始します
NSLog(@"\n produc purchase : %@", product);
SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];
NSLog(@"\n payment buy product : %@", payment.productIdentifier);
[[SKPaymentQueue defaultQueue] addPayment:payment];
2020-10-22 14:01:49.319677-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.319784-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 16:46:53 2020
2020-10-22 14:01:49.319930-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.319970-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:16:45 2020
2020-10-22 14:01:49.320044-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320082-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:06:37 2020
2020-10-22 14:01:49.320155-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320275-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:01:37 2020
2020-10-22 14:01:49.320421-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320532-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 07:49:31 2020
2020-10-22 14:01:49.320671-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320776-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 14:21:39 2020
2020-10-22 14:01:49.320915-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321018-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 14:26:39 2020
2020-10-22 14:01:49.321180-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321282-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 16:56:53 2020
2020-10-22 14:01:49.321414-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321516-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 16:51:53 2020
2020-10-22 14:01:49.321648-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321749-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 08:04:31 2020
2020-10-22 14:01:49.321879-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321984-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:11:41 2020
2020-10-22 14:01:49.322113-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.322214-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 16:41:53 2020
2020-10-22 14:01:49.322346-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.322444-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 14:31:39 2020
2020-10-22 14:01:49.323955-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324097-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 12:07:14 2020
2020-10-22 14:01:49.324240-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324344-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 14:16:39 2020
2020-10-22 14:01:49.324474-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324579-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 14:11:39 2020
2020-10-22 14:01:49.324709-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324808-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 07:39:31 2020
2020-10-22 14:01:49.324934-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.325030-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 07:59:31 2020
2020-10-22 14:01:49.325163-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.325260-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:26:45 2020
2020-10-22 14:01:49.327079-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327212-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 07:44:31 2020
2020-10-22 14:01:49.327360-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327465-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 07:54:31 2020
2020-10-22 14:01:49.327594-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327695-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 14:37:11 2020
2020-10-22 14:01:49.327823-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327923-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:21:45 2020
2020-10-22 14:01:49.328099-0500 ApplicationTest[532:51039]
paymentQueueRestoreCompletedTransactionsFinished
2020-10-22 14:01:49.328204-0500 ApplicationTest[532:51039] Number of items in my array is: 23
2020-10-22 14:01:49.336873-0500 ApplicationTest[532:51039]
finished paymentQueueRestoreCompletedTransactionsFinished
2020-10-22 14:01:50.317721-0500 ApplicationTest[532:51234]
b。 BuySubcriptionログ:
2020-10-22 14:01:50.319607-0500 ApplicationTest[532:51234]
produc purchase : <SKProduct: 0x2839c0630>
2020-10-22 14:01:50.319694-0500 ApplicationTest[532:51234]
payment buy product : test.applicationtest
**2020-10-22 14:01:50.319849-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:50.319895-0500 ApplicationTest[532:51039]
paymentQueue transaction : Mon Oct 5 19:16:45 2020**
そのため、10月5日付けのSKPaymentTransactionStateRestoredでpaymentQueueメソッドが実行される理由がわかりません。
@andresordonezfm購入後にfinishTransaction
に電話しましたか?
ポップアップに関しても、#863で行われた素晴らしいトライアルがあります。 それが役に立てば幸い。
@andresordonezfm購入後に
finishTransaction
に電話しましたか?
承知しました! また、問題になる可能性があるが何も起こらない場合は、とにかくclearTransactionIOS()を呼び出しました。
ポップアップに関しても、#863で行われた素晴らしいトライアルがあります。 それが役に立てば幸い。
ありがとうございました。 レビューします-それ
解決策/更新はありますか?
まだ何もありません。 私はレビューしていて、AppleはStoreKitとNotificationTypesに新機能を追加しました。
それが問題になるかどうかはわかりません
パッケージを4.5.2にダウングレードしました。
あなたが呼んでいるかどうかを確認してくださいawait RNIap.initConnection();
RNIap.requestSubscriptionの前
私はこの問題に続いて解決したようです:
https://github.com/dooboolab/react-native-iap/issues/1146
まず、レシートを検証したときに、 true
をisTest
パラメーターとして渡していました(本番ビルドの場合でも)。
それから私は、追加RNIap.clearTransactionIOS();
でpurchaseUpdatedListener
受領し、検証する前にRNIap.finishTransaction(purchase, false)
した後、 RNIap.finishTransactionIOS(purchase.transactionId);
TestFlightでテストし、(サンドボックスアカウントを使用して)初めて購入を完了することができました。次に、本番環境でテストします🤞
私はこの問題に続いて解決したようです:
1146
まず、レシートを検証したときに、
true
をisTest
パラメーターとして渡していました(本番ビルドの場合でも)。
それから私は、追加RNIap.clearTransactionIOS();
でpurchaseUpdatedListener
受領し、検証する前にRNIap.finishTransaction(purchase, false)
した後、RNIap.finishTransactionIOS(purchase.transactionId);
TestFlightでテストし、(サンドボックスアカウントを使用して)初めて購入を完了することができました。次に、本番環境でテストします🤞
こんにちは、私はこの解決策を試しましたが、うまくいきませんでした。
私は同じ問題に直面しています。 購入を復元した後にサブスクリプションを購入しようとすると発生します。
私はいるようです@andresordonezfm、からログを確認することができますSKPaymentQueue
のトランザクションを受け取るSKPaymentTransactionStateRestored
の代わりに、タイプSKPaymentTransactionStatePurchasing
「復元」の理由であるタイプ、購入時に記録されている文字列。
こんにちはみんな遅れてすみません。
確認していたところ、この問題の解決策が見つかりました。 問題は、復元購入を呼び出す前に、同じ復元購入の新しく開かれたトランザクションが正しく閉じられないことです。 それから私はそれらを強制的に閉じます。
次に、ライブラリのclearTransactionIOS関数、promiseを追加して、関数removeedTransactionsを使用してトランザクションが閉じられるのを待つ必要があります。
これが私のコードです:
ファイル:react-native-iap / ios / RNIapIos.m
RCT_EXPORT_METHOD(clearTransaction:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject) {
NSLog(@"\n\n\n *** clear remaining Transactions. Call this before make a new transaction \n\n.");
NSArray *pendingTrans = [[SKPaymentQueue defaultQueue] transactions];
countPendingTransaction = (NSInteger)(pendingTrans.count);
if (countPendingTransaction > 0) {
[self addPromiseForKey:@"cleaningTransactions" resolve:resolve reject:reject];
for (SKPaymentTransaction *transaction in pendingTrans) {
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
}
} else {
resolve(nil);
}
}
-(void)paymentQueue:(SKPaymentQueue *)queue removedTransactions:(NSArray *)transactions {
NSLog(@"removedTransactions");
if (countPendingTransaction != nil && countPendingTransaction > 0) {
countPendingTransaction--;
if (countPendingTransaction == 0) {
[self resolvePromisesForKey:@"cleaningTransactions" value:nil];
countPendingTransaction = nil;
}
}
}
ファイル:react-native-iap / ios / RNIapIos.h
NSInteger countPendingTransaction;
最後に、「RNIap.requestSubscription(productId、false)」関数を呼び出す前。
clearTransactionIOS関数を呼び出す必要があります。次に例を示します。
if (Platform.OS === 'ios') {
await RNIap.clearTransactionIOS();
}
await RNIap.requestSubscription(productId, false);
お役に立てば幸いです。 復元購入の奇妙な動作は、理由を見つけることができませんでした。 しかし、これは私がサンドボックスでテストすることで解決しました。
何か提案があれば私に知らせてください。
私もこの問題を抱えています、作者、助けてください、あなたの家族に感謝します
私もこの問題を抱えています、作者、助けてください、あなたの家族に感謝します
こんにちはおい、前のコメントでは、それを解決するために私がした手順が説明されています
コメントがあれば教えてください
@andresordonezfmこれらの変更のPRを作成してもよろしいですか?
復元後に発生するSKPaymentTransactionStateRestored
として発生する購入の問題については、新しいアカウントを作成して数回購入しましたが、そのアカウントでは発生しません。 その後、 RNIap.requestSubscription()
RNIap.getAvailablePurchases()
とRNIap.requestSubscription()
に電話をかけることができます。
ユーザーの購入額に関係しているようですが? 私はまだ本番環境でテストを実行していません。
さて、「楽しんで」一日を過ごした後、これは私がこれまでに結論付けたものです...私はさまざまなOSバージョンでさまざまなデバイスを持っていますが、それぞれにこの問題があります。 私はこれに関してAppleに連絡しました、そして私達はまだ事件をフォローアップしています、しかし、確固たる結論はありません。 私はそれがパッケージの問題であるとは思わない、それはアップル側の何かであるに違いない。 私は、このスレッドや同様の問題を報告している他のスレッドで人々が言及しているすべてのことを試しました。 [アプリ内購入]ダイアログの表示に一貫性がなく、結果が常に異なるため、これまでは正当な理由を見つけることができませんでした。 E_UNKNOWNエラーが発生する場合もあれば、フィードバックがゼロになる場合もあります。10分待った後にポップアップが表示される場合もあれば、正常に機能する場合もあります。サンドボックスユーザー、非サンドボックスユーザーで試してみましたが、同じユーザーとデバイスに対して同じ異なる結果が表示され、エラーや決定的/洞察に満ちたログも表示されません。 何も見つからないので、デバッグするのはイライラします...ええと、何かアドバイスや洞察があれば、私は聞いています...それまでの間、Appleからのニュースがあれば、私はあなたを投稿し続けます...
PS編集。 最後のコメントを読んだ後、一貫性があり、確認できます。iOS14では、これをテストしたすべてのOSバージョン(12、13.7、14)で発生しますが、一貫性がないように見えます。 しかし、私はまだ問題がOSのバージョンだけに関係しているのではないという印象を持っており、それがSandboxサーバーまたはApple側の他の何かに関係しているに違いないと私が考えている理由です。
@andresordonezfm (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-734805587)によって提案された修正の後でも、まさに私が自分の側で経験していることです。 @ 106firestarter 、Appleはこれまでに返信しましたか?
その間、開発者フォーラムで何が見つかるかを確認します。
復元後に発生する
SKPaymentTransactionStateRestored
として発生する購入の問題については、新しいアカウントを作成して数回購入しましたが、そのアカウントでは発生しません。 その後、RNIap.requestSubscription()
RNIap.getAvailablePurchases()
とRNIap.requestSubscription()
に電話をかけることができます。ユーザーの購入額に関係しているようですが? 私はまだ本番環境でテストを実行していません。
やってみますが、実は生産も気になります。
記録のために、 getAvailablePurchases()
前にrequestSubscription()
getAvailablePurchases()
も呼び出しています。
また、新しいアカウントでは、 @ Paduadoが述べたように問題が発生していないことも確認できます(https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-742685043)。
訂正: @andresordonezfmによって提案された修正と一緒に真新しいアカウントを使用すると、私の側でそれが機能するようになります。 修正がないと、最初のサブスクリプションの後、以前と同じ動作が再び発生し、再度サブスクリプションを行うことができなくなります。 修正を適用した後に気付いたもう1つの点は、サンドボックスを使用すると5回更新されると予想されているにもかかわらず、サブスクリプションが1回でも自動更新されなくなったように見えることです。
@andresordonezfmこれらの変更のPRを作成してもよろしいですか?
こんにちは、また遅れてすみません。 反応するプルリクエストを作成しました-ネイティブiap
〜新しいアカウントでは、 @ Paduadoが述べたように問題が発生しなくなったことも確認できます( #1120(コメント) )。〜
訂正: @andresordonezfmによって提案された修正と一緒に真新しいアカウントを使用すると、私の側でそれが機能するようになります。 修正がないと、最初のサブスクリプションの後、以前と同じ動作が再び発生し、再度サブスクリプションを行うことができなくなります。 修正を適用した後に気付いたもう1つの点は、サンドボックスを使用すると5回更新されると予想されているにもかかわらず、サブスクリプションが1回でも自動更新されなくなったように見えることです。
こんにちは、サンドボックスの問題だと思います。 あなたはその行動を与え続けますか?
@andresordonezfmはい、私もそれがAppleのサンドボックスの問題だと思います。 前回のコメント以降、これ以上テストを実行していません。まだ本番をチェックしていません。 しかし、これまでのところ、お客様からの苦情はありませんでした。
@Paduadoによって以前に報告された
@andresordonezfm同じことが発生し、パッチの継ぎ目が修正されました。 ただし、コードに微妙なバグがあり、 cleartTransactionsIOS()
がハングする可能性があると思います。 removeTransactions
は、1つ以上のトランザクションを削除して呼び出すことができます。 したがって、 removeTransactions
では、次のことが必要だと思います。
countPendingTransaction -= [transactions count];
実際には、1回のトランザクションでremovedTransactions
呼び出されるのを見ただけですが、 Appleのドキュメントによると1つ以上のトランザクションである可能性があります。 ちなみに素敵な発見! 私はしばらくこれに固執しました。
@andresordonezfm同じことが発生し、パッチの継ぎ目が修正されました。 ただし、コードに微妙なバグがあり、
cleartTransactionsIOS()
がハングする可能性があると思います。removeTransactions
は、1つ以上のトランザクションを削除して呼び出すことができます。 したがって、removeTransactions
では、次のことが必要だと思います。countPendingTransaction -= [transactions count];
実際には、1回のトランザクションで
removedTransactions
呼び出されるのを見ただけですが、 Appleのドキュメントによると1つ以上のトランザクションである可能性があります。 ちなみに素敵な発見! 私はしばらくこれに固執しました。
こんにちはおい、あなたの推薦をありがとう。 私はあなたの提案をテストしました、そしてそれは私にとってうまくいきます。 その変更でプルリクエストを行いました。
注:はい、そのドキュメントを確認しましたが、トランザクションごとにのみ発生するため、実装しませんでした。 しかし、それは非常に良い推奨事項です。 ありがとうございました!
最も参考になるコメント
ここで私が同じ問題に直面していると言うだけです。 私はすでにiOS12でテストしましたが、うまく機能しています... iOS14はバグがあります。
私のrequestSubscriptionの呼び出しは永遠に続きます...そしてそれは本番環境でバグを抱えています!