Develop Reference

Android Gcm Unregister Users Subscribed To A Topic When App Uninstalled

Scenario: I have a 3rd-party app server, a gcm http connection server, and an android app setup for push notifications. When the user uninstalls the app, I can delete them from my 3rd-party server by sending their (no-longer-valid) registration id a push notification and handling the "NotRegistered" error returned from the gcm connection server.
However, this similar approach does not seem to work when you send a push notification to users subscribed to a "Topic", as here the gcm connection server only returns a json object with the "message_id".
The notable columns in my 3rd-party server database table are as follows:
| gcmRegistrationID (string) | subscribedToNotificationTopic (boolean) |
Does anyone know how to identify a user that has previously set true in the subscribedToNotificationTopic column, then uninstalled the app?
I have an idea on how to resolve this, but it seems somewhat messy.
Every so often, instead of only sending push notifications to a topic e.g.
{
"to" : "/topics/global",
...
}
send a push notification to the registration ids of the users subscribed to the topic e.g.
{
"registration_ids" : {list of registration ids},
...
}
such that I can retrieve and handle any "NotRegistered" errors.
The problem with this however, is that multicast messaging has a limit of 1000 users so I'd have to send a message for each thousand.
This seems like bad practice (especially if there is more than one topic involved), but maybe it's the only way?
(Extra tags: topic messaging, pubsub, unregister, google cloud messaging)

