Как узнать статус доставки Push Notification

Я использую push-уведомление в приложении. Все идет хорошо.

Иногда сообщение отправляется с сервера, но со стороны приложения он не получает.

В этой ситуации я должен знать, какое сообщение отсутствует для доставки (приложение не получило).

Есть ли способ узнать с сервера, какое сообщение получено приложением, а какие нет?

Ответ 1

Nopes, push-уведомления - это fire-and-forget.

Apple не скажет вам следующее:

  • Не укажет, было ли сообщение отправлено успешно или нет
  • Не укажет, отказался ли пользователь от Push-уведомлений
  • многое другое, но в любом случае...

Однако

С другой стороны, когда пользователь выбрал Push Notifications, ваше приложение может справиться с этим, но в определенной степени:

В принципе, вы можете добавить логику в -didReceiveRemoteNotification: и -didFinishLaunchingWithOptions:, чтобы связаться с вашим сервером и сообщить серверу, что сообщение получено.
Если он не был получен в течение определенного временного интервала, вы можете отправить его повторно.

Но, как вы видите, это может привести к возможному сценарию затопления невиновного пользователя с теми же push-уведомлениями.
В некотором смысле, преследуя его, чтобы использовать ваше глупое push-уведомление, которое, в свою очередь, может привести к отключению push-уведомлений для вашего приложения, но в основном ze удалит приложение и, возможно, даже даст ему низкий рейтинг?
Скажу вам, правильно.

В любом случае, если вы продолжите это, вам нужно будет внедрить шаблон идентификации, в который вы вставляете уникальный message identifier в полезную нагрузку push-уведомления, и когда ваше приложение получает это push-уведомление, оно должно отправить этот message identifier вернуться на сервер.
Затем ваш сервер должен зарегистрировать, что конкретный токен устройства возвратил message identifier, что означает, что он получил это конкретное push-уведомление.

Ваш сервер может проверять почасовую/ежедневную/безоговорочную основу и повторно отправлять определенное сообщение этим токенам устройства, которые не сообщаются с относительным message identifier.

Опять же, это означает, что вашему серверу иногда может понадобиться OT.


Есть и другие проблемы с этим целым подходом:

  • Пользователь получил push-уведомление, но отклоняет его, а не открывает ваше приложение.
    • Ваш сервер предположит, что пользователь не увидел push-уведомление и снова отправит это push-уведомление.
  • Знаки устройства Ghost
    • Пользователь принял push-уведомления сначала, но позже отозвал этот privelege
    • Пользователь удалил приложение
    • В основном, токены устройства, которые когда-то используют для получения push-уведомления, но больше не выполняются, скорее всего, из-за вашего сообщения о репутации репутации
  • Пользователь получил push-оповещение, но в следующий раз удаляет его
    • может получать одно и то же уведомление push несколько раз (очень раздражает)
  • Пользователь получил push-уведомление, но отменил его, когда нет подключения к интернету.
  • Пользователь получил push-уведомление, но ваш сервер не работает, возможно, fried\m/

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

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

Ответ 2

1. Если вы спрашиваете об уведомлениях, которые не были доставлены на устройстве, на котором установлено приложение на устройстве, и только из-за истечения срока действия уведомления до его доставки или чего-то еще, уведомления не являются поставщиками.

Тогда ответ

Нет.

Он не обеспечивает поддержку, где вы можете проверить, не истечет ли срок действия Уведомления и не доставлен на действительное устройство:

любой параметр, чтобы узнать, получит ли приложение apple push-уведомление?

См. ответ Моше в приведенной выше ссылке. Я включаю его ответ здесь, чтобы он был полезен каждому в будущем, даже если связь становится мертвой.

Короткий ответ, вы не можете, поскольку APNS - это один из способов. Однако, поскольку приложение может выполнить произвольный код после получения уведомления, вы можете используйте это, чтобы сказать, отправьте HTTP-запрос на ваш собственный сервер, когда уведомление получено.

2. Если вы спрашиваете, что уведомления, не доставленные как пользователь, удалили приложение, вы можете обратиться к meda ответу в этом сообщении.

Надеюсь, это поможет вам и сообщите мне, есть ли у вас какие-либо вопросы относительно моего объяснения.

Ответ 3

Служба обратной связи

Служба уведомлений Apple Push включает службу обратной связи для дать вам информацию о неудачных push-уведомлениях. Когда толчок уведомление не может быть доставлено, потому что предполагаемое приложение не существуют на устройстве, служба обратной связи добавляет, что токены устройств его список. Push-уведомления, которые истекают до их доставки, не считается неудачной доставкой и не влияет на обратную связь оказание услуг. Используя эту информацию, чтобы прекратить отправку push-уведомлений которые не будут доставлены, вы уменьшаете ненужное сообщение накладные расходы и улучшить общую производительность системы.

Запросить службу обратной связи ежедневно, чтобы получить список токенов устройства. использование отметка времени, чтобы убедиться, что токены устройства были перерегистрация с момента создания записи обратной связи. Для каждого устройства который не был перерегистрирован, прекратите отправку уведомлений. APNs контролирует поставщиков за их усердие в проверке обратной связи обслуживание и воздержание от отправки push-уведомлений на несуществующий приложений на устройствах.