You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 7, 2019. It is now read-only.
In the README.md and in the demo app, it first calls pushPlugin.register() then calls pushPlugin.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.
self.updateMessage("Successfully registered for interactive push.");
},(err)=>{
self.updateMessage("Error registering for interactive push: "+JSON.stringify(err));
});
}
},(errorMessage: String)=>{
self.updateMessage(JSON.stringify(errorMessage));
});
}
Apple Sample Code:
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
// Configure the user interactions first.
self.configureUserInteractions()
// Register with APNs
UIApplication.shared.registerForRemoteNotifications()
}
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.
The text was updated successfully, but these errors were encountered:
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.
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.push-plugin/demo/app/main-view-model.ts
Lines 53 to 70 in a096afc
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.
The text was updated successfully, but these errors were encountered: