Нет связи с серверами службы eset push notification service

Обновлено: 03.07.2024

В этом разделе обсуждаются начальные действия по устранению неполадок, которые необходимо выполнить при возникновении проблем с уведомлениями плитки, всплывающих уведомлений и значками, включая различные методы уведомления: локальные, Push, периодически и запланированные уведомления.

Устранение конкретных ошибок

В этом разделе рассматриваются некоторые распространенные ошибки, которые могут возникнуть при работе с Push-уведомлениями.

Проверка журналов событий
Push-уведомление получает ответ "200 ОК", но не отображает
Push-уведомление возвращает код, отличный от "200 ОК"
Ошибки при попытке создать канал push-уведомлений

Проверка журналов событий

Если плитки или всплывающие уведомления не отображаются должным образом, просмотрите журналы событий.

если уведомление получено, но не показано: запустите Просмотр событий и изучите журнал microsoft-Windows-твинуи/эксплуатацию в разделе "приложения и службы \ microsoft \ Windows \ приложения".
если уведомление не получено, запустите Просмотр событий и изучите журнал операций в разделе applications and Services \ Microsoft \ Windows \ пушнотификатионс-Platform.

Push-уведомление получает ответ "200 ОК", но не отображает

если Windows Push Notification Services (WNS) возвращает ответ "200 ок", то он будет доставлять уведомление клиенту, если клиент находится в сети. Если вы проверили, что клиент находится в сети, но не отображает уведомление, выполните следующие действия.

Причина: ошибки XML в содержимом уведомления.

Исправление. Проверьте синтаксис языка XML и убедитесь, что XML-код завершен и правильно. Ниже перечислены некоторые распространенные моменты сбоя в XML-содержимом.

Чувствительность к регистру. Имена тегов, имена атрибутов и значения атрибутов чувствительны к регистру. Убедитесь, что XML имеет правильный регистр.
Для каждого поддерживаемого формата плитки должен быть указан элемент Binding . Необходимо предоставить элемент привязки для каждого размера плиток, поддерживаемых в каждом отправляемом уведомлении.
Текстовые строки не должны содержать зарезервированных символов XML. Например, нельзя курсивировать строки мозаики или всплывающих уведомлений, включив <i> </i> теги и. Если предполагается отображать литеральные символы " <i> ", они должны быть правильно экранированы. Дополнительные сведения о escape-символах в XML см. в разделе сущности символов XML и XAML.
Значения, указанные для атрибутов lang , должны соответствовать спецификации итеф BCP 47 .
Строки XML, отправляемые через push-уведомления, должны использовать кодировку UTF-8.
При включении элемента Image в полезные данные XML с непустым атрибутом src необходимо обязательно включить ссылку на допустимое изображение, иначе уведомление будет удалено.

Причина: неправильное использование параметров API push-уведомлений

Исправление. см. документацию по API в Windows. Пространство имен Networking. Пушнотификатионс для конкретных параметров.

Причина: тип заголовка не соответствует содержимому уведомления. Если в заголовке X-WNS-Type не задано значение (плитка, эмблема или всплывающее уведомление), соответствующее шаблону уведомления, указанному в полезных данных, то уведомление не будет отображаться. Это несоответствие приведет к ошибке на стороне клиента, и уведомление будет удалено.

Причина: значение срока жизни (TTL), заданное в заголовке X-WNS-TTL, слишком мало.

Исправление. Укажите значение ДЛИННОГО срока жизни, учитывая, что значение указано в секундах.

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

Push-уведомление возвращает код, отличный от "200 ОК"

Запрос уведомления возвращает "400 недопустимый запрос"
Запрос уведомления возвращает значение "401 с несанкционированным"
Запрос уведомления возвращает значение "401 не авторизовано", срок действия токена истек
Запрос уведомления возвращает значение "403 запрещено".
Запрос уведомления возвращает значение "404 не найдено"
Запрос уведомления возвращает значение "406 неприемлемо"
Запрос уведомления возвращает "410"

Запрос уведомления возвращает "400 недопустимый запрос"

Запрос уведомления возвращает значение "401 с несанкционированным"

Причина: сервер приложений должен использовать правильный идентификатор безопасности пакета (SID пакета) и секретный ключ, предоставленный вам при регистрации приложения. если вы недавно изменили секретный ключ на панели мониторинга хранилища Windows, потребуется также обновить сервер приложений.

