Почему Azure Push Notification перестает работать, когда пользователь больше не использует приложение или приложение долгое время находится в режиме ожидания? - PullRequest
1 голос
/ 13 марта 2019

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

1 Ответ

0 голосов
/ 14 марта 2019

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

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

enter image description here

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

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

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

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

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

Концентраторы уведомлений 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]

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

...