نفسه هنا. يمكن لأي شخص أن يساعد؟

ليست معلقة ، ولكنها تُرجع []

يظهر لنا مربع حوار الشراء ، ويتم استدعاء مستمع الشراء بشكل صحيح ، لكن مكالمة requestSubscription ترجع وعدًا لم يتم الوفاء به أبدًا.

يبدو أنه قد تم حل هذا هنا https://github.com/dooboolab/react-native-iap/pull/1064

لقد طبقت هذا الإصلاح الوعد سابقًا ، لذا فهذه ليست المشكلة هنا.

يعمل معي مع 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 بغض النظر عن الطريقة التي أسمي بها الطريقة ، وهي تعمل بشكل جيد على أجهزة iPhone و iPad التي تعمل بنظام iOS 13 عبر TestFlight. لقد اختبرت requestSubscription مع منطقي وبدونه ولم أحصل على مربعات حوار الشراء على iOS 14. الآن في معظم الأحيان يستدعي RequestUpdatedListener فورًا بما يبدو أنه إيصال غير صالح.

هل هناك آخرون ليس لديهم مشاكل مع اشتراكاتهم في iOS14 و xCode 12 باستخدام TestFlight؟

مرحبًا ، هل يستخدم أي منكم getPurchaseHistory() أو getAvailablePurchases() قبل requestSubscription() ؟ إذا كان الأمر كذلك ، يبدو أن هذه هي المشكلة في نظام التشغيل iOS 14.

أحصل على مشترياتي () في وقت سابق من التدفق - عند تحميل التطبيق ، تظهر الشاشة مباشرة قبل شاشة الاشتراك الخاصة بي.

نعم ، للأسف يبدو أن هذا خطأ في iOS 14. لا يوجد خطأ في هذا البرنامج المساعد. لقد تحققت من الكود الأصلي وهي نفس المشكلة.

كانت تلك هي المشكلة. لقد أزلت الاتصال بـ getAvailablePurchases () وحدثت النوافذ المنبثقة للشراء وتم الشراء بنجاح. للأسف ، أحتاج إلى إجراء هذه المكالمة للحصول على مشتريات متاحة ، لأنني أتحقق من حالة اشتراكهم عند تحميل التطبيق. إذن يبدو أننا بحاجة إلى انتظار تصحيح iOS 14 لإصلاح هذا؟ لا شيء آخر يمكن لأي شخص القيام به؟ بالمناسبة ، شكرا جزيلا لك على Dev23!

على الرحب والسعة. ربما يكون أفضل رهان لك هو الاعتماد على فحص يستند إلى الخادم.

كنت آمل أن أتجنب جعل الخادم يقوم بذلك. هل هو سهل مثل نسخ الرمز من رد الفعل الخاص بي إلى شيء مثل وظيفة Firebase Cloud؟ أم أن هذا شيء يحتاج إلى إعادة تصميمه؟ ربما كان سؤالًا غبيًا ، لكن مهلا .. بدأنا جميعًا في طرح أسئلة غبية. :)

@ the- dut يمكنك استخدام

مشروب من اختيارك إذا كنت في الغرب الأوسط بالولايات المتحدة. :)

نفس المشكلة هنا تؤثر على المستخدمين المباشرين. @ theDev23 هل لديك رابط أي مناقشات حول المشكلة في iOS؟ هل هناك أي جداول زمنية للإصلاح؟

nicknjpconsultingllc لا رابط ، آسف. لقد قمت بالحفر بنفسي.

@ the-dut أنا أستخدم وظائف Firebase Cloud أيضًا. تحقق من هذا الريبو .

انتهى بي الأمر بحفظ الإيصال في قاعدة بيانات عند الشراء الناجح في PurchaseUpdatedListener ، ثم عند تحميل التطبيق ، أقوم بسحب الإيصال من قاعدة البيانات ، والتحقق من صحته مرة أخرى والتحقق لمعرفة ما إذا كان منتهي الصلاحية أم لا. سمح لي ذلك بالتخلص من المكالمة الخاصة بـ getAvailablePurchases () هل تعمل بشكل رائع في iOS14. لقد عملت بشكل جيد حتى الآن وهي أسرع بكثير. الآن سؤال حول إلى أي مدى يجب أن آخذ هذا. إذا كان هذا هو كل ما أفعله ، فهل سيتم استدعاء برنامج UpdatedPurchaseListener على جميع تحديثات الاشتراك (بشكل أساسي التجديدات التلقائية) حتى أنتهي من المعاملات؟ أو هل أحتاج إلى تنفيذ الإشعارات من خادم إلى خادم لأتعرف على التجديدات التلقائية؟ يبدو أن استخدام UpdatedPurchaseListener هو حل أفضل (وأبسط) منذ أن كنت أقرأ أن التكامل من خادم إلى خادم ليس مثاليًا.

