Why Azure Push Notification stops working when user is no longer using App or App is on Idle for a long time?

Question

I have a problem with Push notifications which works sometimes and just stops working after a while when a user is no longer using the app. My app registers for push notification with Azure using Web API 2.0 back end when it launches . After a user has successfully logged in to the app , it then updates the registration record to add the username as Tag . According to my knowledge Azure registration has a long life span which is supposed to be sometime in 9999/12/31 23:59:59. My question is , Does both PNS handlers for Android FCM and IOS APNS expires , If they do how can I register the app with Azure again if the user is not using the app for sometime so they wont miss notifications?

Answer 1

One of the most common questions from Azure Notification Hubs customers is how to troubleshoot when notifications that are sent from an application don't appear on client devices. They want to know where and why notifications were dropped, and how to fix the issue. This article identifies why notifications might get dropped or not be received by devices. Learn how to analyze and determine the root cause.

It's critical to first understand how the Notification Hubs service pushes notifications to a device.

In a typical send notification flow, the message is sent from the application back end to Notification Hubs. Notification Hubs does some processing on all the registrations. The processing takes into account the configured tags and tag expressions to determine "targets." Targets are all the registrations that need to receive the push notification. These registrations can span any or all our supported platforms: iOS, Google, Windows, Windows Phone, Kindle, and Baidu for China Android.

With the targets established, the Notification Hubs service pushes notifications to the push notification service for the device platform. Examples include the Apple Push Notification service (APNs) for Apple and Firebase Cloud Messaging (FCM) for Google. Notification Hubs pushes notifications split across multiple batches of registrations. Notification Hubs authenticates with the respective push notification service based on the credentials that you set in the Azure portal, under Configure Notification Hub. The push notification service then forwards the notifications to the respective client devices.

The final leg of notification delivery takes place between the platform push notification service and the device. Any of the four major components in the push notification process (client, application back end, Notification Hubs, and the platform push notification service) might cause notifications to be dropped.

Failure to deliver notifications might occur during the initial test/staging phase. Dropped notifications at this stage might indicate a configuration issue. If failure to deliver notifications occurs in production, either some or all of the notifications might be dropped. In this case, a deeper application or messaging pattern issue is indicated.

Below is the very good article , which explains the diagnosis over dropped connection , and how we can can configure the notification hub setting so that wi will not have any dropped connection .

Notification Hubs Push Notification Fixer

Here i am listing some common misconfiguration which we usually do

* Ensure that your notification hub name (without typos) is the same in each of these locations:
    * Where you register from the client.
    * Where you send notifications from the back end.
    * Where you configured the push notification service credentials.
* Ensure that you use the correct shared access signature configuration strings on the client and on the application back end. Generally, you must use **DefaultListenSharedAccessSignature** on the client and **DefaultFullSharedAccessSignature** on the application back end (grants permissions to send notifications to Notification Hubs).

You must maintain two different hubs: one hub for production, and another hub for testing. This means that you must upload the certificate that you use in a sandbox environment to a separate hub than the certificate and hub that you are going to use in production. Don't try to upload different types of certificates to the same hub. This might cause notification failures.

If you inadvertently upload different types of certificates to the same hub, we recommend that you delete the hub and start fresh with a new hub. If for some reason you can't delete the hub, at a minimum, you must delete all the existing registrations from the hub.

1. Ensure that the *server key* that you obtained from Firebase matches the server key that you registered in the Azure portal.

![Firebase server key][3]

2. Ensure that you have configured **Project ID** on the client. You can obtain the value for **Project ID** from the Firebase dashboard.

![Firebase Project ID][1]

Hope this helps.