исправление: посетите Windows сторедашбоард, чтобы проверить идентификатор безопасности и секрет пакета.

Запрос уведомления возвращает значение "401 не авторизовано", срок действия токена истек

Причина: маркер доступа имеет конечное время существования. Если вы отправляете уведомление с просроченным маркером доступа, учетные данные сервера приложений являются недопустимыми, и уведомление не может быть отправлено.

Исправление. запросите новый маркер доступа из WNS, прополнив аутентификацию в WNS с помощью идентификатора безопасности пакета (SID пакета) и секретного ключа. дополнительные сведения см. в обзоре Windows Push-Notification Services (WNS) .

Запрос уведомления возвращает значение "403 запрещено".

исправление. войдите на панель мониторинга хранилища Windows с помощью учетной записи разработчика. Выберите свое приложение и щелкните "дополнительные функции"- > "Управление параметрами облачной службы". Выберите "идентификация приложения", чтобы ознакомиться с инструкциями по обновлению манифеста приложения в соответствии с учетными данными облачной службы.

Запрос уведомления возвращает значение "404 не найдено"

Причина: Эта ошибка обычно означает, что URL-адрес канала сформирован неправильно. URL-адрес канала никогда не должен быть изменен при отправке уведомления в WNS. URL-адрес канала всегда должен рассматриваться как непрозрачная строка — вам никогда не нужно изучать или даже знать его содержимое.

Исправление. Убедитесь, что код не изменяет URL-адрес канала, изменив один или несколько символов или изменив его кодировку.

Запрос уведомления возвращает значение "406 неприемлемо"

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

Исправление. Проверьте частоту уведомлений, чтобы узнать, можно ли его уменьшить или оптимизировать для повышения удобства работы пользователей.

Запрос уведомления возвращает "410"

Причина: истек срок действия URL-адреса канала. Дальнейшие уведомления не могут быть отправлены, пока приложение не будет запущено и запросит новый URL-адрес канала.

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

Ошибки при попытке создать канал push-уведомлений

Создание канала уведомления приводит к ОШИБКе " _ отсутствует _ Сетевая ошибка"
Создание канала уведомления приводит к _ _ ошибке в облаке ВПН E. _
Создание канала уведомления приводит к возникновению ошибки "ВПН _ E _ Invalid _ App"

Создание канала уведомления приводит к ОШИБКе " _ отсутствует _ Сетевая ошибка"

Причина. для создания канала уведомления WNS требуется подключение к Интернету.

Исправление. Проверьте подключение к Интернету.

Создание канала уведомления приводит к _ _ ошибке в облаке ВПН E. _

Причина: приложение не объявило возможности Интернета в манифесте приложения (Package. appxmanifest).

Исправление. Убедитесь, что манифест приложения объявил возможности Интернета. в редакторе манифестов Visual Studio этот параметр находится на вкладке возможности в интернете (клиент). Дополнительные сведения см. в разделе возможности.

Создание канала уведомления приводит к возникновению ошибки "ВПН _ E _ Invalid _ App"

Причина: приложение должно использовать допустимое имя пакета. если вы еще не получили его, вы можете получить его на портале хранилища Windows в разделе "дополнительные возможности".

исправление. дополнительные сведения о получении идентификатора безопасности пакета (пксид) для приложения для магазина Windows см. в статье Windows Push Notification Services (WNS).

Alena Gorkova сегодня в 10:03
Добрый день. Много лет пользуюсь ESET. Никаких проблем с обновлением не было. После последнего продления лицензии программа дает ошибку :

Alena, Перейдите в раздел "Справка и поддержка", нажмите на кнопку "Изменить лицензию" и повторно введите ключ. Затем перезагрузите компьютер.

Виталий, уточните, установлены ли у Вас на компьютере программы крипто про или vipnet?

Антивирусник предлагает скачать новую версию "Совершенно бесплатно". Но разные версии - по-разному стоят. Будет ли тогда уменьшен срок действия лицензии?

Версия программы никак не влияет на стоимость и срок действия лицензии - все обновления программы предоставляются владельцам лицензии бесплатно.

Ну а так годнота. Если бы автор оригинала еще больше про свой сервер уведомлений рассказал. Ведь не просто так люди всякие Urbanairship используют.

