In order to get an updated registration ID once a user upgrades their android version, do I need to first unregister the original registration ID by calling unRegister before I get the new registration ID?
You don't have to un-register before registering again to GCM, unless you are changing the sender ID (project number) used to register. In fact, the registration ID may even stay the same if you register with the same sender ID.
You don't have to do that and if you do the registration ID will remain the same.
If you want to have a completely new and different registration-id you need to register with another project-id.
Also, if you change your package name for your project, the registration-id would change too.
Updating registration ID is not required if Android device get updated with newer Android version e.g. JellyBean to KitKat.
You have to update registration ID if your application is updated. In that case you don't have to un-register at all, just register again and clear stored previous ID in the local storage.
Android Developer page has well written chapter about GCM Advanced Topics. You should be interested in Unregistration and Keeping the Registration State in Sync
#Eran is absolutely right.Upgrading your android version won't change gcm registration id.However sometimes may be because of some bug in your app or uninstalling(and again reinstalling the app) gcm may change your registration id.But thankfully gcm provides the concept of canonical ids.So i don't think you will need to unregister your device from gcm for this case but you need to deal with the canonical id properly if it occurs.
Please refer here and have a read about canonical ids
Canonical IDs
On the server side, as long as the application is behaving well, everything should work normally. However, if a bug in the application triggers multiple registrations for the same device, it can be hard to reconcile state and you might end up with duplicate messages.
GCM provides a facility called "canonical registration IDs" to easily recover from these situations. A canonical registration ID is defined to be the ID of the last registration requested by your application. This is the ID that the server should use when sending messages to the device.
If later on you try to send a message using a different registration ID, GCM will process the request as usual, but it will include the canonical registration ID in the registration_id field of the response. Make sure to replace the registration ID stored in your server with this canonical ID, as eventually the ID you're using will stop working.
Related
I am doing an android application which uses gcm.I came to know that when the application is uninstalled and re installed there is no guarantee to receive the same registration id again.So what I did is while logging in I take one unique Id from application server and whenever new registration id is made I am able to replace that in application server.So what my question is, I am not using the canonical id for replacing the latest registration id in gcm server.Will it cause any problem? Please help me.
Your solution is basically good, though I'm not sure whether that unique Id your server generates is associated with the device or the logged in user. If it's the former, make sure you persist it on the device's external storage, so that it doesn't get lost when the app is uninstalled. If it's the latter, I'm not sure how you are handling the case of the same user logging in on multiple devices.
While your strategy is good for maintaining the current registration ID on both the device and your server, you should still handle canonical registration ID responses from Google just to be safe.
On the server side, as long as the application is behaving well,
everything should work normally. However, if a bug in the application
triggers multiple registrations for the same device, it can be hard to
reconcile state and you might end up with duplicate messages.
GCM provides a facility called "canonical registration IDs" to easily
recover from these situations. A canonical registration ID is defined
to be the ID of the last registration requested by your application.
This is the ID that the server should use when sending messages to the
device.
If later on you try to send a message using a different registration
ID, GCM will process the request as usual, but it will include the
canonical registration ID in the registration_id field of the
response. Make sure to replace the registration ID stored in your
server with this canonical ID, as eventually the ID you're using will
stop working.
Source : http://developer.android.com/google/gcm/adv.html#canonical
I am working on an android project which uses gcm. I came to know that if we uninstall the appfrom device and reinstalled most of the time the device gets new registration id.Then if we do not delete the old one from application server and update, The messages will be sending to both ids and in the response it will be showing canonical id is present.My question is, at this point message will be successfully send to that device or not?
When you receive a canonical registration ID in the response from Google, the message was accepted by the GCM server and the GCM server would attempt to deliver it to the device. Whether it is actually sent to the device depends on whether the device is available (i.e. connected to the internet).
So if your server sends a GCM message to both the old ID and the new ID, the device will probably get two messages.
Canonical IDs
On the server side, as long as the application is behaving well,
everything should work normally. However, if a bug in the application
triggers multiple registrations for the same device, it can be hard to
reconcile state and you might end up with duplicate messages.
GCM provides a facility called "canonical registration IDs" to easily
recover from these situations. A canonical registration ID is defined
to be the ID of the last registration requested by your application.
This is the ID that the server should use when sending messages to the
device.
If later on you try to send a message using a different registration
ID, GCM will process the request as usual, but it will include the
canonical registration ID in the registration_id field of the
response. Make sure to replace the registration ID stored in your
server with this canonical ID, as eventually the ID you're using will
stop working.
(Source)
You can overcome this problem by assigning a unique identifier to each instance of your application. If you store that identifier in the device's external storage, it won't be deleted when the app is uninstalled. Then you can recover it when the app is installed again. If you send this identifier to your server along with the registration ID, you can check if your server has an old registration ID for this identifier, and delete it.
#Eran We have two option either to remove older registration ids or update with Key and position of canonical id. I prefer to update... You can view working code of mine i have answered here Steps to Update Canonical Ids
I am developing an app using the new Google Cloud Messaging Framework. We know that once we register our app we get a registration id. But what happens when the user unistalls the app through the device for a number of times and re installs again and again (there is no new notification sent till now). Now with many installations done google might return several new registration ids and now all the ids are saved in the app database.
If there is a notification to be sent it would be sent to all the ids previously saved also. Now my problem is that i think google is sending the notification to all the previous ids(so i get multiple notifications on the same device).
I hope i made my question clear and is there a solution to this.
You can assign a unique identifier to the app on each device. If you store that identifier on the external storage of this device, it won't be removed when the app is uninstalled. Then, when the app is installed again, you can send the registration ID along with that stored unique identifier. Your server will use the identifier to locate the old registration ID and replace it with the new one.
In addition, you should check for canonical registration IDs in the response you get from GCM. Each time to get a canonical ID, you should make sure you have that ID in your DB and remove the old ID (the one you used to send the message that got the canonical registration ID in its response).
I suggest you read the section Canonical IDs of the official documentation, as canonical IDs are specifically designed to solve your problem.
Every time you will send a message to an old registration ID Google will let you know what is the current canonical ID of the device you are sending a message to. Just make sure to replace your ID by this one.
Also make sure to check the code of the official demo here.
I have been working on GCM for my Android app for a bit. I have noticed that almost every time I have a different GCM Registration ID for my device. Is it safe for me to keep a UNIQUE_KEY constrain on GCM Registration ID? And delete all the IDs with the error NotRegistered and update all the IDs which are canonical_ids?
a registration ID is tied to a particular Android application running on a particular device.
(from GCM Overview)
Two different devices would always have a different registration id. Even different apps on the same device have different registration ids.
Functionally it is safe to keep a UNIQUE_KEY constraint on the Registration ID, but since the Registration ID can be long (up to 4096 bytes, though in practice it's usually much shorter), some databases may prevent you from defining an index or constraint on such a large column. You might want to use a one way hash function that would map the Registration ID to a smaller value, store that value in a smaller column and have the constraint/index on that column.
When you get NotRegistered error, you should indeed delete that registration ID from your DB (or at least mark it with a status that says it is inactive, and stop sending messages to it). But if the app will be re-installed on a device from which it was earlier uninstalled, the app may get the same registration ID when it registers again to GCM, so your server should allow registration IDs that at one point gave NotRegistered to become active again.
You should update the old registration ID when you get canonical registration ID in the response from Google.
It depends.
In some cases, I have proved that Two or more devices can have identical Registration IDs.
I have a push enabled phonegap app, that is made to run in several devices, all the same kind (brand, model, specs...). For saving time reasons, I decided to make a nandroid backup of one device and then copy that into the others. The result: many devices, the same Reg ID. Hope this helps.
I am also confused regarding this due to following region, But i am not getting same registration Id as i Creates two demo also.
1) But one region, There is Particular sender id for Particular Application and according to that sender id there is a unique Registration id
Check for the Bold Line.As according to this Registration id always different for different application{Copy this line from http://developer.android.com/google/gcm/gcm.html}
Registration ID An ID issued by the GCM servers to the Android application that allows it to receive messages. Once the Android application has the registration ID, it sends it to the 3rd-party application server, which uses it to identify each device that has registered to receive messages for a given Android application. In other words, a registration ID is tied to a particular Android application running on a particular device.
The registration id is unique, what happens sometimes, is that your application changes.
If you change the package name, or a whatever key used to be publish, debug or release key, then your registration id changes.
I developed an application which used GCM technology and everything is OK.
I observed that the registration ID of the device changes after a period of time and this has caused a problem in my app because my app is dependent on the Reg ID.
So how I can get a fixed Reg ID for clients?
I read the 2 reasons over here when you GCM Registration Id might change:
You’ll need to re-register every device each time you update your
app.
You’ll also need to re-register a device if the version of Android it’s running has been updated
P.S: The below old answer's reference has been removed from Google's page, so might not be valid anymore
If you see the second point under the heading Enable GCM on Architectural Overview page, it says:
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.
So, for handling that you should have a Broadcast Listener which could handle com.google.android.c2dm.intent.REGISTRATION intent, which Google send to the app when it has to refresh the registration ID. The broadcast receiver will have the onReceive method with an Intent. From the intent you can get the Bundle using which you can extract the new registration ID from Google. You can save that and send it to the 3rd part server to replace your previous registered ID for that user.
Also you may see this answer on the question In GoogleCloudMessaging API, how to handle the renewal or expiration of registration ID?.
Discussion on Should applications call gcm.register() every seven days to ensure valid registration IDs? question might also be of some use.
Hope this helps you understand how to handle it.
The 'periodical' refresh never happened, and the registration refresh is not included in the new GCM library.
The only known cause for registration ID change is the old bug of apps getting unregistered automatically if they receive a message while getting upgraded. Until this bug is fixed apps still need to call register() after upgrade, and so far the registration ID may change in this case. Calling unregister() explicitly usually changes the registration ID too.
The suggestion/workaround is to generate your own random identifier, saved as a shared preference for example. On each app upgrade you can upload the identifier and the potentially new registration ID. This may also help tracking and debugging the upgrade and registration changes on server side.