My app uses gcm. Each time user logs in, new gcm token is registered and sent to my 3rd party server. Each time user logs out, gcm token is unregistered. This woks without any problems.
The problem is that when it comes to testing, tester can uninstall the app without loging out, and then install it back again and log into another account. Then he'll recieve two gcms from two different account. This means he'll recieve private gcms for account hes not currently loged into. This can even happen with live users sometimes.
GCM documentation states that gcm tokens can expire sometimes if the application is uninstalled. In practice, this never happens.
http://developer.android.com/google/gcm/gcm.html
GCM documentation also states that you can unregister GCM tokens by executing
Intent unregIntent = new Intent("com.google.android.c2dm.intent.UNREGISTER");
unregIntent.putExtra("app", PendingIntent.getBroadcast(this, 0, new Intent(), 0));
startService(unregIntent);
But this method doesn't seem to work if you try it after reinstall. I do recieve callback which tells me that token is unregistered, but gcm token still works ok.
My question is: can you ensure that there are no valid gcm tokens for your application? I'd really like to unregister all existing tokens during application first start, or at least reset them from the phone settings.
GCM tokens for your app are unique for each device, so if you ever get a different user telling you they are using the same GCM token as some other user, then you know that the situation you described has occurred. Basically, every time you receive a GCM token, you should delete all older records that have that same GCM token before assigning it ONLY to the new user.
I believe you'll receive an error when your server send a message to the invalidated registration id. I think you can catch this error to delete these registrations id from your database/datastore.
Also from the doc (canonical id):
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 want to know If I am registering my android app multiple time on gcm from same device will I get different registration id each time or the same one once registered?
Coming onto my second problem which is as below
if user1 logs out and user2 logs in the app on the same device. Now suppose a notification for user1 is sent from the server. Will the user2 get that notification or not if yes then how can it be avoided?
if user1 is logged in the app but user2 re-installs the app and logs in but server still thinks that user1 is logged in that device hence when we send the notification to user1 it will be delivered to user2. How can these be handled?
if my andriod app tries to register multiple time on gcm, will it get
different registration id or the same one?
AFAIK, this will be handled by GCM but as stated in this forum the solution would be to filter them on the client side. Your GCM notification should pass on which user it is for. Then in your onReceive method you should check who is currently logged in.
For your last question, according to the documentation - Registering:Client Apps
If a bug in the client app triggers multiple registrations for the same device, it can be hard to reconcile state and the client app might end up with duplicate messages.
Implementing canonical IDs can help you more easily recover from these situations. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.
If you try to send a message using an old registration token, GCM will process the request as usual, but it will include the canonical ID in the registration_id field of the response. Make sure to replace the registration token stored in your server with this canonical ID, as eventually the old registration token will stop working.
Here is the scenario of the problem I am facing right now. I have a web app that holds all the registration id of devices that connected to my server. On my android app. Every time the user logs in, I send request for registration id to google, forward to my server, then the server saves it and link it to the user. When a user logs out from my app. My app sends a request to the server to destroy the authentication code and registration id. The problem was, when the user uninstalls the app and a reinstall it again, his old registration id retains on my server. So when he logged in on his same phone. the app registers the new registration id to my server, when the server pushes a notification, that user would receive multiple notification depending on how many times he uninstalled the app. What is your work around on this one?
From the Official Documentation:
A client app can be automatically unregistered after it is
uninstalled. However, this process does not happen immediately. What
happens in this scenario is:
The end user uninstalls the client app.
The app server sends a message to GCM connection server.
The GCM connection server sends the message to the GCM client on the device.
The GCM client on the device receives
the message and detects that the client app has been uninstalled; the
detection details depend on the platform on which the client app is running.
The GCM client on the device informs the GCM connection server that the client app was uninstalled.
The GCM connection server marks the registration token for deletion.
The app server sends a message to GCM. The GCM returns a NotRegistered error message to the app server.
The app server should delete the registration token.
Note that it might take a while for the registration token to be completely
removed from GCM. Thus it is possible that messages sent during step 7
above get a valid message ID as a response, even though the message
will not be delivered to the client app. Eventually, the registration
token will be removed and the server will get a NotRegistered error,
without any further action being required from the app server.
Check this our: Downstream messages response codes
Unregistered Device
200 + error:NotRegistered
An existing registration token may cease to be valid in a number of scenarios, including:
If the client app unregisters with FCM.
If the client app is automatically unregistered, which can happen if
the user uninstalls the application. For example, on iOS, if the APNS
Feedback Service reported the APNS token as invalid.
If the registration token expires (for example, Google might decide
to refresh registration tokens, or the APNS token has expired for iOS
devices).
If the client app is updated but the new version is not configured to
receive messages.
For all these cases, remove this registration token from the app server and stop using it to send messages.
Refer Official document.
You have to check this on your server. You cannot do it from the application code since there is no way of knowing when the user is uninstalling the application.
when you send a push notification, GCM will check if the user has your application, if the user has uninstalled the application GCM will note the same and inform you as part of reply for the push.
EDIT - From GCM docs
How uninstalled client app unregistration works
A client app can be automatically unregistered after it is
uninstalled. However, this process does not happen immediately. What
happens in this scenario is:
The end user uninstalls the client app.
The app server sends a message to GCM connection server.
The GCM connection server sends the message to the GCM client on the device.
The GCM client on the device receives the message and detects that the client app has been uninstalled; the detection details depend on
the platform on which the client app is running.
The GCM client on the device informs the GCM connection server that the client app was uninstalled.
The GCM connection server marks the registration token for deletion.
The app server sends a message to GCM.
The GCM returns a NotRegistered error message to the app server.
The app server should delete the registration token.
Note that it might take a while for the registration token to be
completely removed from GCM. Thus it is possible that messages sent
during step 7 above get a valid message ID as a response, even though
the message will not be delivered to the client app. Eventually, the
registration token will be removed and the server will get a
NotRegistered error, without any further action being required from
the app server.
This can be done on your server side code.
While inserting requested data to your GCM table, check if your user id is already in table? if yes simply replace whole row with new data. else insert fresh new data into table.
Side-note : it is better practice to check for duplicate GCM registration id as well. because google refresh all GCM ids frequently.
Hope this will help.
EDIT
as #Haunter suggested,
what if the users have a multiple devices?
Well in this case use store IMEI number on your database and check for that instead of user id.
how to get IMEI number
TelephonyManager tel = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
String IMEI = tel.getDeviceId().toString();
Some changes on my code: (Might help someone)
I have remove IMEI to avoid issues. In order for the server to validate all users registration id to be valid, even he/she reinstalls the app. When an android device registers it new registration id on the server. After saving the new registration id,server will run a worker, starts gathering all the registration id of the current user,then send a dummy notification (empty string) on each registration id, when gcm respond with a canonical Id > 0 or an error like NotRegistered, I then delete the registration id,
This question already has answers here:
Do old GCM tokens live on even after an uninstall?
(2 answers)
Closed 7 years ago.
I'm currently trying to use GCM to send notification to user and currently I'm still studying on how I can maximize it. For now I just use the sample project provided on the documentation here and I use the gcm-client sample to work on it.
Now using this project from Git I tried to push a message using the registration ID created by the app and yes it successfully delivers the message.
Now the problem is that after I uninstalled the application. After I reinstall it it will generate a new registration ID wherein I store it on a server together with the previous one except that I can't tag the previous registration ID to not receive any further message since the uninstall might happen when user has no internet connection. After that I send a message to two registration ID's which is the ID before uninstalling the app and the ID after reinstalling the application. What happen is that I receive two push messages eventhough I expected it to only get one since the app already changes the registration ID.
I expect that the app might receive twoor more duplicate apps if ever I also updated the app since as said on documentation the registration ID might change on update.
Any workaround I can do to handle this duplicate messages?
From the official documentation:
How uninstalled client app unregistration works
A client app can be automatically unregistered after it is
uninstalled. However, this process does not happen immediately. What
happens in this scenario is:
The end user uninstalls the client app.
The app server sends a message to GCM connection server.
The GCM connection server sends the message to the GCM client on the device.
The GCM client on the device receives the message and detects that the client app has been uninstalled; the detection details depend on the platform on which the client app is running.
The GCM client on the device informs the GCM connection
server that the client app was uninstalled.
The GCM connection server
marks the registration token for deletion.
The app server sends a
message to GCM.
The GCM returns a NotRegistered error message to the
app server.
The app server should delete the registration token.
Note
that it might take a while for the registration token to be completely
removed from GCM. Thus it is possible that messages sent during step 7
above get a valid message ID as a response, even though the message
will not be delivered to the client app. Eventually, the registration
token will be removed and the server will get a NotRegistered error,
without any further action being required from the app server.
However, it can apparently happen that you still get the notification for the old registration ID, as users state in other questions:
Android GCM and multiple tokens
Unregistering and re-registering for GCM messages causes two regId's to be valid. Is this as intended?
Do old GCM tokens live on even after an uninstall?
For this problem, there is a functionality called "canonical IDs":
Canonical IDs
If a bug in the client app triggers multiple registrations for the
same device, it can be hard to reconcile state and the client app
might end up with duplicate messages.
Implementing canonical IDs can help you more easily recover from these
situations. A canonical registration ID is the registration token of
the last registration requested by the client app. This is the ID
that the server should use when sending messages to the device.
If you try to send a message using an old registration token, GCM will
process the request as usual, but it will include the canonical ID in
the registration_id field of the response. Make sure to replace the
registration token stored in your server with this canonical ID, as
eventually the old registration token will stop working.
#KaHel When client app was uninstalled regId will be valid during some time, you are right. But, when client app will be installed again and your push server try to send message on old reg id that message will be successfully sent but GCM server put cannonical_id in response. And you should correct processes this response with cannonical_id. How do this i described at this post and there is not big documentation about cannonical_id. I.e. as soon as you get cannonical_id from GCM server you should immediately replace old reg_id by new one value. It will allow you not to produce a many regIds for one client, just one to one.
After reinstal you will get new RegId and prev not valid anymore. So, even if you send push to both RegIds, only last will received it.
You can implement logic for accounts in application.
For example, when user login in application you send his GoogleId + RegId. After reinstall of application and relogin you just update RegId on server. So, you can have only one RegId for every user.
There is problem: only one device will receive push msg (if you login in 2 devices with same account). So, you can send to server GoogleId + RegId + DeviceId after start application.
I just started to use Google Cloud Messaging and read about User Notifications.
According to this link, all the devices owned by a particular user will be notified at once.
In my case, a particular user is identified by his/her user_id and the database would look like this:
[user_id] [gcm_registration_id]
As per the demo, on the application side this registration_id is stored as persistent data.
What happens if the user uninstalls the app and the persistent data is gone?
Will I get the same Registration ID for the same App on the same device once the user re-installs the app?
Will Google invalidate these Registration IDs after some time?
will I get the same registration_id for the same app on the same
device once the user reinstalls the app?
YES. Reg id chnages in two cases. Either your app will register OR Google refreshes the Registration ID. SO until any one cases executes your are fine with old reg id.
By any chance google invalidates these registration_ids after some
time?
YES. Google refreshes the registration ID. GCM gives you the idea about handleing of updated registartion ID.
Handle updated id on client side
If the registration is successful, the GCM server broadcasts a com.google.android.c2dm.intent.REGISTRATION intent which gives the Android application a registration ID.
The Android application should store this ID for later use (for instance, to check on onCreate() if it is already registered). 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.
Actually the answer you accepted is not entirely correct.
I tested the case of un-installing and re-installing an app on a device, and in some cases you could get a different registration ID.
There are two cases :
You install an app, register to GCM and get a registration ID.
You un-install app
Your server sends a few messages to that registration ID, until you get a NotRegistered error from GCM (I believe you'll get that error only from the 2nd message you send).
You re-install the app
You receive a new registration ID when app register to GCM
If you now send a message with the old registration ID, it will still work, but you'll get the new registration ID in the response as canonical registration ID.
You install an app, register to GCM and get a registration ID.
You un-install app
The server doesn't send anything to that registration ID while the app is un-installed.
You re-install the app
You receive the same registration ID when app registers to GCM
I'm developing an application that uses C2DM to receive push notifications. I've implemented the whole C2DM circuit (both client and server) and it's working fine.
Currently my applicacion has a button to bootstrap the C2DM registration, when receiving the registration id token from Google I call a webservice in my app server to associate the device with the registration id.
I'm going to implement authentication in my application and I have a few question related to the handling of the C2DM registration.
The client application (ie the Android one) will have a login screen as the first screen so the user can enter the credentials. As soon as the credentials get validated I'm planning on calling the C2DM registration so the user gets associated with a registration id token. Is this ok? In later executions of the application I will probably store the credentials or some sort of token so the user doesn't need to enter the credentials again, Should I also fire the C2DM registration when the application launches?
I'm aware that Google may eventually update the registration id. Is it a good practice to also update the registration id on a regular basis? If so, when should be appropiate? Does the registration id token expire?
What happens in the rare case of a desynchronization of the registration id between the client and the server (eg a new registration id arrives at the client, in the middle of that a new event is fired on the server with the old registration id, then the registration id arrives at the server)? Will Google handle this cases? Should my app server handle this cases?
What happens if the server is not reachable when a new registration id arrives from Google? Should I backoff and schedule an Alarm to try again?
Can you think of any other pitfalls with this?
1) I would fire the C2DM registration as soon as possible. Nothing in particular, but since the request is asynchronous, firing it up early will help me get the reg ID sooner. However, no need to fire the registration each time the app starts. Once is sufficient.
2) Whenever Google decides to update the reg ID it will send it to the device and you need to do the same steps you followed when you receive the reg id for the first time i.e. convey it to the server.
3 & 4) You may want to go through this documentation. It stresses the fact that you need to make it sure that you send the registration ID to your server and keep on trying. I assume here that if the reg ID is refreshed, and your server still has the old ID, it will not be able to send messages to the device. It will receive a 200OK with an Error Code of InvalidRegistration which means a (missing or) bad registration id.
5) Cannot comment much - would say that it depends on the design of your application. But one thing worth noting is that C2DM is still in Beta so expect things to be different in the long run.
Try to prompt the user with a choice of google accounts that are already on the phone. The http://code.google.com/p/chrometophone/source/checkout shows this. Look at SetupActivity.java for getGoogleAccounts(), etc.