3.0.3
0,59,10
Android
Nenhum aviso de promessa não tratada
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]
Dispositivo real
Crie um aplicativo de exemplo na ramificação 3.0.x. Execute no dispositivo, toque em Get Products
, em seguida, toque em Purchase android.test.canceled
Pelo que entendi, acontece devido a esta linha: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/ Theyava# apModule.java usado em alguns outros lugares também.
Não consigo entender por que essas funções estão sendo chamadas depois que o evento de erro foi disparado. Parece que há uma combinação de 2 abordagens usadas aqui.
A nova promessa está sendo criada em cada inicialização e então é resolvida ou rejeitada dependendo dos resultados da operação junto com o envio de eventos via DeviceEventManagerModule
.
Mas, como entendi nos documentos, a única forma de comunicação com a biblioteca é por meio de eventos, as promessas estão obsoletas agora.
Talvez eu não tenha entendido algo corretamente, mas do meu ponto de vista, a biblioteca não deve rejeitar promessas ao enviar eventos de erro.
@hyochan Alguma outra ideia? Estou pronto para contribuir, só quero entender que estou caminhando na direção certa.
@gaykov Você está certo. Parece que isso é um efeito colateral em um esforço para apoiar event
e promises
. Esperando melhorias com o seu PR
🔨
Olá, parece que não houve nenhuma atividade sobre este problema recentemente. O problema foi corrigido ou ainda requer a atenção da comunidade? Este problema pode ser resolvido se nenhuma outra atividade ocorrer. Você também pode rotular esse problema como "Para discussão" ou "Bom primeiro problema" e eu o deixarei em aberto. Obrigado por suas contribuições.
Fechar este problema após um período prolongado de inatividade. Se esse problema ainda estiver presente na versão mais recente, sinta-se à vontade para criar um novo problema com informações atualizadas.
Comentários muito úteis
Pelo que entendi, acontece devido a esta linha: https://github.com/dooboolab/react-native-iap/blob/8d28d204857d65d99d764aa2a59f9bca1385859a/android/src/main/java/com/dooboolab/RNIap/ Theyava# apModule.java usado em alguns outros lugares também.
Não consigo entender por que essas funções estão sendo chamadas depois que o evento de erro foi disparado. Parece que há uma combinação de 2 abordagens usadas aqui.
A nova promessa está sendo criada em cada inicialização e então é resolvida ou rejeitada dependendo dos resultados da operação junto com o envio de eventos via
DeviceEventManagerModule
.Mas, como entendi nos documentos, a única forma de comunicação com a biblioteca é por meio de eventos, as promessas estão obsoletas agora.
Talvez eu não tenha entendido algo corretamente, mas do meu ponto de vista, a biblioteca não deve rejeitar promessas ao enviar eventos de erro.
@hyochan Alguma outra ideia? Estou pronto para contribuir, só quero entender que estou caminhando na direção certa.