То есть тот же скайп запущенный или аська на эппле могут в тупую уснуть и месседж дойдёт неизвестно когда? Так?
На андроиде тоже? Я вот не понял, а причем тут вообще приложения? Речь же про пуш нотификаторы.
На сколько я понял, автор писал, что нет никакой возможности узнать, дошел ли нотификатор до девайса, увидел ли его пользователь, закрыл или нажал на него.

По Андроиду не могу сказать, но думаю, что на этой платформе можно ожидать аналогичного поведения.

В общем случае, уведомление приходит вне зависимости от того, запущено приложение, или нет. Уведомление ориентируется на токен устройства и bundle identifier.

Не прийти оно может только если нет доступа в сеть. Ну, или если заблудилось по дороге.

В общем случае — безусловно. В случае если «убить» скайп, уведомления не будут приходить. Потому что «серверная часть» скайпа не отправляет уведомления, если пользователь в оффлайне. потому что скайп как VoIP приложение может работать в фоне по-настоящему, ему не нужны пуши, поэтому это не пуши, а локальные уведомления.

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

Ну а скайп постоянно работает в фоне, так что его это не касается.

Однажды я два дня занимался сексом с пуш-уведомлениями, потому что они не приходили.
Оказалось, что у меня телефон подглючил и не принимал их. Через пару часов, после наладки, всё стало отлично приниматься.
Так что не торопитесь опускать руки при работе с пуш-уведомлениями, и проверяйте всё на несколько раз. А еще стоит проверить время на сервере, т.к. оно может сбится, и часть пушей может отправляться в «прошлое». Приложение для тестирования это хорошо, но многим хотелось бы узнать как правильно настроить свой vds/vps для работы с push сертификатом.

В статье написано о том, что пользователь может индивидуально настроить виды уведомлений. Но не сказано, можно ли самому по умолчанию задать тип уведомлений с помощью кода?

Задавался аналогичным вопросом и нашёл ответ на него: нет, задать тип уведомлений нельзя, т. к. начиная с iOS 5.0 под алертом понимается как баннер, так и напоминание. И баннер выбирается по умолчанию в связи со своей ненавязчивостью.

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

Я последние полторы недели делал уведомления для APNS и GCM. Добавлю свои 5 копеек.

2. Есть засада с сертификатами Entrust, которые использует APNS. Копипаста из доков:
Note: To establish a TLS session with APNs, an Entrust Secure CA root certificate must be installed on the provider’s server. If the server is running OS X, this root certificate is already in the keychain. On other systems, the certificate might not be available. You can download this certificate from the Entrust SSL Certificates website.

Оф. документация на оба момента — goo.gl/rwO8t

Последняя отвратительно написана и энкораджит откровенно плохой стиль кодирования. Можно просто поглядеть исходники и все сразу станет ясно.

Java-apns написана отлично и не тянет лишних депенденций. Проблема с ней — автор отошел от дел полтора года назад, версию 2.0 в мавен не зарелизил и по сути проект не поддерживается. Последняя доступная в maven central версия имеет отровенные баги — ну, например, в конфигурации с тред-пулом не работает error detection. Тем не менее, качество кода отличное и исправление занимает минуты. Многие компании форкнули либу и используют в работе со своими мелками доделками. В пул-реквестах на гитхабе все это хорошо видно.

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

Но что если происходит что-то интересное и вы хотите сообщить об этом пользователям, даже если ваше приложение у них не запущено?

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

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

Краткий обзор

Схема работы механизма push-уведомлений:

iOS запрашивает у сервера Apple Push Notification Service (APNS) токен девайса.
Приложение получает токен девайса. Можно считать, что токен – это адрес для отправки push-уведомлений.
Приложение отправляет токен девайса на ваш сервер.
Когда произойдёт какое-либо событие для вашего приложения, сервер отправит push-уведомление в APNS.
APNS отправит push-уведомление на девайс пользователя.

Стоит ли по-прежнему использовать push-уведомления, если уже в iOS 4.0 появились локальные уведомления и мультизадачность? Ещё бы!

Локальные уведомления — это ограниченные по времени события. Только VOIP-приложения, навигация и фоновое воспроизведения звука обладают возможностью неограниченного фонового выполнения. Если необходимо уведомить пользователей приложения (пока оно закрыто) о каком-либо внешнем событии, вы всё ещё должны использовать push-уведомления.

