[Android] Prevent crashes with null check for saved call (Fixes #368)

[kentwilliams-stripe]

cc @rdlabo @Julian-Sam

[netlify]

✅ Deploy Preview for capacitor-community-stripe ready!

Name	Link
🔨 Latest commit	475d31d
🔍 Latest deploy log	https://app.netlify.com/sites/capacitor-community-stripe/deploys/67883909760247000828eeb6
😎 Deploy Preview	https://deploy-preview-420--capacitor-community-stripe.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[yankostadinov]

this should remove the errors for "callback resolve is not a method"

[rdlabo]

Thanks for creating pull request.

Is it a Stripe Android SDK spec that onVerificationCompleted and onVerificationCancelled are called multiple times? If so, call.resolve should be removed. ( But in that case, I think you should modify the Stripe Android SDK )

If we accept this change, I will make to be deprecate the following

const result = await StripeIdentity.present();

And it should be recommended that the result be obtained only on events. But did you eventually reproduce the problem? I am at a loss to get pull requests for problems that can't reproduce.

[rdlabo]

Another idea is to provide an argument to initialize with ignoreNativeError: boolean. And maintain documentation.

For plugin users, errors are important information to distinguish between successful and unsuccessful implementations. I would not want to inadvertently respond to errors that cannot be reproduced.

[kentwilliams-stripe]

Is it a Stripe Android SDK spec that onVerificationCompleted and onVerificationCancelled are called multiple times?

No, this shouldn't be the case as far as I know.

For plugin users, errors are important information to distinguish between successful and unsuccessful implementations. I would not want to inadvertently respond to errors that cannot be reproduced.

Yes, agreed. If you aren't confident that this change makes sense, I will defer to your judgement here.

[rdlabo]

@yankostadinov 's note: The error seems to happening within the first 5 seconds (as per Crashlytics) of a user's session in our app. So it seems to be a crash happening during initialization of the plugin or when resuming an activity with the plugin, which could help with reproducing it (I haven't been able to do so myself yet).

@kentwilliams-stripe Does this still continue today? This is the most detailed information on this glitch.