First off, I am not sure it is correct to assume that an "NotRegistered" error can only be the result of the user uninstalling your app. It seems like the device can become unregistered if the device receives a message but that message can not be delivered. This can happen if the user stops the app (which is different from uninstalling it, or even if the app was killed and remains stopped due to a power saving mode.
https://developers.google.com/cloud-messaging/ccs#response
If it is NotRegistered, you should remove the registration ID from
your server database because the application was uninstalled from the
device, or the client app isn't configured to receive messages.
What you can do is from the device side, periodically register the device, and make sure that the token you get back is the same as the one you stored, if not update your server with the new token.
As far as detecting if a user has uninstalled your app via a response to a topic message, I agree with you it does not seem to be directly possible. As an alternative to your proposed solution, you might, every now and then include a flag in the topic message that would ask the device to validate itself with your server, if a device does not validate itself after some number of attempts or some period of time you might conclude the user is not longer listening.
The other question is why do you really need to know. Is there any harm in sending some extra regid's to google? If a user quits your web service you can remove them from the list, but do you really need to take action if they just un-install your app from there device? - Just some thing to consider. Hope this helps.

GCM: Send notifications only for the current user logged in application

For the application that I am working I need to integrate Google Cloud Messaging. After playing a little with different examples, I was able to send and receive a notification on my deivce.
However, I have come across an interesting situation. As I know (please correct me if I'm wrong), the registration_id is issued per device and per application.
The application that I'm working supports login functionality. When the application is installed and the user logs in for the first time (let it be "UserA"), I request the registration_id from GCM which then I send it to my server.
Now imagine that UserA logs out and gives his device to some UserB to log in. With other words, UserB logs in using UserA's device.
The problem is that if meanwhile UserA receives a notification, UserB will be able to intercept it. And if UserB receives a notification, he won't be able to receive it.
This seems normal because the registration_id is per device and per application, but it does not seem reasonable for my case.
So I'm asking if there is a way I could make the registration_id to be dependent of some user id (besides the device and app)? Or how could I make such that the logged in user to receive only his own notifications?

Yes its true that you have one google registration ID for the app per device.
But you can always register and unregister users at your own Server that will actually send messages to GCM and GCM will send this to the registered devices.
Define some interfaces for your Server like registerOnServer and unRegisteronServer , send some unique value for each user on this interface.
So, in your case, when A use Log ins , regitration is done on GCM first and register the user on your Server with registerOnServer inteface and while the user is logged in send notifications pertaining to him to GCM to be send to the device.
When A logs out, unregister him using unRegisterServer and do not send any messages from your Server to GCM as A is unregistered.
So,now if B Logs in even with the same device , register him at your Server and send his messages.
This shall solve your problem!

Android: C2DM Changing registration_id without notification?

So I have a situation which I didn't think would happen based on my understanding of the registration My understanding:
Phone Registers with google gets registration_id, send registration_id to the server, use registration_id when sending out push notifications. If registration_id is updated by google, they will send a new registration broadcast.
However, I have case where a phone was registered, and was successfully receiving push notifications, but than one day the server goes to send a push notification to the phone and I get a error "NotRegistered" which would suggest the registration_id refreshed but did not get propagated through the system properly, whether it be on the phone side or the server side.
My question is has anyone else hand issues like this? What is the best approach to making sure this doesn't happen?

From the Android Cloud to Device Messaging Framework documentation:
Note that Google may periodically refresh the registration ID, so you should design your application with the understanding that the REGISTRATION Intent may be called multiple times. Your application needs to be able to respond accordingly.

Why do I get multiple active Tokens for my Device with Googles Cloud To Device Messaging Service?

I just added C2DM capability to my Android App.
At the moment the following happens if C2DM is started in my App.
My App sends the registration Intent
The answer broadcast is received by my app
The device token is retrieved from the intent and sent to my server
From that moment everything is working fine. The client receives the push notifications etc.
A problem occurs if the following hapens:
The user uninstalls the application without disabling push. (Completely deleting it not only updating)
The user reinstalls the application
If after step 5 a push notification is sent my app still receives this notification.
It seems that the token which was retrieved from the previous install is still active and is reconnected to the new instance of my application.
This leeds to the following problem:
A user who reinstalls my app but has no intention of receiving push notifications has no possibility to remove himself from the service because the new instance of the app has no way to unregister the old token from my server.
Is this a bug in the C2DM system or is something wrong in my setup?
Update
I followed Berdons advice and did the following:
For testing purposes only start an unregister Intent every time my app starts up.
After I send the unregister intent no push notification from my server is sent to my application. That seems to do the trick, but if I now go the C2DM Settings Screen and turn on push notifications for my app all the old tokens get active again and I receive information that I did not register for in the current installation of my app.
Next Update
It seems I'm not the only one with this problem:
Android C2DM : Duplicate message to the same device and App
I hoped that Google would manage those tokens in a way that old tokens from the same device get disabled after a new one was issued. I also expect that after I sent an unregister Intent all tokens for that application and that device are marked as invalid or deleted from the Google Server for ever. If this is somehow a design decision by Google for special use cases I don't see please enlighten me.

We now found a solution that should work in most of the cases.
The server adds the C2DM registration id as a data field with every C2D Message.
The device now only shows a notification if the token in the message and the token that is stored in a pref file match. That way we guarantee that we don't show messages for device tokens that were obtained by previous installs.
If the tokens do not match we found an old token that should not be active anymore. We now mark the token on our own web server as inactive to prevent the server from sending more unnecessary C2D Messages
This solution enables us to show only relevant data without the need to store a unique user id.

In my C2DM implementation, each user's device token is saved in a database against their UDID and the package name of the app (among other things). The UDID and package name form the primary key, meaning that the table can list multiple apps from the same device (UDID). When a user runs a particular app, the device token is recorded, and if they uninstall and re-run the app, the new device token would be recorded over the old one. We also have columns to record whether push is active for that particular app/device combo, and which types of push messages the user has enabled/disabled.
When the time comes to send a push for a particular app, no UDID will be registered more than once (since these two fields form the primary key), and therefore only the latest device token will be used. Furthermore, our query only returns the rows that have push messages enabled.
This solution should solve your problem because it prevents you from sending the push to both device tokens. I hope this helps!

More like an unexpected "feature". You might consider issuing an unregister request on the "first run" (first run ever) of your application to prevent this from occuring.
Update
You could could do the work of differentiating between different C2DM messages by using the collapse_key (or anything of your own creation) as an identifier. Update it between registrations and pass it to the device following registrations, unregistrations and messages.

Best practices implementing C2DM registration

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.