لا تزال تواجه هذه المشكلة بعد إزالة getPurchaseHistory وتطبيق الإصلاح الوعد. لا يمكن الحصول على مربع حوار الشراء المنبثق. يمكن لأي شخص أن يساعد؟

أود أن أقول ألق نظرة على أي / جميع المكالمات التي تجريها إلى AIP قبل القيام بطلب الشراء. هل تتصل بـ getAvailablePurchases () أيضًا؟

لا يمكنني استبعاد مكالمات getAvailablePurchases () و getPurchaseHistory () ، فهل هناك على أي حال لجعله يطلب الاشتراك () المنبثقة في قائمة الشراء بهذه المكالمات؟

مرحبًا @ HamzaIkram2727 ، إذا لم أكن مخطئًا ، يمكنك فقط إنشاء حساب رمل جديد لاستخدامه وحذف الحساب القديم. يجب أن يعمل.

@ the-dut حتى أنني لا أستخدم أي مكالمات getAvailablePurchases () و getPurchaseHistory () ، ما زلت أواجه نفس المشكلة. لا يُظهر مربع حوار الشراء ولكن تم الشراء بنجاح تلقائيًا.

أنا أيضًا أستدعي دالات finishTrsanactionIOS و finishTransation

تمكنت من الحصول على مربع حوار الشراء الأصلي لنظام iOS عن طريق الخروج من التطبيق. هذا يبدو لي وكأن بعض الوعود حُلت أخيرًا. لست متأكدًا مما إذا كان هناك أي تبعيات واعدة في react-native-iap لكن السلوك يبدو غريبًا. يؤدي استدعاء requestSubscription حل المشكلة في التطبيق ولكن لا يوجد مربع حوار حتى أخرج من التطبيق.

أواجه نفس المشكلة مع getAvailblePruchases () ، في معظم الأوقات لا يحل الوعد أو يرفض. بدأ ذلك عند الاختبار على أجهزة iOS 14.

انا لدى نفس المشكله

1. اتصل بـ getAvailablePurchases ()
2. طلب اشتراك ()

لقد قمت بإزالة getAvailablePurchase ويبدو أنه يعمل بشكل جيد

أي تحديثات؟

سلوك غريب حقًا وما ألاحظه ليس فقط على نظام iOS 14 الذي يحدث ... أنا أتصل بشركة Apple لمحاولة فهم ما يحدث لأنني لا أعتقد أنها مشكلة متعلقة بالحزمة الذات.

هنا فقط لأقول إنني أواجه نفس المشكلة. لقد اختبرت بالفعل على نظام التشغيل iOS 12 وهو يعمل بشكل جيد ... نظام iOS 14 عبارة عن عربات التي تجرها الدواب.

نداء الطلب الخاص بيالاشتراك يدوم إلى الأبد ... وهو يتنقل في الإنتاج!

