3.0.3
0.59.10
ذكري المظهر
لا تحذير وعد لم يتم التعامل معه
09-03 16:42:41.214 20367 21085 I ReactNativeJS: 'purchaseErrorListener', { debugMessage: '', responseCode: 1 }
09-03 16:42:43.254 20367 21085 W ReactNativeJS: Possible Unhandled Promise Rejection (id: 0):
09-03 16:42:43.254 20367 21085 W ReactNativeJS: Error: Payment is Cancelled.
09-03 16:42:43.254 20367 21085 W ReactNativeJS: createErrorFromErrorData<strong i="14">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2108:26
09-03 16:42:43.254 20367 21085 W ReactNativeJS: http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2060:51
09-03 16:42:43.254 20367 21085 W ReactNativeJS: __invokeCallback<strong i="15">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2627:23
09-03 16:42:43.254 20367 21085 W ReactNativeJS: http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2358:34
09-03 16:42:43.254 20367 21085 W ReactNativeJS: __guard<strong i="16">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2531:15
09-03 16:42:43.254 20367 21085 W ReactNativeJS: invokeCallbackAndReturnFlushedQueue<strong i="17">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2357:21
09-03 16:42:43.254 20367 21085 W ReactNativeJS: invokeCallbackAndReturnFlushedQueue@[native code]
جهاز حقيقي
إنشاء تطبيق مثال على الفرع 3.0.x. تشغيل على الجهاز ، المس Get Products
، ثم المس Purchase android.test.canceled
كما أفهم ، يحدث ذلك بسبب هذا السطر: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapModule.java# المستخدمة في عدد قليل من الأماكن الأخرى كذلك.
لا أفهم سبب استدعاء هذه الوظائف بعد إطلاق حدث الخطأ. يبدو أن هناك مزيجًا من طريقتين مستخدمتين هنا.
يتم إنشاء الوعد الجديد عند كل تهيئة ثم يتم حله أو رفضه بناءً على نتائج العملية إلى جانب إرسال الأحداث عبر DeviceEventManagerModule
.
لكن كما فهمت من المستندات ، فإن الطريقة الوحيدة للتواصل مع المكتبة هي عبر الأحداث ، فالوعود أصبحت مهملة الآن.
ربما لا أحصل على شيء ما بشكل صحيح ، ولكن من وجهة نظري ، لا ينبغي للمكتبة أن ترفض الوعود عند إرسال أحداث الخطأ.
hyochan أية أفكار أخرى؟ أنا مستعد للمساهمة ، فقط أريد أن أفهم أنني أتجه إلى الاتجاه الصحيح.
gaykov أنت على حق. يبدو أن هذا أثر جانبي في محاولة لدعم كل من event
و promises
. على أمل التحسين من PR
🔨
مرحبًا ، يبدو أنه لم يكن هناك أي نشاط بشأن هذه المشكلة مؤخرًا. هل تم إصلاح المشكلة أم أنها لا تزال تتطلب اهتمام المجتمع؟ قد يتم إغلاق هذه المشكلة في حالة عدم حدوث أي نشاط آخر. يمكنك أيضًا تصنيف هذه المشكلة على أنها "للمناقشة" أو "مشكلة أولى جيدة" وسأتركها مفتوحة. شكرا لمساهماتكم.
إغلاق هذه القضية بعد فترة طويلة من عدم النشاط. إذا كانت هذه المشكلة لا تزال موجودة في الإصدار الأخير ، فلا تتردد في إنشاء مشكلة جديدة بمعلومات محدثة.
التعليق الأكثر فائدة
كما أفهم ، يحدث ذلك بسبب هذا السطر: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapModule.java# المستخدمة في عدد قليل من الأماكن الأخرى كذلك.
لا أفهم سبب استدعاء هذه الوظائف بعد إطلاق حدث الخطأ. يبدو أن هناك مزيجًا من طريقتين مستخدمتين هنا.
يتم إنشاء الوعد الجديد عند كل تهيئة ثم يتم حله أو رفضه بناءً على نتائج العملية إلى جانب إرسال الأحداث عبر
DeviceEventManagerModule
.لكن كما فهمت من المستندات ، فإن الطريقة الوحيدة للتواصل مع المكتبة هي عبر الأحداث ، فالوعود أصبحت مهملة الآن.
ربما لا أحصل على شيء ما بشكل صحيح ، ولكن من وجهة نظري ، لا ينبغي للمكتبة أن ترفض الوعود عند إرسال أحداث الخطأ.
hyochan أية أفكار أخرى؟ أنا مستعد للمساهمة ، فقط أريد أن أفهم أنني أتجه إلى الاتجاه الصحيح.