I recently migrated an old push notification app to a new Azure Mobile Service. The MPNS API, apparently, has changed. It also automatically created a notification hub. Now instead of being able to define a clear channel URI for the message to be sent to, I need to specify a tag. I find it very hard to find information on this and how to send messages to individual users from Azure Mobile Services.
How is this done now?
Its actually pretty simple. Use your unique user identifier as a tag when you register.
Here is an example.
Registration reg = new AppleRegistration(token)
reg.getTags().add(userId)
hub.createRegistration(reg)
Now when you want to send to that user, send via the tag.
hub.sendNotification(Notification.createAppleNotification(payload), userId)
With Notification Hubs you have a few different options. Tags are the way of identifying who you want to push to (i.e. when you push to tag X, any device that has registered with tag X will be pushed to). So if you want to push based off of channel URI, when you register from the device, you should use the Channel URI as one of the tags. If you want to be able to push to all of a single user's devices, you'd need a different mechanism of knowing who the user is (i.e. registering with the username as a tag and then pushing to the username).
Related
I want to send web push notifications to registered users, are there any best practices on how to implement the cases when multiple users have access to the same device and one should not see the message of another user.
Thanks in advance.
A web push notification subscription is tied to the browser, not the device.
What you need to do is, map this id with your registered user when he logs in from a particular browser. Also, you need to remove the subscription id mapping with any other users in the system.
In the case of multiple users using the same browser, the above logic will make sure that at a time, a particular browser subscription id is linked only to a single user.
And when you want to send a notification to a registered user, you can retrieve all push subscription IDs linked to this user in your database, and trigger notifications to those subscription IDs.
And don't forget to unmap a subscription id when the user logs out from a browser. Otherwise, he will continue to receive all notifications even if he has logged out.
I need to implement push notification system which allows to send push to specific users every time.
the registration to the hub is supported by device token and set of tags.
Is the right way to do what I want is to register each user with a singleton set of tags with their user ID as the only tag?
and then when I'd like to send push notifications to users a,b,c for example I will need to attach their users Id's.
Is there any way more elegant to do so or those tags are the only way?
BTW I am limited to attach 20 tags foreach push Im sending so I wont be able to push to more then 20 specific users at once.
Please let me know what you think about this solution.
#Liran Revivo well i think, yes this is the right way to do push notification over azure.
As my experience with azure push notification
step 1: i made a notificationHub for my azure notification and registered my GCM api key with that hub
step 2: i did register device token with or without the tag as you want.
step 3: send push notification
i sent push with different case like:
(i) sends a push to single device: i just sent with that particular device token registration id
(ii) sends a push for a group of device: So i mentioned tag name and sent the push
(iii) sends a push for multiple group: So i mentioned multiple tag name and sent the push
(iv) sends a push to all devices: So i send tag name empty and by deafult it sent to all device with that notificationHub
By doing all these above stuff, i did my push notification with azure, And i think this is the right way to push with azure as it is documented by its offical site
From my experience - using user ID as a TAG works quite well. It allows you to send push for specific user. If you want to notify all users at once, you can send push notification without specific tag, then it would work as a broadcast message. On the other hand if you want to divide users to some subgroups you can provide them some "channels" using specific tags.
For example
"premium_user" tag that every premium user registers.
I want to enable push notifications for a UWP mobile app connected to Azure app service with Azure SQL database. The notifications will alert only the users that are located within x kilometres from a certain geo coordinate.
However I'm not clear about how to track the users, My questions are as follows,
In my database should I store every user that uses the app and update their location periodically? I'm guessing I would need to do this in order to calculate which ones are in range and send notification to only those. However this leads me to my next question,
If I was going to store a record for each user in my database, what identifier is used for them? How are users identified on each device? Do they need to log in with an authorization provider like Facebook, Twitter, etc. in order for my app to record a unique identifier? Or is there a different mechanism to create or get a unique identifier?
#DaveSmits is on the right direction. You could register a GeofenceBackgroundtask to report user's location to your azure service. Besides current location, you also need to report current device channel Uri to your zaure device.
I believe you're familiar with WNS. If not, please check that document, it will explain what the channel Uri for you.
Then in your azure service, you need to save the location and channel Uri in some database tables. You would need to caculate the distance from a certain geo coordinate. If it meets the requirement, you can get all qualified channel Uris.(e.g. select channelUri from yourtable where location='xxxxx')
After you get all channel Uris, you could use it to send notifications to the specific users. About how to send notification, please check the WNS document.
I've answered a similar question on MSDN, it also needs to send notifications to the specific users.
there is nothing to track the location of the user in the push notifications. There are two things you can do:
solution 1:
- use a geofence that triggers a background task. If entering a geofence register for push notifications. If leaving the geofence unsubscribe again in your backend.
solution 2:
- Only send raw notifications and use a background task to handle them. In the background task evaulate the current location and if in the right location trigger the notification from code.
I would like to use Azure Notification Hubs to send push notifications to users of my app running across iOS, Android and Windows Phone.
I have managed to get the basics working but I don't know how to manage the App uninstall story.
On starting, the mobile app will call my Identity Svc to get an Auth Token.
It then calls its Platform Notification service (eg Google Cloud Messaging, APNS) to get a PNS Token.
After persisting the token to local storage it will call a back-end Contact Svc to register the customer's device. This service will create a subscription to the Azure Notification hub for the device.
This is illustrated in the following diagram:
Later on a back-end publishing service will call the Contact Service requesting a push notification for a particular user id. The contact service will lookup the Id allocated to a tag on the notification hub and send a push request.
What options are available to determine when a customer uninstalls the app? Is it just a matter of trapping errors when calling "Send" on the notification hub? I guess this could work if only sending to a single user but my intention is that certain message types are to be published to multiple subscribers. On the initial registration of a device a subscription will be created for a tag of the user id but also for a more general tag such as "New Promotion". The publishing service would later want to issue a "New Promotion" notification to all devices.
Why do you need to know app uninstalls?
Notification Hubs automatically expire registrations for devices that get uninstalled.
Also, I would avoid persisting the PNSHandles in your service at all.
The current guidelines for using hubs are the following:
store the registrationIds of the registrations associated with the device in local storage. This enables you to update tags and channel information with a single update call.
Because mobile connections are not always reliable, it is best to avoid creating a new registration without being able to store the registrationId in local storage. This can result in the device registering multiple times, causing duplicate notifications. You can achieve this by using the Create Registration ID and Create or Update Registration REST APIs.
The first API returns a registrationId without actually creating a registration. When the ID has been securely stored on the device storage, the device can call the Create or Update Registration API.
So I would have your ContactSvc expose two functionalities:
a) create registration id (just call hub to get it)
b) create or update registration given (registrationId, pnsHandle, tags?)
Then your device keeps the regId in its storage, ad after getting the handle from PNS, if as regId is not there creates a new one with endpoint a), then updates the registration with pnsHandle and tags.
Note that in this way your service does not need to persist handles or UUIDs, and does not need to worry about app uninstalls.
If you are keeping track of users, one approach is to periodically (once a month?) check in your hub if its registrations are still there...
You can reach me at #eliodamaggio if this is not clear.
I am evaluating which Push Notification service to use out of Azure Mobile Services, Parse and Urban Airship.
One of the criteria is whether the service provides a way for the app to register a bespoke user Id or alias that can then easily be used when calling the service to send a push notification to an individual. This removes the need for our backend service to have a lookup table giving us the service registration ID for a given user.
Urban Airship has the alias feature: http://docs.urbanairship.com/connect/connect_audience.html#aliases
Parse has a sophisticated Installation object which behaves like a dictionary so that additional values can be added to it (like UserId). When the Parse service is called to send a Push Notification a query can be used to specify the user that will receive the message:
https://www.parse.com/docs/push_guide#sending-queries/REST
Is there an equivalent feature in Azure Mobile Services?
With Mobile Services, you would need to keep track of a user to token / channel URI / registration ID association in a table which is more work than you NEED to do. However, another feature of Windows Azure is Notification Hubs which does what you want (and much more). With Notification Hubs, from the client you say "I want to register for Notification Hubs, here are some tags you can use to push me information". Those tags can be anything you want including a User ID. Later on you can tell your Notification Hub to push to anyone registered with a certain tag. That would allow you to then push notifications out to any devices a specific user has registered.
The flow would look something like this:
Register with Push Provider (APNS, GCM, MPNS, WNS)
Send token to Notification Hubs along with tags (such as the User's ID)
Trigger a push to a specific Tag (i.e. User ID)
Notification Hubs will handle delivering a push to all devices with a Tag (again, their user ID)
Notification Hubs has client SDKs for WinPhone, WinStore, iOS, and Android so it's very easy to use from the client side. As far as triggering pushes goes, Notification Hubs exposes a REST API you can communicate with, there is a .NET SDK, a Node SDK, as well as an unofficial Java SDK. You can even use the Node SDK from Mobile Services which makes it super easy to combine authentication (i.e. getting User IDs) with data storage and push notifications. It also has lots of other features like templated push notifications so instead of specifying a different payload depending on what the device OS you're pushing to is, you can have the client application indicate how it should receive a certain type of push.