3.0.3
0,59,10
Android
Keine unbehandelte Versprechen Warnung
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]
Echtes Gerät
Erstellen Sie eine Beispiel-App im Zweig 3.0.x. Führen Sie es auf dem Gerät aus, berühren Sie Get Products
und anschließend Purchase android.test.canceled
Soweit ich weiß, geschieht dies aufgrund dieser Zeile: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapM auch an einigen anderen Orten verwendet.
Ich kann nicht verstehen, warum diese Funktionen aufgerufen werden, nachdem das Fehlerereignis ausgelöst wurde. Es sieht so aus, als ob hier eine Kombination von zwei Ansätzen verwendet wird.
Das neue Versprechen wird bei jeder Initialisierung erstellt und dann abhängig von den Operationsergebnissen aufgelöst oder abgelehnt. Außerdem werden Ereignisse über DeviceEventManagerModule
.
Aber wie ich aus den Dokumenten verstanden habe, ist die einzige Möglichkeit der Kommunikation mit der Bibliothek über Ereignisse. Versprechen sind jetzt veraltet.
Vielleicht verstehe ich etwas nicht richtig, aber aus meiner Sicht sollte die Bibliothek beim Senden von Fehlerereignissen keine Versprechen ablehnen.
@hyochan Irgendwelche anderen Ideen? Ich bin bereit, einen Beitrag zu leisten, möchte nur verstehen, dass ich mich in die richtige Richtung bewege.
@gaykov Du hast recht. Sieht so aus, als wäre dies ein Nebeneffekt bei dem Versuch, sowohl event
als auch promises
. Ich hoffe auf eine Verbesserung von Ihrem PR
🔨
Hey, es sieht so aus, als ob es in letzter Zeit keine Aktivitäten zu diesem Thema gegeben hat. Wurde das Problem behoben oder erfordert es immer noch die Aufmerksamkeit der Community? Dieses Problem kann geschlossen werden, wenn keine weitere Aktivität auftritt. Sie können diese Ausgabe auch als "Zur Diskussion" oder "Gute erste Ausgabe" bezeichnen, und ich werde sie offen lassen. Vielen Dank für Ihre Beiträge.
Schließen dieses Problems nach längerer Inaktivität. Wenn dieses Problem in der neuesten Version noch vorhanden ist, können Sie ein neues Problem mit aktuellen Informationen erstellen.
Hilfreichster Kommentar
Soweit ich weiß, geschieht dies aufgrund dieser Zeile: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/RNIapM auch an einigen anderen Orten verwendet.
Ich kann nicht verstehen, warum diese Funktionen aufgerufen werden, nachdem das Fehlerereignis ausgelöst wurde. Es sieht so aus, als ob hier eine Kombination von zwei Ansätzen verwendet wird.
Das neue Versprechen wird bei jeder Initialisierung erstellt und dann abhängig von den Operationsergebnissen aufgelöst oder abgelehnt. Außerdem werden Ereignisse über
DeviceEventManagerModule
.Aber wie ich aus den Dokumenten verstanden habe, ist die einzige Möglichkeit der Kommunikation mit der Bibliothek über Ereignisse. Versprechen sind jetzt veraltet.
Vielleicht verstehe ich etwas nicht richtig, aber aus meiner Sicht sollte die Bibliothek beim Senden von Fehlerereignissen keine Versprechen ablehnen.
@hyochan Irgendwelche anderen Ideen? Ich bin bereit, einen Beitrag zu leisten, möchte nur verstehen, dass ich mich in die richtige Richtung bewege.