3.0.3
0,59,10
Android
Aucun avertissement de promesse non gérée
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]
Appareil réel
Créez un exemple d'application sur la branche 3.0.x. Exécutez sur l'appareil, touchez Get Products
, puis touchez Purchase android.test.canceled
Si je comprends bien, cela se produit à cause de cette ligne: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapModule.j utilisé dans quelques autres endroits également.
Je ne comprends pas pourquoi ces fonctions sont appelées après le déclenchement d'un événement d'erreur. On dirait qu'une combinaison de 2 approches est utilisée ici.
La nouvelle promesse est en cours de création à chaque initialisation, puis elle est résolue ou rejetée en fonction des résultats de l'opération avec l'envoi d'événements via DeviceEventManagerModule
.
Mais comme je l'ai compris à partir de la documentation, le seul moyen de communication avec la bibliothèque est via des événements, les promesses sont désormais obsolètes.
Peut-être que je n'obtiens pas quelque chose correctement, mais de mon point de vue, la bibliothèque ne devrait pas rejeter les promesses lors de l'envoi d'événements d'erreur.
@hyochan D' autres idées? Je suis prêt à contribuer, je veux juste comprendre que je vais dans la bonne direction.
@gaykov Vous avez raison. On dirait que c'est un effet secondaire dans un effort pour prendre en charge à la fois event
et promises
. En espérant une amélioration de votre PR
🔨
Salut, il semble qu'il n'y ait eu aucune activité sur ce problème récemment. Le problème a-t-il été résolu ou nécessite-t-il toujours l'attention de la communauté? Ce problème peut être résolu si aucune autre activité ne se produit. Vous pouvez également étiqueter ce problème comme "Pour discussion" ou "Bon premier numéro" et je le laisserai ouvert. Merci pour vos contributions.
Clôture de ce numéro après une période d'inactivité prolongée. Si ce problème est toujours présent dans la dernière version, n'hésitez pas à créer un nouveau problème avec des informations à jour.
Commentaire le plus utile
Si je comprends bien, cela se produit à cause de cette ligne: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapModule.j utilisé dans quelques autres endroits également.
Je ne comprends pas pourquoi ces fonctions sont appelées après le déclenchement d'un événement d'erreur. On dirait qu'une combinaison de 2 approches est utilisée ici.
La nouvelle promesse est en cours de création à chaque initialisation, puis elle est résolue ou rejetée en fonction des résultats de l'opération avec l'envoi d'événements via
DeviceEventManagerModule
.Mais comme je l'ai compris à partir de la documentation, le seul moyen de communication avec la bibliothèque est via des événements, les promesses sont désormais obsolètes.
Peut-être que je n'obtiens pas quelque chose correctement, mais de mon point de vue, la bibliothèque ne devrait pas rejeter les promesses lors de l'envoi d'événements d'erreur.
@hyochan D' autres idées? Je suis prêt à contribuer, je veux juste comprendre que je vais dans la bonne direction.