حسنًا ، بعد يوم من "الاستمتاع" هذا ما توصلت إليه حتى الآن ... لدي أجهزة مختلفة على إصدارات نظام تشغيل مختلفة ولدي هذه المشكلة على كل منها. لقد اتصلت بشركة Apple بخصوص هذا الأمر وما زلنا نتابع القضية ، ومع ذلك ، دون أي استنتاجات قوية. لا أعتقد أنها مشكلة في الحزمة ، يجب أن تكون شيئًا من جانب Apple. لقد جربت كل شيء يذكره الأشخاص في هذا الموضوع وفي سلاسل الرسائل الأخرى التي أبلغت عن مشكلة مماثلة. مربع حوار شراء التطبيق غير متناسق عند الظهور وحتى الآن ، لا يمكنني العثور على سبب وجيه لذلك لأن النتيجة مختلفة دائمًا. أحيانًا أحصل على خطأ E_UNKNOWN ، وأحيانًا لا أحصل على أي ملاحظات ، وأحيانًا تظهر النوافذ المنبثقة بعد 10 دقائق من الانتظار وأحيانًا أخرى تعمل فقط ... نفس النتائج المختلفة لنفس المستخدم والجهاز ولا يتم عرض أي خطأ أو سجل قاطع / ثاقب. هذا أمر محبط للتصحيح لأنه لا يمكنك العثور على أي شيء تقريبًا ... حسنًا ، إذا كان لديكم أي نوع من النصائح أو البصيرة ، فأنا أستمع ... في غضون ذلك ، إذا تلقيت بعض الأخبار من Apple ، سأبقيك على اطلاع ...
تحرير PS. بعد قراءة التعليق الأخير ، هناك شيء واحد ثابت ويمكنني تأكيده ، في iOS 14 يبدو الشيء أكثر تناقضًا على الرغم من حدوثه في كل إصدار من إصدارات نظام التشغيل الذي اختبرته (12 ، 13.7 ، 14). ومع ذلك ، ما زلت لدي انطباع بأن المشكلة لا تتعلق فقط بإصدار نظام التشغيل وهذا هو السبب في أنني أعتقد أنه يجب أن يكون شيئًا ما مع خادم Sandbox أو أي شيء آخر في نهاية Apple ..

لقد اختبرنا حزمة التطبيقات الخاصة بنا باستخدام إصدار معتمد من App Store ويبدو أن التناقض يظهر بشكل أكثر بروزًا في الإصدار 14 من نظام التشغيل iOS أو أحدث

استنتاجنا هو أن الطريقة التي تتحقق بها Apple من الإيصال على iOS 14+ مختلفة قليلاً.

يحدث ذلك مع الحسابات التي قامت بعمليات شراء بالفعل

1. قم بإنشاء حساب جديد في Sandbox
2. إجراء عملية شراء (تعمل بشكل جيد لأن عمليات الاستعادة لا تحتوي على مشتريات)
3. انتظر حتى تنتهي صلاحيته.
4. شراء مرة أخرى. (الآن تستجيب عمليات الشراء المستعادة كائنًا ، ولم تعد النافذة المنبثقة لتأكيد الشراء تعمل)

هذا غريب. كنت أقوم بمراجعة كود المكتبة وأضفت بعض السجلات للاختبار. وحصلت على ما يلي

1. عندما يتم استدعاء عمليات الاستعادة. يتم تشغيل المستمع "paymentQueueRestoreCompletedTransactionsFinished"

-(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 عنصرًا

1. يتم تنفيذ وظيفة paymentQueue لإنهاء عمليات الاستعادة

case SKPaymentTransactionStateRestored: {
          NSLog(@"Restored ");

         NSLog(@"\n  paymentQueue transaction : %@", transaction.transactionDate);
         [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
           break;
  }

1. solutionPromisesForKey أكمل عملية الاستعادة

2. requestSubscription ابدأ باستدعاء الوظيفة buyProduct

3. هنا أضفت سجلات لمشاهدة السجل

 NSLog(@"\n  produc purchase : %@", product);

  SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

  NSLog(@"\n  payment buy product : %@", payment.productIdentifier);

  [[SKPaymentQueue defaultQueue] addPayment:payment];

1. حصلت على السجل التالي:
   أ) سجل RestorePurchases

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] 

ب. 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**

لذلك لا أفهم سبب تنفيذ طريقة paymentQueue باستخدام SKPaymentTransactionStateRestored بتاريخ 5 أكتوبر

andresordonezfm هل اتصلت بـ finishTransaction بعد الشراء؟

أيضًا فيما يتعلق بالنوافذ المنبثقة ، إليك تجارب رائعة معطاة في # 863. آمل أن يساعد.

andresordonezfm هل اتصلت بـ finishTransaction بعد الشراء؟

أكيد! اتصلت أيضًا بـ clearTransactionIOS () على أي حال إذا كان من الممكن أن تكون المشكلة ولكن لا شيء.

أيضًا فيما يتعلق بالنوافذ المنبثقة ، إليك تجارب رائعة معطاة في # 863. آمل أن يساعد.

شكرا لك. سأقوم بمراجعته

أي حلول / تحديثات؟

لا شيء حتى الان. كنت أراجع وأضفت Apple ميزات جديدة في StoreKit وأنواع الإشعارات ..
لست متأكدًا مما إذا كانت هذه هي المشكلة

