Блог

У меня проблема с Push-уведомлениями, которые иногда срабатывают и просто перестают работать через некоторое время, когда пользователь больше не использует приложение. Мое приложение регистрируется для push-уведомления в Azure с использованием серверной части Web API 2.0 при запуске. После успешного входа пользователя в приложение оно обновляет регистрационную запись, добавляя имя пользователя в качестве тега. Насколько мне известно, регистрация Azure имеет длительный срок службы, который должен быть где-то в 9999/12/31 23:59:59. Мой вопрос в том, истекает ли срок действия обоих обработчиков PNS для Android FCM и IOS APNS, если истекает, как я могу снова зарегистрировать приложение в Azure, если пользователь какое-то время не использует приложение, чтобы они не пропускали уведомления?

Один из наиболее распространенных вопросов от клиентов Azure Notification Hubs заключается в том, как устранить неполадки, когда уведомления, отправляемые из приложения, не отображаются на клиентских устройствах. Они хотят знать, где и почему были удалены уведомления, и как устранить проблему. В этой статье объясняется, почему уведомления могут удаляться или не приниматься устройствами. Узнайте, как проанализировать и определить основную причину.

Сначала важно понять, как служба Notification Hubs отправляет уведомления на устройство.

В типичном потоке отправки уведомлений сообщение отправляется из серверной части приложения в центры уведомлений. Центры уведомлений выполняют некоторую обработку всех регистраций. При обработке учитываются настроенные теги и выражения тегов для определения «целей». Цели — это все регистрации, которые должны получать push-уведомление. Эти регистрации могут охватывать любую или все поддерживаемые нами платформы: iOS, Google, Windows, Windows Phone, Kindle и Baidu для китайского Android.

После установления целевых параметров служба Notification Hubs отправляет уведомления в службу push-уведомлений для платформы устройства. Примерами могут служить служба Apple Push Notification service (APNs) для Apple и Firebase Cloud Messaging (FCM) для Google. Центры уведомлений отправляют уведомления, разделенные на несколько пакетов регистраций. Центры уведомлений выполняют аутентификацию с помощью соответствующей службы push-уведомлений на основе учетных данных, которые вы установили на портале Azure в разделе Настройка центра уведомлений. Затем служба push-уведомлений пересылает уведомления на соответствующие клиентские устройства.

Заключительный этап доставки уведомлений происходит между службой push-уведомлений платформы и устройством. Любой из четырех основных компонентов процесса push-уведомлений (клиент, серверная часть приложения, центры уведомлений и служба push-уведомлений платформы) может привести к удалению уведомлений.

Сбой доставки уведомлений может произойти на начальном этапе тестирования / промежуточного этапа. Пропущенные уведомления на этом этапе могут указывать на проблему с конфигурацией. Если в процессе производства происходит сбой доставки уведомлений, некоторые или все уведомления могут быть удалены. В этом случае указывается более глубокая проблема с приложением или шаблоном обмена сообщениями.

Ниже приведена очень хорошая статья, в которой объясняется диагностика при сброшенном соединении и то, как мы можем настроить параметр notification hub, чтобы у wi не было сброшенного соединения.

Исправитель Push-уведомлений в концентраторах уведомлений

Здесь я перечисляю некоторые распространенные неправильные настройки, которые мы обычно выполняем

 * 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]
  

Надеюсь, это поможет.