Device Registration to Azure Notification Hubs

80 views Asked by At

I'm trying to use Azure Notification Hubs for remote notifications for my mobile app.

When my mobile app is first installed on a device, I create and store an installationId on the device which is a GUID value. I use Shiny to handle device registration with Apple/FCM and then it gives me a registrationToken. I then pass both my installationId and registrationToken along with device platform to my backend API where I use the code below to handle the registration:

public async Task RegisterDevice(Guid installationId, string registrationToken, string platform)
{
   var installation = new Installation();
   installation.InstallationId = installationId.ToString();
   installation.PushChannel = registrationToken; // This is the registration token I get from Shiny
   installation.Platform = platform == "ios" ? NotificationPlatform.Apns : NotificationPlatform.Fcm;

   await _notificationHubsClient.CreateOrUpdateInstallationAsync(installation);
}

The _notificationHubsClient is my wrapper for NotificationHubClient that comes with the Microsoft.Azure.NotificationHubs NuGet package.

WHen I check the registration info by getting all the registrations on my notifications hub, I don't see my InstallationId anywhere in the JSON object. Instead I see the registrationToken as InstallationId under tags. It looks like this:

{
    "eTag": "1",
    "expirationTime": "9999-12-31T23:59:59.9999999Z",
    "registrationId": "1234567890232290733-3250316115430032296-3",
    "tags": [
      "$InstallationId:{999a99a9999999a99a99a9a99aa99999}" // <- This is the registrationToken value
    ],
    "pushVariables": null,
    "pnsHandle": "aAaaBCdeF0qUgk7kMPrVUB...",
    "isReadOnly": false,
    "extensionData": {}
  }

Could someone please tell me what I'm doing wrong here?

1

There are 1 answers

0
MarStr On

Good news, you're not doing anything wrong. If you retrieve the Installation using the Read Installation operation, your installation ID and tokens will match the format you were expecting here.

Azure Notification Hubs has two mostly separate ways to store device records, Installations and Registrations. Mostly, the distinction was a way to allow for API changes without introducing backwards compatibility questions. For example, changing policy on what happens when a device handle expires, moving to an asynchronous model, etc. For better or worse, Read All Registrations was decided to return all devices stored a hub, not just records that were added as registrations. While that does allow for a unified way to get all records, it does cause a little confusion.