azure notification hubs - app uninstall

Question

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.

Answer 1

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.