hope you all fine
My problem is somecompany made an application for me for android and ios
and now I want to transfer these apps to my accounts
the problem is these accounts have GCM. so I want to keep these IDs
they told me that they will give me the GCM IDs database
and I have to make a script to handle the send of notification
But I know that when you register a new device with gcm you have to pass the
project ID.. that you made on your google account
and I have a different project ID than they have.
so the register of any device will vary ..
the new devices will work without any problem
but my problem is with the old devices!!
when I send a notification with the Device ID and the access token
the token is for another project ID that this Device ID generated to !!
so I think it will fail and not send any notification for old clients ..
its true ???
if its true please may you give me the correct way to transfer the app with GCM project or clients
thank you.
Is GCM the only way for push notifications in android? And is it advisable over other methods (if there are any)?
So let's say my app from a device registers on GCM. Is it the app itself which is assosciated with the device that registers itself, or the user and his email id that register? If my user switches devices in future, will the same 'registration token' work for him ? Or in a similar scenario if a user with another g-mail id registers to my app from the same device, do i push notifications to the same device with 2 different registration tokens?
Extending to what i asked in 2, suppose a single user has his g-mail id working on my app on different devices. Does GCM push the notification to all those devices, or only one of them? And if one, then how does it prioritize?
No, there are other push notification services in Android, like Parse. However, it is strongly recommended to use the default push notification service that is present in any Android device that has Google Play Store, because that reduces battery usage. If you are pushing your app somewhere else though, like Amazon Store, keep in mind that Kindle Fire does not comply with this and doesn't have Google Play Services -- at least as far as I know.
The registration token is very volatile and is not bound at all to an email. Actually, sometimes the same device may get a new GCM ID out of the blue. There are many tutorials on GCM's best practices, but Google's is the best way to start. What you should do to prevent problems is store the GCM id of your device in your database, so you can always know which ID is currently associated to your device. GCM may give you new IDs for no reason, so always parse its response properly and store the new ID it may provide, linking it to the device.
GCM doesn't really care which Google account is your app using. That means you can register as many devices as you want with the same account. You have to manage to which devices you push notifications, because the ID is managed by device.
Be careful: there's been some changes with the API lately, so a lot of unnoficial tutorials you find on the internet may point to deprecated methods.
There are other ways of sending notifications, Tokodu and RabbitMQ for example. I wont go over if X is better than Y, since it's not allowed on StackOverflow.
A unique device token is generated for the device, how you use this device token is totally up to you. You can make it unique for the user by, for example, implementing a login system, so that the device token is created and stored in a database (together with the user information). Let's say if two different users uses your application on a shared device, they can both receive notifications on the same device if you allow them to. It depends on your own implementation.
This again depends on how you chose to implement the GCM features on your client and server side. For example, you can choose to store device tokens for each and every device the user has installed the app on, or you can store the latest device token so that notifications are only sent to one of the user's devices.
I hope this helps clear some things up.
Besides good answers above, if you need a push notification solution for a working environment without Internet access, I suggest SignalR of Microsoft, which has already supported Android and Java (you can find out more at GitHub).
Hope this helps little!
While building my first Android app (a simple game), I came across this (most probably newbie) problem:
my app needs to send a message to a contact (chosen from contact list) via my own server.
same app installed on this contact's device, needs to retrieve this message.
The problem I am facing is contact "identification". How can the app identify a contact such that one device sends a message for this "ID", and another device polls for messages intended the same "ID?
Maybe there is some kind of ID associated with a contact having an Android device?
Thanks (and sorry for newbie question :)
You can try push notifications service, by using the google cloud messaging.
From the first device you can send an http request containing message to a server that manages the request and sends message to the second device, or to more than one device.
You can find a tutorial here
https://developers.google.com/cloud-messaging/
If you have one phone and need to use Google Cloud Messaging, what would you use as client nbr 2? Chrome seems awkward, the simulator is terribly slow. Can you use a Python script as gcm client? I didnt quite understand how to use gcm-client, if it could receive push notifications or not. Can it?
Only an Android application can serve as GCM client. So if you only have one phone, you'll have to use the simulator.
Another (awkward) solution you might try is to install two instances of your application on the same phone. That would require to have two builds of your app with different package names (so that your device will treat them as different applications). Each will register to GCM and get its own registration ID. Then each app can send GCM messages to the other.
I have an application setup where both Android and IOS devices are configured with UA libraries. The issue I'm having is in understanding the purpose of some of these steps or if I am duplicating work. I'll explain the process I have setup first.
On application start-up the devices seem to be registering with UA successfully.
The devices then post their apid's and information to my own service (on a different server).
My server stores the device id information and everything required for push.
For every push enable device that comes in, my server performs a subscribe call to UA. "/api/device_tokens/" for IOS and "/api/apids" for Android.
This server is designed so that when it wants to send push notifications, it queries the list of device id's and tokens it has and sends this information to UA's push api service. "/api/push/" etc...
There is a step which is confusing me however.
What is the difference between step 1 and step 4. Am I basically registering the device tokens and information twice? Once from the devices and once from my own server?
In short, what is the difference between the registration that the Devices perform (as per their relevant libraries) and the registration from my server to UA's api "/api/device_tokens"
Also, where does this come into play:
https://docs.urbanairship.com/display/DOCS/Server%3A+Subscription+API
The term "subscriptions" in the UA system refers to recurring content subscriptions, such as with a magazine-type app. Whereas "registration" is a device registation in the system. The apps do register themselves with the UA servers every time the app is started up (more-or-less). There is generally not a need to re-register the devices before every push, however it should not be harmful to do so. If you are maintaining a list of device ids on your servers, you should be using the Feedback API regularly to prune your list. This will return a list of "deactivated" device ids, so you are not storing unaddressable device ids in your system.
You do not need to worry about the Subscriptions API unless your app is selling subscriptions.