https://developer.apple.com/videos/play/wwdc2020/10661/

لقد خفضت الحزمة إلى 4.5.2 عملت معي
تحقق مما إذا كنت تتصل
await RNIap.initConnection();
قبل طلب RNIap

يبدو أنني حللت بعد هذه المشكلة:
https://github.com/dooboolab/react-native-iap/issues/1146

بادئ ذي بدء ، عندما كنت أتحقق من صحة الإيصال ، كنت أمرر true كمعامل isTest (حتى عندما كان إصدار إنتاج).
ثم أضفت RNIap.clearTransactionIOS(); في purchaseUpdatedListener قبل التحقق من صحة الإيصال و RNIap.finishTransaction(purchase, false) بعد RNIap.finishTransactionIOS(purchase.transactionId);

لقد اختبرت في TestFlight ويمكنني إكمال عملية شراء لأول مرة (باستخدام حساب sandbox) ، والآن سأختبرها في الإنتاج 🤞

يبدو أنني حللت بعد هذه المشكلة:

1146

بادئ ذي بدء ، عندما كنت أتحقق من صحة الإيصال ، كنت أمرر true كمعامل isTest (حتى عندما كان إصدار إنتاج).
ثم أضفت RNIap.clearTransactionIOS(); في purchaseUpdatedListener قبل التحقق من صحة الإيصال و RNIap.finishTransaction(purchase, false) بعد RNIap.finishTransactionIOS(purchase.transactionId);

لقد اختبرت في TestFlight ويمكنني إكمال عملية شراء لأول مرة (باستخدام حساب sandbox) ، والآن سأختبرها في الإنتاج 🤞

مرحبًا يا صاح ، لقد جربت هذا الحل ولكن لم يعمل معي.

أنا أواجه نفس المشكلة. يحدث ذلك عند محاولة شراء الاشتراك بعد استعادة الشراء.

يمكنني تأكيد السجلات من andresordonezfm ، حيث يبدو أن SKPaymentQueue يتلقى معاملة من النوع SKPaymentTransactionStateRestored ، بدلاً من النوع SKPaymentTransactionStatePurchasing ، وهو سبب "الاستعادة" سلسلة يتم تسجيلها عند الشراء.

مرحبا شباب آسف للتأخير.

كنت أقوم بالمراجعة ووجدت حلاً لهذه المشكلة. تكمن المشكلة في أنه قبل استدعاء عمليات الشراء المستعادة ، لا تغلق المعاملات المفتوحة حديثًا لنفس عمليات الاستعادة بشكل صحيح. ثم أغلقهم بالقوة.

ثم وظيفة clearTransactionIOS للمكتبة ، يجب إضافة الوعد لانتظار إغلاق المعاملات باستخدام الوظيفة التي تمت إزالتها

هذا هو الكود الخاص بي:

الملف: رد فعل أصلي - iap / ios / RNIapIos.m

1. استبدل الدالة RCT_EXPORT_METHOD (clearTransaction) بالتعليمة البرمجية التالية

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);
    }
}

1. أضف الوظيفة الجديدة التالية (لقد أضفت هذه الوظيفة في نهاية ملف RNIapIos.m. قبل السطر "end")

-(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;
        }
    }
}

الملف: رد فعل-أصلي- iap / ios / RNIapIos.h

1. تحت الكود "SKProduct * promotionProduct؛" أضف السطر التالي

  NSInteger countPendingTransaction;

أخيرًا قبل استدعاء وظيفة "RNIap.requestSubscription (productId، false)".
يجب استدعاء الدالة clearTransactionIOS ، على سبيل المثال:

    if (Platform.OS === 'ios') {
      await RNIap.clearTransactionIOS();
    }
    await RNIap.requestSubscription(productId, false);

اتمني ان يكون مفيدا. السلوك الغريب لاستعادة المشتريات لم أتمكن من العثور على السبب. لكن هذا حل لي الاختبار في Sandbox.

إذا كان لديك أي اقتراحات، واسمحوا لي أن أعرف.

لدي أيضًا هذه المشكلة ， يرجى المؤلف ، ساعدني ، أشكر عائلتك

لدي أيضًا هذه المشكلة ， يرجى المؤلف ، ساعدني ، أشكر عائلتك

