Как узнать статус доставки Push-уведомлений
Я использую push-уведомление в приложении. Все идет хорошо.
иногда сообщение отправляется с сервера, но в стороне приложения он не получает.
в этой ситуации я должен знать, что сообщение отсутствует для доставки(приложение не получите).
есть ли способ узнать со стороны сервера, какое сообщение получено приложением, а какое нет?
4 ответов
нет, push-уведомления-это огонь и забыть.
Apple не скажет вам следующее:
- не скажет, было ли сообщение отправлено успешно или нет
- не скажет, если пользователь отказался от Push-уведомлений
- много других вещей, но в любом случае...
С другой стороны, когда пользователь выбрал Push-уведомления, ваше приложение может справиться с этим, но в определенной степени:
в принципе, вы можете добавить логику в -didReceiveRemoteNotification: и -didFinishLaunchingWithOptions: чтобы связаться с вашим сервером и сообщить вашему серверу, что сообщение было получено.
Если он не был получен в течение определенного промежутка времени, вы можете отправить его повторно.
но, как видите, это может привести к возможному сценарию затопления невинного пользователя с теми же push-уведомлениями.
В каком-то смысле, беспокоить его, чтобы нажать на ваш глупый толчок уведомление, которое, в свою очередь, может привести ze к отключению push-уведомлений для вашего приложения полностью, но в основном ze удалит приложение и, возможно, даже даст ему низкий рейтинг?
Так тебе и надо, скажу я.
в любом случае, если вы продолжите это, вам нужно будет реализовать шаблон идентификации, где вы вставляете уникальный message identifier в полезную нагрузку push-уведомления, и когда ваше приложение получает это push-уведомление, оно должно отправить это message identifier обратно сервер.
Затем ваш сервер должен зарегистрировать, что определенный токен устройства вернул message identifier, что означает, что он получил это конкретное push-уведомление.
ваш сервер может проверить на ежечасно / ежедневно / whateverly основе и повторно отправить конкретное сообщение на те маркеры устройства, которые не сообщили обратно с относительным message identifier.
опять же, это означает, что ваш сервер может иногда работать.
есть и другие проблемы со всем этим подход:
- пользователь получил push-уведомление, но отклоняет его, а не открывает приложение с ним
- ваш сервер будет считать, что пользователь не видел уведомления толчка и отправит это уведомление толчка снова
- призрачные маркеры устройств
- пользователь сначала принял push-уведомления, но позже отозвал этот privelege
- пользователь удалил приложение
- в основном, маркеры устройств, которые после использования для получения push-уведомления, но больше не делать, скорее всего, из - за Вашего сообщения наводнения репутации
- пользователь получил push-уведомление, но нажимает его позже
- может получить одно и то же push-уведомление несколько раз (очень раздражает)
- пользователь получил push-уведомление, но нажимает его, когда нет подключения к интернету
- пользователь получил push-уведомление, но ваш сервер вниз, возможно, жареный \m/
вы можете обойти последние 3 сценария, имея еще больше логики в вашем приложении, которое ставит в очередь идентификаторы сообщений, которые должны быть отправлены на сервер, и удаляет его только тогда, когда сервер отвечает успешно.
Итак, вы видите, слишком много работы, на стороне сервера + на стороне клиента.
Кроме того, это массовый ухудшитель производительности на стороне сервера при работе с хорошим объемом пользователей, а также снижение производительности вашего приложения на wee немного.
1. Если вы спрашиваете об уведомлениях, не доставленных на устройстве, на котором установлено приложение, и только из-за истечения срока действия уведомления до его доставки или чего-то еще, уведомления не являются delivererd.
ответ
Неа.
Он не обеспечивает поддержку, где вы можете проверить, если уведомления истекли и не доставлены на действительном устройстве:
любой вариант чтобы узнать, если apple app получить push-уведомление?
см. ответ Моше в приведенной выше ссылке. Я включаю его ответ здесь, чтобы он был полезен всем в будущем, даже если ссылка станет мертвой.
короткий ответ, вы не можете, так как APNS-это один из способов. Однако, поскольку приложение может выполнять произвольный код при получении уведомления, вы можете используйте это, чтобы сказать, отправьте http-запрос на свой собственный сервер, когда уведомление получено.
2. Если вы спрашиваете уведомлений, не доставленных как пользователь удалил приложение, то вы можете обратиться к меда ответ в этом посте.
надеюсь, это поможет и дайте мне знать, если у вас есть какие-либо вопросы относительно моего объяснения.
служба Push-уведомлений Apple включает в себя службу обратной связи для дать вам информацию о неудачных push-уведомлений. Когда толчок уведомление не может быть доставлено, поскольку предполагаемое приложение не существует на устройстве, служба обратной связи добавляет маркер этого устройства в свой список. Push-уведомления, срок действия которых истекает до доставки не считается неудачной поставкой и не влияет на обратная связь услуга. Использование этой информации для прекращения отправки push-уведомлений это не будет доставлено, вы уменьшите ненужное сообщение накладные расходы и повышение общей производительности системы.
запрос службы обратной связи ежедневно, чтобы получить список токенов устройства. Использовать метка времени для проверки того, что маркеры устройства не были перерегистрация с момента создания записи обратной связи. Для каждого устройства чтобы не было перерегистрации, прекратите отправлять уведомления. Точек доступа APN контролирует провайдеров за их усердие в проверке обратной связи обслуживание и воздерживаться от отправки push-уведомлений существует приложения на устройствах.
вы можете получить отчет о доставке Push-уведомления, не с сервера, но из вашего приложения, используя "Сервис Расширение " и изменение немного в вашем Push json. Оформить заказ этой ссылке для подробного объяснения.