Closed BuzzPaul closed 4 years ago
For anyone else who ends up here like me: the problem most likely is not the plugin. You're probably just not handling the event listener properly. In my case it was a race condition where the user had to be logged in to be able to share content from another app but the request to our API to check their login status hadn't returned yet when the intent event listener was triggered!
Apologies for not clarifying this sooner. For us, this was an order of events issue caused by routing in Angular. We simply hadn't allowed for the use case of sharing when the authentication state was unknown (eg. during a cold start), meaning that authentication related navigation events occurred that prevented the correct share UI from showing. This was obfuscated by the fact that Android worked correctly due to it using a different routing method.
On iOS, we've found the ShareExtension works correctly when the app has been previously opened and is in a backgrounded state. However, if we share and the app isn't running, the app opens but the openwith handler isn't triggered (presumably because the handler hasn't been registered yet).
I'm trying to determine if this is a problem with our use of the plugin, if there's an issue with the plugin or if it's simply the expected behaviour.
Is anybody able to confirm this behaviour please?