В этом руководстве будет детально описана работа системы push-уведомлений и как её интегрировать в своё приложение.

Что необходимо для push-уведомлений

Для интеграции push-уведомлений в приложение необходимо:

iPhone, iPad или iPod touch. Push-уведомления не работают в симуляторе, поэтому для тестирования нужен девайс.

Если хотите полностью выполнять примеры из этого руководства, вам необходимо создать provisioning profile и SSL-сертификат. Я в деталях объясню, как это сделать.

Сервер, подключенный к интернету. Push-уведомления всегда отправляются сервером. В процессе разработки вы можете использовать ваш собственный Мак в качестве сервера, но для релиза нужно что-то наподобие VPS (Virtual Private Server).

Для работы с push-уведомлениями дешёвого виртуального хостинга недостаточно. Вам необходимо запустить фоновое выполнение на сервере, установить SSL-сертификат, настроить исходящее TLS-соединение на определённых портах. Большинство провайдеров виртуального хостинга не позволят вам это сделать. Хотя если обратиться в службу технической поддержки, то вам, скорее всего, помогут решить все проблемы. Но всё же я настоятельно рекомендую использовать VPS.

Анатомия push-уведомлений

Блок, ограниченный фигурными скобками содержит словарь, который состоит из пар «ключ-значение» (так же, как и в NSDictionary).

Кроме этого, в «aps» можно добавить и другие поля для настройки уведомления. Например:

Теперь значение поля «alert» — это словарь. «action-loc-key» содержит альтернативный текст для кнопки «Запустить». Поле «badge» содержит число, которое будет отображено на бейдже иконки приложения. Push-уведомление не будет сопровождаться звуковым сигналом.

Есть довольно много способов формирования JSON полезной нагрузки. Вы можете изменить звуковой сигнал уведомления, добавить свои собственные поля. Дополнительную информацию можно найти на странице «Local and Push Notification Programming Guide» сайта разработчиков Apple.

Push-уведомления — это нечто довольно маленькое; размер полезной нагрузки не может превышать 256 байт. Это примерно столько же, сколько позволяет вместить в себя СМС или твит. Push-сервер не будет тратиться на переносы на новую строку и пробелы, а сгенерирует что-то наподобие этого:

Такое представление менее читаемо, однако предоставляет достаточно места для более ценной информации. APNS отклонит push-уведомления, чьи размеры превышают 256 байт.

Понимание push-уведомлений

Они не надёжны! Нет гарантий, что push-уведомления будут доставлены, даже если APNS примет их.

Как только ваш сервер сформировал push-уведомление, он безответно отправляет его в APNS. Нет способа узнать статус доставки уведомления конечному пользователю после отправки. Время доставки может варьироваться от нескольких секунд до получаса.

Кроме этого, у пользователей i-девайсов может не быть возможности получать push-уведомления всё время. Например, рядом нет Wi-Fi сети с доступом в интернет либо девайс может быть вообще выключен.

APNS будет пытаться доставить последнее отправленное уведомление, когда девайс станет доступен для приёма. Но эти попытки ограничены по времени. После тайм-аута push-уведомление будет потеряно навсегда!

Они могут быть дорогими! Добавить push-функционал в приложение довольно просто и недорого, если вы владеете данными. Однако если у вас много пользователей либо необходимо запрашивать данные, то затраты резко возрастают.

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

Но что если ваше приложение — это RSS-читалка, позволяющая пользователям вносить URL-адреса своих лент? В этом случае вам необходимо придумать механизм слежения за обновлением добавленных лент.

На практике это означает, что вашему серверу нужно постоянно проверять ленты на изменение. Если у вас много пользователей, то возможно, придётся установить дополнительные сервера для обработки всех процессов и поддержки стабильной пропускной способности. Для таких приложений, как RSS-читалка, реализация push-функционала может стать довольно затратной и не представлять ценности для вас.

Ладно, хватит теории. Настало время изучить процесс реализации всех этих push-вещей. Но до того, как приступать к самому «вкусному» — программированию! — нужно выполнить несколько скучных настроек на iOS Provisioning Portal. Что ж, давайте сделаем их настолько быстро, насколько это возможно.

Provisioning Profiles и Сертификаты

