Google Cloud Messaging - Registration ID status

Question

I am using the new GCM APIs in order to register. The documentation of the method clearly states:

Register the application for GCM and return the registration ID. You must call this once, when your application is installed, and send the returned registration ID to the server.

Repeated calls to this method will return the original registration ID.

However, while reading this article (http://developer.android.com/google/gcm/adv.html#reg-state), it states that there are two cases that need special treat:

There are also two other scenarios that require special care:

• Application update
• Backup and restore

When an application is updated, it should invalidate its existing registration ID, as it is not guaranteed to work with the new version.

So, it not clear when the developer should invalidate or not the registration ID.

Moreover, regarding the unregister phase the new GCM API states:

Unregister the application. Calling unregister() stops any messages from the server. This is a blocking call—you shouldn't call it from the UI thread. You should rarely (if ever) need to call this method. Not only is it expensive in terms of resources, but it invalidates your registration ID, which you should never change unnecessarily. A better approach is to simply have your server stop sending messages. Only use unregister if you want to change your sender ID.

However the previous same article states:

Whenever the application registers as described in Implementing GCM Client, it should save the registration ID for future use, pass it to the 3rd-party server to complete the registration, and keep track of whether the server completed the registration. If the server fails to complete the registration, it should try again or unregister from GCM.

This is also not clear (i.e. how to handle unregistration).

Finally, based on the above, it is not clear how Canonical IDs are related to the mobile. In case Google produce a Canonical ID for an existing registration and pass it back to the application backend, it will also change the registration ID of the mobile if it calls the register method? Is there any other way for the mobile to get informed about this new ID?

Thank you very much in advance!

Answer 1

Google suggest that your app should invalidate the registration ID when the app is launched after a new version is installed. Their GCM demo app implements this suggestion. Other than this case, there is no need to call the register method more than once (when the app is first launched).

As for unregistering - they suggest to unregister if your wish to change your sender ID, or if the registration in your own server failed. The reason for the latter is that if your server never got the registration ID from your app, it will never use that registration ID, and therefore there is no reason for the app to be registered to GCM (unless your app is going to retry later to send the registration ID to your server).

As for canonical registration ID, the only way I know how to cause a canonical registration ID to be returned to my server is by unregistering the app from GCM (to invalidate the old registration ID) and then re-registering to get a new registration ID. In that scenario, if the server used the old registration ID, it will work, but the new registration ID will be returned as canonical registration ID. That's one of the main reasons for the suggestion not to unregister unnecessarily (to avoid generating multiple registration IDs for the same app on the same device).

Since the new registration ID is created as a result of actions you take in the client side (i.e. unregister + register), your app should already be aware of the new registration ID (yes, register will return the latest registration ID, which is identical to the canonical registration ID), and your server should be notified of it and avoid sending messages with the old registration ID in the first place. Getting the canonical registration ID in the response from Google only covers the case in which your client failed to pass the new registration ID to your server (or your server failed to remove the old registration ID). Therefore the is no need to inform the client of the new registration ID.

You can read more here about handling registration ID changes and here about canonical registration ID.