مرحبًا يا صاح ، في التعليق السابق ، تم شرح الخطوات التي قمت بها لحلها

إذا كان لديك أي تعليقات ، أخبرني

andresordonezfm ، هل أنت على استعداد لإنشاء

بالنسبة لمسألة المشتريات القادمة على أنها SKPaymentTransactionStateRestored والتي تحدث بعد الاستعادة ، قمت بإنشاء حساب جديد وقمت ببعض عمليات الشراء ولم يحدث ذلك لهذا الحساب. يمكنني الاتصال بـ RNIap.getAvailablePurchases() و RNIap.requestSubscription() بعد ذلك.

يبدو أنه قد يكون مرتبطًا بكمية المشتريات التي قام بها المستخدم؟ لم أجري أي اختبارات على الإنتاج حتى الآن.

حسنًا ، بعد يوم من "الاستمتاع" هذا ما توصلت إليه حتى الآن ... لدي أجهزة مختلفة على إصدارات نظام تشغيل مختلفة ولدي هذه المشكلة على كل منها. لقد اتصلت بشركة Apple بخصوص هذا الأمر وما زلنا نتابع القضية ، ومع ذلك ، دون أي استنتاجات قوية. لا أعتقد أنها مشكلة في الحزمة ، يجب أن تكون شيئًا من جانب Apple. لقد جربت كل شيء يذكره الأشخاص في هذا الموضوع وفي سلاسل الرسائل الأخرى التي أبلغت عن مشكلة مماثلة. مربع حوار شراء التطبيق غير متناسق عند الظهور وحتى الآن ، لا يمكنني العثور على سبب وجيه لذلك لأن النتيجة مختلفة دائمًا. أحيانًا أحصل على خطأ E_UNKNOWN ، وأحيانًا لا أحصل على أي ملاحظات ، وأحيانًا تظهر النوافذ المنبثقة بعد 10 دقائق من الانتظار وأحيانًا أخرى تعمل فقط ... نفس النتائج المختلفة لنفس المستخدم والجهاز ولا يتم عرض أي خطأ أو سجل قاطع / ثاقب. هذا أمر محبط للتصحيح لأنه لا يمكنك العثور على أي شيء تقريبًا ... حسنًا ، إذا كان لديكم أي نوع من النصائح أو البصيرة ، فأنا أستمع ... في غضون ذلك ، إذا تلقيت بعض الأخبار من Apple ، سأبقيك على اطلاع ...
تحرير PS. بعد قراءة التعليق الأخير ، هناك شيء واحد ثابت ويمكنني تأكيده ، في iOS 14 يبدو الشيء أكثر تناقضًا على الرغم من حدوثه في كل إصدار من إصدارات نظام التشغيل الذي اختبرته (12 ، 13.7 ، 14). ومع ذلك ، ما زلت لدي انطباع بأن المشكلة لا تتعلق فقط بإصدار نظام التشغيل وهذا هو السبب في أنني أعتقد أنه يجب أن يكون شيئًا ما مع خادم Sandbox أو أي شيء آخر في نهاية Apple ..

بالضبط ما أواجهه من andresordonezfm (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-734805587). @ 106firestarter ، هل

في غضون ذلك ، سأرى ما يمكنني العثور عليه في منتديات المطورين.

بالنسبة لمسألة المشتريات القادمة على أنها SKPaymentTransactionStateRestored والتي تحدث بعد الاستعادة ، قمت بإنشاء حساب جديد وقمت ببعض عمليات الشراء ولم يحدث ذلك لهذا الحساب. يمكنني الاتصال بـ RNIap.getAvailablePurchases() و RNIap.requestSubscription() بعد ذلك.

يبدو أنه قد يكون مرتبطًا بكمية المشتريات التي قام بها المستخدم؟ لم أجري أي اختبارات على الإنتاج حتى الآن.

سأحاول ذلك ، لكن الإنتاج يمثل مصدر قلق أيضًا.

للسجل ، أتصل أيضًا بـ getAvailablePurchases() قبل requestSubscription() .

يحتمل أن تكون ذات صلة:

• https://developer.apple.com/forums/thread/669435

يمكنني أن أؤكد أيضًا أنه مع حساب جديد تمامًا ، لم تعد المشكلة كما ذكر Paduado (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-742685043).

