Now I'm using PushSharp library to send Apple push notifications (through APNS), but I want to migrate to Notification Hubs for robustness and scalability.
I'm planning to implement sending notification via Azure Notification Hubs using backend registration as described in this article. So:
There is a method of backend API that an iOS client calls when it has push token updated. In this method I do the registration tagging it with user id. (Previously, I stored push token to user link in DB.)
When I have some notification to send for a specific user I send it using the tag (user id). (Previously, I used APNS device token from DB.)
It seems like a working solution, but in Notification Hubs documentation it's said:
It is important to note that registrations are transient. Similar to the PNS handles that they contain, registrations expire. You can set the time to live for a registration on the Notification Hub, up to a maximum of 90 days. This limit means that they must be periodically refreshed, and also that they should not be the only store for important information. This automatic expiration also simplifies cleanup when your mobile application is uninstalled.
And that is the problem. Sometimes I need to send notification to devices that haven't updated the token for 90 days and so forth the registration. So the APNS token will still be active, but Notification Hub's registration will be invalidated. So I just lose the communication channel for the user.
How do you handle this?
Of course, I can still store tokens in DB and make a job that updates registrations periodically. But that's not what you expect from a push notification solution like Notification Hubs.
You can either refresh your registrations from the application or from your server. If you do it from your application, the app must be launched by the user in order for the registration to be refreshed.
Therefore, if you require that device registrations remain active even for apps that weren't launched for over 90 days, you have to refresh the registration via your server, and running a job in your server that would refresh the tokens seems like your only option.
I agree that Notification Hubs' decision to expire the tokens seems strange. Perhaps they had in mind the behavior of MPNS (Microsoft Push Notification Service) notification channels, which expire more often than APNS device tokens or GCM registration IDs.
Just a quick note, since the answer is 2 years old. In this blogpost Azure states:
It is important to note that registrations and installations by default no longer expire.
I assume that this makes the expire field confusing, but not a problem anymore.
UPDATE
Older notification hubs still have this issue. You need to update them to set the expiry to infinity, instructions are found in this forum post. New hubs are automatically set to infinity.
As per latest notification hub documentation, this 90 days limit has increased to lifetime, which means you don't need to re register device after 90 days.
Related
We are able to send push notification to apple 12.x iOS devices. But it doesn't send notification to the iOS 13 devices. We tried the suggestion of adding "apns-push-type" value to "alert" in the notification header. But it doesn't work at all. It seems microsoft doesn't know how to fix it. They just like that told the change. We have tried many ways to solve it for last 1 week. But no success.
Apple recently updated their public Push service in a way that impacts Azure Notification Hubs customers. Learn more about the impact of these changes on Azure Notification Hubs. Specifically, Apple now requires that developers identify notifications as an alert or background notifications through the new 'apns-push-type' header in the APNS API.
Azure Notification Hubs updates for iOS 13 - I understand you mentioned "We have tried many ways to solve it", If you haven't tried these already kindly try and let us know for further investigation.
According to Apple’s documentation: "The value of this header must accurately reflect the contents of your notification’s payload. If there is a mismatch, or if the header is missing on required systems, APNs may return an error, delay the delivery of the notification, or drop it altogether."
Developers must now set this header in their applications that send notifications through Azure Notification Hubs. Due to a technical limitation, customers must use token-based authentication for APNS credentials with requests that includes this attribute. If you’re using certificate-based authentication for your APNS credentials, you must switch to using token-based authentication.
To help you during this transition, when Azure Notification Hubs detects a notification that doesn’t have the apns-push-type set, the service will infer the push type from the notification request and set the value automatically. Remember, you must configure Azure Notification Hubs to use token-based authentication to set the required header; please refer to Token-based (HTTP/2) Authentication for APNS for additional information.
Another minor change, but one that requires a change to the backend application that sends notifications, is the requirement that for background notifications the apns-priority header must be set to 5. Many applications set the apns-priority header to 10 (indicating immediate delivery), or don’t set it and get the default value which is also 10. This is no longer allowed for background notifications, so you must set the value for each request as Apple will not deliver background notifications if this value is missing.
For years, iOS developers used the description attribute of the deviceToken data sent to the push token delegate to extract the push token a backend application uses to send notifications to the device. With Xcode 11, that description attribute changed to a different format. Existing code developers used for this is now broken. We’ve updated the Azure Notification Hubs SDK to accommodate this change, please update the SDK used by your applications to the version 2.0.4 or newer of the Azure Notification Hubs iOS SDK.
Source -Azure Updates Azure Notification Hubs updates for iOS 13 (Posted on 21 October 2019). Copied the content here for more clarity.
In the article describing the registration management it states that:
The following are some key advantages to using installations:
Creating or updating an installation is fully idempotent. So you can
retry it without any concerns about duplicate registrations
What does it exactly mean? I assume it doesn't mean the installations have a 'CreateOrUpdate' unlike registrations, because a similar method also exists there - 'CreateOrUpdateRegistrationAsync'.
Suppose that I've created two installations with different installation ID but the same PNS handle (pushChannel property) and identical tag 'foo' present in both installations. I'm going to send a notification using the SendTemplateNotificationAsync method using the 'foo' tag to select the target of my notification.
It's going to match both my installations, because they both contain the tag 'foo' and both have the same PNS handle. Is the device going to receive two notifications, or is Azure going to prevent delivery of duplicates in this case?
In the the same article I've linked the code samples do check for existing registrations with the PNS handle that's about to get registered:
// make sure there are no existing registrations for this push handle (used for iOS and Android)
string newRegistrationId = null;
var registrations = await hub.GetRegistrationsByChannelAsync(pushChannel.Uri, 100);
but they don't check that in the installations samples, which again suggests that Azure prevents delivery of duplicate notifications.
Creating or updating an installation is fully idempotent. So you can
retry it without any concerns about duplicate registrations
Here, an installation is a term used to describe an enhanced registration (with Azure's Notification Hub) to associate PNS of the device with tag(s) and/or template(s). "Idempotency" here is used with regards to the act of such an installation.
What it means is that you can simply call the same code for this type of registration every time your app starts or is brought to foreground without worrying about handling changes in PNS or previous states of registration with the Notification Hub.
This is good because the classic registration model can lead to duplicate registrations for the same device and user in the notification hub. Installation model doesn't do that.
Q. What would happen when you have one PNS assigned to multiple registrations with same tag in the Notification Hub and you try to push a notification by targeting a tag?
A. Azure Notification Hub has de-duplication logic which will prevent duplicate notifications from going out.
Q. Can you force multiple notifications (for the same tag) in any way if you have multiple applications but one Notification Hub?
A. You can if you can get multiple device tokens. However, in case of iOS, as APNS issues only one valid device token at a time, it will not be possible. Also, iOS apps have their own bundle identifier and therefore their own specific push certificate. And, Notification Hubs don't support multiple certificates. But in case of Android, you can force it if you use registration model and use older GCM registration Ids as they are renewed frequently and don't expire so easily.
Hope that helps! Cheers!
I'm trying to piece together the general workflow of giving a user push notifications via the service worker.
I have followed this Google Developers service worker push notifications tutorial and am currently thinking about how I can implement this sort of thing in a small user based web app for experimentation.
In my mind, the general workflow of an web app supporting push notifications is as follows:
Client visits app
Service worker yields a push notification endpoint
Client sends the endpoint to the server
Server associates the endpoint with the current user that the endpoint was generated for
Every time something that your app would say is notification worthy happens, the server grabs the push notification endpoint(s) associated with the user, and hits it to send a push notification to any user devices (possibly with a data payload in Chrome 50+, etc)
Basically I just want to confirm that my general implementation thoughts with this technology are accurate, else get feedback if I am missing something.
You are pretty much bang on, there are some specifics that aren't quite right (but this is largely phrasing and may be done to personally taste).
Client visits app
Register a Service Worker that you want to use for push messaging
Use the service worker registration to subscribe the user to push messaging, at which point the user agent will configure an endpoint + additional values for encrypting payloads (If the the user agent supports it).
Client sends the endpoint to the server
Server store the the endpoint and data for later use (The server can associate the endpoint with the current user if the server if the web app has user accounts).
When ever the server wishes to send a notification to a user(s), it grabs the appropriate endpoints and calls them that will wake up the service worker which can then display a notification.
Payload support in coming in Chrome 50+ and at the time of writing payload is support in Firefox, but there are 3 different versions of encryption used for the payloads in 3 different versions of Firefox, so I'd wait for the payload support story to be ironed out a little before using it / relying on it.
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.