Hi, thanks for this awesome plugin!
I noticed the following weird behaviour on iOS 9.0.2 and version 1.3.0 of this plugin (i'm not sure if this happens on earlier versions of iOS as well). Also it only happens about 50% of the time.
Steps to reproduce:
Result (about 50% of the time):
When the user chooses to reject notifications, of course messages won't arrive. When he later turns them on in the settings app, they will arrive with the previous obtained token.
The problem is that my app cannot reliably know if registration was successful or not, since It is possible a token is registered and a moment later the user chooses not to allow notifications... Also, it is undesirable that the registration event is called twice when the user accepts them.
@alexbuijs it was fixed by PR #215 which is in master and will be part of the 1.4.0 release I hope to get out this week.
I missed that. Great, thanks!
I tested again with the master branch. Unfortunately, the original problem is not solved. It did solve the re-registering problem! But the fact that the plugin some (most) of the time registers before waiting for the result of the system popup, is still a problem, imo.
@macdonst can you confirm this is still an issue and reopen it?
@alexbuijs are you using PhoneGap Build? If so please comment on issue #201
@macdonst No, I'm using plain cordova, most recent version. Actually, what this issue was about, is described here: http://stackoverflow.com/questions/11045406/apple-push-notification-registration-device-token-receive-clarification. So didRegisterForRemoteNotificationsWithDeviceToken is called with a token, whether the user allows notifications or not. I reckon there is not much you can do about this. My workaround is calling init at different points in time. Because when a user disallows notifications, the registration event will not be called a second time, when calling init again. (Which can be registered with a timeout).