تصحيح: استخدام حساب جديد تمامًا مع الإصلاح الذي اقترحه andresordonezfm يجعله يعمل من جانبي. بدون الإصلاح ، بعد أول اشتراك ، يظهر نفس السلوك الذي كنت أواجهه من قبل مرة أخرى ولم يعد بإمكاني الاشتراك مرة أخرى. هناك شيء آخر لاحظته بعد تطبيق الإصلاح وهو أن الاشتراكات لم تعد تتجدد تلقائيًا بعد الآن ، ولا حتى مرة واحدة ، على الرغم من استخدام وضع الحماية من المتوقع أن يتم تجديدها 5 مرات.

andresordonezfm ، هل أنت على استعداد لإنشاء

مرحبا يا صاح آسف للتأخير مرة أخرى. لقد أنشأت طلب سحب للتفاعل مع iap الأصلي

يمكنني أن أؤكد أيضًا أنه مع حساب جديد تمامًا ، لم تعد المشكلة كما ذكر Paduado ( # 1120 (تعليق) ). ~

تصحيح: استخدام حساب جديد تمامًا مع الإصلاح الذي اقترحه andresordonezfm يجعله يعمل من جانبي. بدون الإصلاح ، بعد أول اشتراك ، يظهر نفس السلوك الذي كنت أواجهه من قبل مرة أخرى ولم يعد بإمكاني الاشتراك مرة أخرى. هناك شيء آخر لاحظته بعد تطبيق الإصلاح وهو أن الاشتراكات لم تعد تتجدد تلقائيًا بعد الآن ، ولا حتى مرة واحدة ، على الرغم من استخدام وضع الحماية من المتوقع أن يتم تجديدها 5 مرات.

مرحباً يا صاح أعتقد أنها مشكلة رمل. هل تستمر في إعطاء هذا السلوك؟

andresordonezfm نعم ، أظن أيضًا أنها مشكلة في وضع الحماية من Apple. لم أقم بإجراء المزيد من الاختبارات منذ تعليقي الأخير ولم أتحقق من الإنتاج بعد. ومع ذلك ، حتى الآن ، لم أتلق أي شكاوى من العملاء.

يبدو أن وضع الحماية قد عاد إلى المسار الصحيح من جانبي عند استخدام حساب جديد تمامًا ، كما ورد سابقًا بواسطة Paduado ، دون إجراء أي تغييرات على الكود. 🤷‍♂️ 😕

andresordonezfm لقد واجهت نفس الشيء وطبقات التصحيح الخاصة بك لإصلاحها. ومع ذلك ، أعتقد أنني أرى خطأً خفيًا في شفرتك والذي من المحتمل أن يتسبب في تعليق cleartTransactionsIOS() . قد يتم استدعاء removeTransactions مع معاملة واحدة أو أكثر ليتم إزالتها. لذا في removeTransactions ، أعتقد أننا نريد:

        countPendingTransaction -= [transactions count];

من الناحية العملية ، رأيت فقط removedTransactions استدعاؤه بمعاملة واحدة ، لكن مستندات Apple تقول إنها قد تكون واحدة أو أكثر. اكتشاف جميل بالمناسبة! لقد علقت في هذا لفترة من الوقت.

andresordonezfm لقد واجهت نفس الشيء وطبقات التصحيح الخاصة بك لإصلاحها. ومع ذلك ، أعتقد أنني أرى خطأً خفيًا في شفرتك والذي من المحتمل أن يتسبب في تعليق cleartTransactionsIOS() . قد يتم استدعاء removeTransactions مع معاملة واحدة أو أكثر ليتم إزالتها. لذا في removeTransactions ، أعتقد أننا نريد:

        countPendingTransaction -= [transactions count];

من الناحية العملية ، رأيت فقط removedTransactions استدعاؤه بمعاملة واحدة ، لكن مستندات Apple تقول إنها قد تكون واحدة أو أكثر. اكتشاف جميل بالمناسبة! لقد علقت في هذا لفترة من الوقت.

مرحبا يا صاح ، شكرا لك على التوصية. لقد اختبرت اقتراحك وهو يعمل جيدًا بالنسبة لي. لقد قدمت طلب سحب مع هذا التغيير.

ملحوظة: نعم ، لقد راجعت تلك الوثائق ولكن نظرًا لإطلاقها فقط من معاملة إلى أخرى لم أقم بتنفيذها. لكنها توصية جيدة للغاية. شكرا لك!