Ответ 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 сценария, добавив еще больше логики в ваше приложение, которое ставит в очередь идентификатор сообщения, который должен быть отправлен на сервер, и удаляет его только тогда, когда сервер отвечает успешно.
Итак, вы видите, слишком много работы, серверная сторона + клиентская сторона.
Кроме того, это огромная деградация производительности на стороне сервера при работе с хорошим объемом пользователей, а также снижение производительности вашего приложения небольшим битом.