Для того чтобы подключить push-уведомления к приложению, необходимо подписать его правильно сконфигурированным provisioning profile. Кроме этого, вашему серверу необходимо соединиться с APNS при помощи SSL-сертификата.

Provisioning profile и SSL-сертификат тесно связаны друг с другом и действительны только для одного App ID. Это защита, гарантирующая, что только ваш сервер может отправлять push-уведомления пользователям вашего же приложения.

Как вы знаете, для разработки и релиза приложения используют разные provisioning profiles. Есть два типа push-сертификатов для сервера:

Разработка (Development). Если приложение работает в режиме отладки и подписано provisioning profile для разработки (Code Signing Identity — «iPhone Developer»).
Релиз (Production). Приложения, созданные как Ad-Hoc или подготовленные для загрузки на App Store (Code Signing Identify — «iPhone Distribution») должны сообщить серверу, что используют сертификат для релиза (Production certificate). Если между ними будут несоответствия, то push-уведомления не смогут приходить в ваше приложение.

Генерация Certificate Signing Request (CSR)

Помните, как вы заходили на iOS Provisioning Portal и создавали сертификат разработчика (Development Certificate) после присоединения к iOS Developer Program? Следующие шаги будут аналогичными. Но всё же я советую выполнять их в точности, как будет описано ниже. У разработчиков большинство проблем с push-уведомлениями как раз и связано с сертификатами.

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

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

Откройте утилиту «Связка ключей» («Приложения → Утилиты (Другие)») и выберите опцию «Запросить сертификат у бюро сертификации…».

Сейчас перед вами должно быть окно ассистента сертификации:

Здесь введите e-mail. Разработчики советуют в качестве электронной почты использовать такую же, которую вы использовали для регистрации в iOS Developer Program, но это не обязательно.

В качестве общего имени введите «PushChat». Вы можете ввести что угодно, но выберите что-нибудь описательное. Позже это позволит легко найти приватный ключ.

Установите переключатель «Сохранён на диске» и нажмите «Продолжить». Сохраните файл под именем «PushChat.certSigningRequest».

Создание App ID и SSL-сертификата

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

Кликните на пункт «App IDs» в сайдбаре и нажмите на кнопку «New App ID».

Я заполнил поля следующим образом:

Description: PushChat
Bundle Seed ID: по умолчанию
Bundle Identifier: me.evgeniy.PushChat

Будет лучше, если вы укажите свой собственный Bundle Identifier — com.yoursite.PushChat — вместо моего. В Xcode-проекте необходимо установить такой же bundle ID.

Ещё несколько моментов: мы сгенерируем SSL-сертификат, который будет использовать ваш push-сервер для защищённого соединения с APNS. Этот сертификат связан с App ID. Сервер может посылать push-уведомления только вашему приложению и никакому другому.

После того, как был создан App ID, он появится в списке:

В колонках «Development» и «Production» напротив «Push Notification» есть два оранжевых кружка с надписью «Configurable». Это значит, что App ID может использовать push-уведомления, но их всё ещё необходимо настроить. Поэтому переходим по ссылке «Configure».

На появившейся странице ставим флажок напротив «Enable for Apple Push Notification service». Далее нажмите кнопку «Configure» в строке с Development Push SSL Certificate. Откроется окно «Apple Push Notification service SSL Certificate Assistant»:

Первое, что необходимо — это сгенерировать Certificate Signing Request. Мы уже сделали это, поэтому нажмите «Continue».

На следующем шаге необходимо загрузить CSR на сервер Apple. Выберите CSR-файл, который вы сгенерировали ранее и нажмите «Generate».

Генерация SSL-сертификата займёт несколько секунд. Когда будет готово, нажмите «Continue».

Для того, чтобы скачать сертификат, нажмите «Download» — он будет сохранён под именем «aps_development.cer». После нажмите «Done».

Теперь у нас есть валидный сертификат и механизм push-уведомлений доступен для разработки. Если необходимо, вы можете снова загрузить сертификат.

Когда ваше приложение будет готово к релизу, необходимо повторить весь процесс для генерации Production-сертификата. Все шаги аналогичны.

Замечание. Production-сертификат действителен в течении года, но вы можете пересоздать его до истечения срока.

Нет необходимости добавлять сертификат в связку ключей. Если же вы захотите это сделать, то кликните два раза по скачанному ранее файлу aps_development.cer (после этого сертификат будет ассоциирован с приватным ключом).

