Azure Notification Hub integration and support for Firebase FCM API v1

[Floris-NL-NL]

The "old" Firebase API will stop working 20/6/2024 and so I was testing with the new API V1:
"If you are an existing user of the legacy HTTP or XMPP APIs (deprecated on 20/6/2023), you must migrate to the latest Firebase Cloud Messaging API (HTTP v1) by 20/6/2024"

I use Azure Notification Hub to send push messages to IOS and Android. This question is about the Android devices.

• Registrations in Firebase are successfully created.
• Registrations in Azure Notification Hub are successfully created... but:

The problem is that the Android device registrations (that are created by Shiny) in my Azure Notification hub have the platform type "Fcm" and this should be "FCMV1" per: https://learn.microsoft.com/en-us/azure/notification-hubs/firebase-migration-rest

In Shiny's AzureNotificationHubsPushProvider.cs there is only the old value "Fcm":

#if APPLE
Platform = NotificationPlatform.Apns
#elif ANDROID
Platform = NotificationPlatform.Fcm
#endif

This results in push messages that are only delivered if I use the old API call in the Azure Notification Hub SDK:

await conn.SendNotificationAsync(nn, "tag1");

And nothing is delivered when using the new function:

await conn.SendFcmV1NativeNotificationAsync(jsonBodyTest, "tag1");

Is my assumption correct and is the new Firebase API v1 registration platform type not yet supported by Shiny's Azure Notification Hub implementation?
Or is FCMV1 already supported for Azure Notification Hub Android device registrations created by Shiny and is there a setting somewhere if I want to use FCMV1 and not the legacy API platform setting for the device registration in the hub?

[aritchie]

Firebase is not used at all on the iOS side of Shiny with azure notification hubs. The android version of firebase is already up-to-date. Azure notification hubs on the server side does require you use the newer setup which they cover in their docs.

For server setups, please consult the Azure notification Hubs documentation. I don't want to support those setups here.

[Cybrosys]

@aritchie I'm quite new to this so sorry if I'm misunderstanding something.

I've been struggling trying to get push notifications to work using various libraries for a .NET MAUI app and I'm currently working on getting Shiny.NET on Android working.

I started out doing the the FCM v1 setup server-side between Firebase and Azure Notification Hubs. But trying to send the test notification just resulted in 0 passed, 0 failed.

I then proceeded to activating the Firebase Legacy API and configured GCM/FCM in Azure Notification Hubs. Now when using the send test notification, it reports 1 passed, 0 failed.

My take on this is that the device registration in Firebase or Azure, registers it as GCM/FCM and I have no control over it?

If this responsibility lies with Shiny, then why shouldn't it register the device as FCM v1 when using the AddPushAzureNotificationHubs extension method?

builder.Services.AddPushAzureNotificationHubs<MyPushDelegate>(
    PushNotifications.Constants.ListenConnectionString,
    PushNotifications.Constants.NotificationHubName,
    firebaseConfig);

Sorry again if I'm missing something here, this is all new to me.

[Floris-NL-NL]

Hi,

Indeed, this is exactly what I was saying... the Android device registration that is created by Shiny in Azure Notification Hub is created with the platform code "FCM" and this should be "FCMV1" for it to work with the new API so you can send push notifications after 20/6/2024 thru Azure Notification Hub to Android devices.

In my opinion Shiny should be updated so you at least have the option to choose the platform used for the device registration in Azure Notification Hub for Android devices.

The only option now is to update the device registration yourself for example by using the "Microsoft.Azure.NotificationHubs" NuGet package (after Shiny created the registration in the hub) and set the platform to "FCMV1":

[Cybrosys]

As a temporary solution after looking at the code and documentation, we could create our own provider and extension method. The provider would just be a copy of the AzureNotificationHubsPushProvider but pass in FcmV1.

[Floris-NL-NL]

Yes that's also a possibility.

But for now I'll stick with the 3 lines of code to update the registration in the hub and hope Shiny will be updated later (tested and works 100%).

[aritchie]

GUYS - if you have opinions or things you've found that fix an issue - SEND A PR!

Yes it is an easy fix, but all of the mechanisms are there to "go your own way" with the push provider.

But for now I'll stick with the 3 lines of code to update the registration in the hub and hope Shiny will be updated later (tested and works 100%).

This is the kind of attitude I don't want here. This is free code. Don't send workarounds when you could easily send a fix.

[Floris-NL-NL]

I'm sorry you feel that way. All I did was help another person with a workaround because he had the same problem.

The comment "tested and works 100%" was about my workaround and not about a potential Shiny update.

Bottom line and to be honest: I'm not skilled enough to provide a worthy fix/PR for the Shiny project that equals the high standard of the complete project, I'm sorry.

[Cybrosys]

@aritchie I understand and apologize. In my previous comment above I asked for clarification as this is all new to me and I don't yet have a complete understanding of which parts owns which responsibility (Shiny, Firebase, Azure).

That was why I was asking for clarification to your initial response and closing of the discussion that Floris initiated. Your actions, to me, indicated that you did not want this fixed or changed.

I can gladly submit a PR if this is something we are allowed to fix/change in the AzureNotificationHubsPushProvider.

Update
Seems you beat me to it :) Thank you