I am using Urban Airship to test push notification and it went well.
My problem is how do I specify which user to get the notification not just the device token.
I mean in some situations where one device has multiple users, so many users registered the same device token to server.
Or do I have to do the filter on the device (client side) itself?
There's no real way to do what you want unfortunately. In APNS there's only such thing as a device. You push a device and it shows a message / badge / sound on that device.
If your app can have multiple users associated with it then you'd need to work out from the push which user it relates to and handle it accordingly. How you do that would depend on your app but you could add in a custom key to the push which indicated the user it's for.
If your app only ever has one user logged in at once then I suggest that when you hand the push token to your server, the server first turns off push for the user that the token was originally registered for and subsequently turns push on for the new user.
Related
I have my app running on a Nexus 5 (Marshmallow) which has 2 active registration ids. Just want to know if that is normal by GCM behavior?
Here's how it's causing me trouble:
Android M has come up with Group permissions - which means the user chooses whether or not he wants the app to have access to his device identifiers (Android ID). Let's assume he denies it and I can't identify the device. The way my app functions is that a user can log in from multiple devices, all of which remain in sync. Because a user can be on mulitple devices, I must handle multiple registration IDs to send push messages (and I cant be sure of the number of devices the user is on, as they can deny providing the device identifiers). This means that I cant delete/update any registration ids on the server side, but only send every push message to all recorded IDs against a user, in the hope that all the devices on which that particular user is signed in will receive the messages.
Because I have a device which has two active registration IDs, I am getting 2 notifications for everything.
On the client end, we were noticing frequent changes in the Registration IDs, we have a class that keeps generating registration ids and updating the server.
Having multiple registration Ids can be a bug in the client app (which you have to deal with).
And the only way to ensure that there will only be one notification being sent per device is to implement canonical IDs on the server side. It is included in the webservice response as "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.
Here is a related issue
android GCM get original id of canonical id which tackles how canonical ids work in the actual code
I am a software developer in Xamarin - Android, I want to create notification messages. For this purpose I use Azure notification hub, combined with Google's service - Google Cloud Messaging (GCM).
My problem comes when I want to send notification to a particular user. I realized that I need to use the "TAGS" When I compose a new user to the system (Uniqe TAG)
Indeed, it works great, but when the user logged off his account, and then connect to another one (with another TAGS) - the TAGS of his old account are kept in a certain time, and he continues to receive personal messages from the previous account!!!!
Does anyone know what can be done about it?
thank you very much
This is actually an issue a lot of people/apps have on iOS and Android.
What you should do is:
Register your app at your Azure Notification Hub (ANH) on first start and reregister at every app start, to keep registration in sync
If a user logs in, update the registration with an additional tag for this user (e.g. "user:XY")
Sending notifications to that user tag will of course result in notifications on all devices the user is logged in on
If a user logs out, update the registration without the user tag (omit the user tag, so the registration doesn't have user tag anymore afterwards)
The registration will be updated immediately on ANH and sending notifications to the user (tag) will not result in notifications on that specific client
If the user can logout on your app without internet connection, you won't be able to update the registration of course and you will still have the problem of getting notifications for a logged out user. But as soon as another user logs in, the registration should get updated with the new user tag and everything should be fine again...
What you shouldn't do:
"Developers should never unregister the client app as a mechanism for logout or for switching between users..."
I have a doubt about iPhone push notifications. I need to use them when the user is using the app, but for me aren't necessary alert-sound-badge when the app is closed.
My question is: could I use these kind of notifications also if the user doesn't accept the push notifications when the app starts?
I would to use the push system to avoid any timer to get periodically info from our server when the app is running; they will be custom notifications with no alert, no badge and no sound.
Thank you
No, you can't circumvent the user's choice (the user said no, you should respect that). However, you can determine if the user opted out using
UIRemoteNotificationType types = [[UIApplication sharedApplication] enabledRemoteNotificationTypes];
if (types == UIRemoteNotificationTypeNone) {
// user does not want to get push notifications
}
No you can't. If user refuses the notifications, APNS server will not send them to the device.
And by the way, trying to get application / user info from an app without asking for user permission may lead to application rejection from the App Store.
I was wondering how to deal with UILocalNotifications that were created using my app but the app then got deleted.
Lets say that after creating a few notifications, the user decides to delete the app, but i've noticed that even though the app is deleted the notifications lived and they still fire in the correct time, but this doesn't make sense to me since the app is not existant in the phone anymore.
I understand how this is possible, but i would like to know if there a way to delete such notifications when the user decides to get rid of my app?
And does this happen as well if the app is being updated?
Thanks.
Another way is to use APNS (remote notifications) instead of local notifications.
This way, once your App was removed, pushed notifications will not get to the device anymore , nor to the user's attention.
At this stage you can be aware of the App's removal (using APNS feedback service) and cease your sending mechanism for that user (his push token..)
I am developing an application in which I want to use push notification service. I have a server, now I want to know that
How do I handle multiple devices?
Is there a unique device id/name for every iphone?
Suppose I want to delete request for a specific device token, so how do I handle multiple users?
Is there a way I can generate unique name for every device through application?
You should really read the APNS documentation, this is all explained in depth there.
The short answer is that when you launch an app on the phone it requests a push notification key from the OS. You then take that key and send it back to your server. Your server uses that key when it sends a push via Apple's servers to indicate the devices to send the push out to.
The service just gives you a token. If you want accounts or device names you need to come up with them and store them with the credentials on your server.
You handle multiple users by same way you handle single users, you send message with the appropriate key to the service.
As for deleting a request, you can't. It is like a text message, there may be some latency before hits the device, but the moment you commit the push it could be delivered instantly.