Создание Provisioning Profile

Зайдите на Provisioning Portal. Перейдите по ссылке «Provisioning» и нажмите на кнопку «New Profile».

Я заполнил поля следующим образом:

Profile Name: PushChat Development
Certificates: выберите сертификат
App ID: PushChat
Devices: выберите ваш девайс(ы)

Нажмите «Submit» и profile будет сгенерирован. У нового profile будет установлен статус «Pending». Перезагрузите страницу и увидите, что статус изменился на «Active». Теперь вы можете скачать provisioning profile (файл с названием «PushChat.mobileprovision»).

Добавьте provisioning profile в Xcode перетянув файл на иконку IDE либо кликнув на файл два раза.

Если ваше приложение готово к релизу, то вам необходимо повторить описанный выше процесс для создания Ad Hoc или App Store distribution profile.

Простенькое приложение

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

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

Откройте Xcode и создайте новый проект. В ассистенте выберите «Single View Application» и перейдите к следующему шагу.

Я заполнил поля следующим образом:

Product Name: PushChat
Company Identifier: me.evgeniy
Class Prefix: PC
Device Family: iPhone
Флажки: «Use Storyboards» и «Use Automatic Referance Counting»

После создания проекта, откройте PCAppDelegate.m. Измените метод didFinishLaunchingWithOptions следующим образом:

Вызов registerForRemoteNotificationTypes сообщает iOS, что это приложение хочет получать push-уведомления.

Соберите и запустите приложение. Для этого необходимо использовать девайс, потому что симулятор не поддерживает push-уведомления. Xcode автоматически выберет новый provisioning profile. Если во время запуска приложения произошла ошибка, убедитесь, что в Code Signing Identity выбран правильный profile.

Приложение запросит разрешение только один раз. Если пользователь нажмёт «OK», push-уведомления будут приходить, если «Запретить» — не будут. Своё решение можно изменить в настройках.

Ваше приложение может определить, какие типы push-уведомлений включены:

Существует ещё одна вещь, которую вы должны добавить в приложение для того, чтобы иметь возможность получать push-уведомления. Добавьте следующий код в PCAppDelegate.m:

Когда ваше приложение регистрируется на приём push-уведомлений, оно пытается получить токен девайса. Это 32-байтовый уникальный номер, который однозначно определяет ваш девайс. Токен девайса можно сравнить с адресом, на который будут приходить push-уведомления.

После запуска приложения на консоли Xcode отобразиться токен вашего девайса:

My token is: <740f4707 bebcf74f 9b7c25d4 8e335894 5f6aa01d a5ddb387 462c7eaf 61bb78ad>

Токен — это непрозрачная двоичная структура данных, которая представляет собой объект типа NSData. Для наших целей достаточно знать 32-байтовый токен девайса. Токен можно представить в виде 64 шестнадцатеричных символов. Мы будем использовать именно такой формат.

Если запустить приложение на симуляторе, то вызовется метод didFailToRegisterForRemoteNotificationsWithError:, который выведет ошибку с информацией о том, что симулятор не поддерживает push-уведомления.

Мы закончили с приложением. Теперь давайте опробуем push-уведомления в действии!

Отправка push-уведомления

Как было описано ранее, для отправки push-уведомлений необходимо настроить сервер. Но для тестирования воспользуемся приложением для Mac OS PushMeBaby, которое также можно скачать с сервиса self.deviceToken = @"564f77d3 c1d06866 77a907d5 31d0450a 9cb552ec 5e2373e5 f2cc2c20 ff013232";

Добавляем полезную нагрузку, о которой говорилось ранее (обязательно экранируем кавычки):

И задаём имя добавленного в проект SSL-сертификата:

Теперь запускаем приложение и нажимаем кнопку Push. В течении нескольких секунд вы должны получить push-уведомление.

Со стилем «Баннер» push-уведомление выглядит следующим образом:

Со стилем «Напоминание» более привычно:

Замечание. Уведомление не отобразится, если приложение запущено и активно на девайсе. Однако полезная нагрузка придёт в приложение и её можно обработать с помощью метода didReceiveRemoteNotification:

На этом всё. Все интересующие вас вопросы можно задать в комментариях; я постараюсь на них ответить.

Читайте также: