Open joeizy opened 6 years ago
We haven't noticed the Apple suggested approach and we might reconsider it. Thanks for pointing out this. In the meantime do you observe any issues that current implementation causes?
No issues observed. Seems to work great. Haven’t tested on Android but I don’t think this affect that platform. Thanks for the plug-in!
Considering the type of problem, I believe the only consequence would be that if a message arrives before the the interactions are registered, that message just wouldn’t have all the bells and whistles it normally would. I didn’t test this so don’t take my word. If my understanding is correct, it’s a super fringe case but wanted to bring it up just in case I’m wrong and it’s a big deal.
@joeizy We will be very happy if you contribute to the plugin by implementing the invocation order suggested by Apple. We encourage the community to model the plugins by providing changes so they become better and stabler.
Sure, I’ll take a stab at it. I think this change will be breaking though.
In the README.md and in the demo app, it first calls
pushPlugin.register()
then callspushPlugin.registerUserNotificationSettings()
. It seems like this is the reverse of the example in the Configuring Remote Notification Support (in the Obtaining a Device Token in iOS and tvOS section) of the Apple Docs.https://github.com/NativeScript/push-plugin/blob/a096afc8ee9a44bc13bc986183504d5c0f22c312/demo/app/main-view-model.ts#L53-L70
Apple Sample Code:
It makes sense that you would want to setup the interactions first so that you don't run into a race condition trying to configure interactions before a notification comes in.
I'm totally new to mobile dev and just happened to be reading the Apple Docs to make sure I understood how this stuff works.