In which mobile platforms the “push token” is not

2019-03-21 09:00发布

问题:

We all know that in order to use the push notifications functionality in any mobile platform we need a unique identifier called "push token".

The developer needs somehow to save this "token" to his server in order to be able to send notifications to the user.

However in which mobile platforms this "token" will remain permanent and in which it may change?

In other words , in which cases the developer must take care of updating the users "token" in the database if ever change?

Answers should include : iOS , android , WP , BB platforms.

* If you know at least one answer of these platforms post your answer and in the end i ll sum up all the answers to have a complete answer.*

回答1:

The Token is never permanent.

In iOS, the Device Token is the same for all the applications on the device. In practice, it stays the same until you upgrade your iOS version or restore your device from a backup. In theory Apple say it may change anytime, so you should handle this case.

By requesting the device token and passing it to the provider every time your application launches, you help to ensure that the provider has the current token for the device. If a user restores a backup to a device or computer other than the one that the backup was created for (for example, the user migrates data to a new device or computer), he or she must launch the application at least once for it to receive notifications again. If the user restores backup data to a new device or computer, or reinstalls the operating system, the device token changes. Moreover, never cache a device token and give that to your provider; always get the token from the system whenever you need it. If your application has previously registered, calling registerForRemoteNotificationTypes: results in the operating system passing the device token to the delegate immediately without incurring additional overhead.

In Android, the Registration ID is different for each application on the same device. It sometimes changes when you un-register your app from GCM and then re-register it. However, the old Registration ID often works for sending GCM messages to the app (you would get a canonical registration ID in the response in this case, asking you to use the newest Registration ID). That said, Google also claim the registration ID may change any time, so you should handle this case.

Note that Google may periodically refresh the registration ID, so you should design your Android application with the understanding that the com.google.android.c2dm.intent.REGISTRATION intent may be called multiple times. Your Android application needs to be able to respond accordingly.

The registration ID lasts until the Android application explicitly unregisters itself, or until Google refreshes the registration ID for your Android application.

In Windows Phone, I'm not sure how often does the Notification Channel URI changes in practice, but Microsoft also claim it may change anytime.

All apps should register for the ChannelUriUpdated event in case the push notification URI changes. Even if you already have a channel opened, you should register for the ChannelUriUpdated event in case the URI changes.

To summarize, you should always treat the Token as if it may change any time you restart your application.



回答2:

In android if you are using Google cloud messaging it will change

Note that Google may periodically refresh the registration ID, so you should design your Android application with the understanding that the com.google.android.c2dm.intent.REGISTRATION intent may be called multiple times.

A full description about GCM can be found here



回答3:

FOR IOS, as you can see here

Does the APNS device token ever change, once created?

and here

Apple Documentation ApplePushService

if the user restores backup data to a new device or reinstalls the operating system, the device token changes.

Following the EasyAPNS instructions (www.easyapns.com), every time the app starts you can check if the token is registered or not, and eventually register the device.