Push токены что это
Внедряем кросс-платформенные пуш-уведомления: начало
Добрый день! Меня зовут Владимир Столяров, я бэкенд-разработчик в команде Клиентские коммуникации в ДомКлике. В этой статье я расскажу о том, как внедрить кросс-платформенные пуш-уведомления. Хотя про это уже написано немало, я бы хотел рассказать о некоторых нюансах, с которыми нам пришлось столкнуться в процессе внедрения. Для лучшего понимания происходящего также напишем с вами небольшое веб-приложение, способное принимать пуши.
Для начала нужно понять, куда мы вообще хотим отправлять пуши. В нашем случае это веб-сайт, iOS-приложение и Android-приложение.
Начнем с веб-пушей. Для их получения браузер подключается к своему пуш-серверу, идентифицируется и принимает уведомления в сервис-воркер (в нем срабатывает событие push ). Нюанс тут в том, что у каждого браузера пуш-сервис свой:
Хорошая новость для нас в том, что веб-пуши стандартизированы IETF (https://datatracker.ietf.org/wg/webpush/documents/), и поддерживать разные форматы API для каждого браузера как на клиенте, так и на сервере нам не придется.
Теперь рассмотрим устройства на базе Android. Здесь есть несколько вариантов:
Далее идет iOS. В отличие от Android, способ отправить уведомления на устройства Apple всего один — использовать Apple Push Notification service (APNs).
Может возникнуть логичный вопрос: неужели придется поддерживать всё это многообразие стандартов, API и прочего на серверной стороне? На самом деле, всё не так уж и плохо, так как Firebase Cloud Messaging, помимо отправки на Android, покрывает еще и веб-пуши и работает с APNs. Так мы пришли к следующей схеме: на устройства Huawei без Google Apps отправляем через Huawei Push Kit, в остальных случаях пользуемся Firebase Cloud Messaging.
Несмотря на многообразие стандартов и сервисов, схема работы будет примерно одинаковой:
Попробуем написать тестовое приложение
Для начала просто получим пуш-токен от Firebase и попробуем отправить пуш. Нужно зарегистрировать проект в консоли Firebase и получить конфигурацию для веб-приложения. Для корректного функционирования будет нужен локальный HTTP-сервер с передачей статики.
Сделаем страницу с одной кнопкой и необходимыми скриптами:
Открываем страницу, нажимаем на кнопку, разрешаем уведомления в браузере и копируем отображенный токен. Для удобства работы с API вручную можно создать долговременный ключ сервера (не сервисный аккаунт). Делаем простой запрос:
Тут есть важный момент, о котором можно забыть: пуш-токен никак не связан с пользователем приложения, он связан с конкретным получателем (т.е. с клиентской конфигурацией). На мобильных устройствах он связан с конкретной инсталляцией приложения.
Открываем консоль сервис-воркера, снова отправляем пуш… и ничего не видим в консоли, хотя уведомление отобразилось. Почему же? Ответ в есть в документации:
Note: If you set notification fields in your message payload, your setBackgroundMessageHandler callback is not called, and instead the SDK displays a notification based on your payload.
В нашем случае в запросе есть поле notification и данный колбэк не вызывается. Это довольно важное замечание, к нему мы вернемся дальше.
Тем не менее, можно это обойти, обрабатывая входящие пуши вручную. Поменяем содержимое firebase-messaging-sw.js :
Теперь добавим пользователей в наше приложение
Для удобства заведем новую страницу:
Нам понадобится простенький бэкенд, писать будем на Go. Тут приведу только пример кода, отвечающего за хранилище токенов:
В бэкенд также добавлен код отправки пушей конкретному пользователю.
Базово мы обеспечиваем следующую функциональность:
Опишу несколько важных моментов, на которые мы наткнулись уже на практике (они отражены в примере):
И вот, грабли собраны, доработки выложены в прод. Пуши ходят… или не ходят? Самое время поговорить про
Надежность
Никаких методов подтверждения доставки от клиента серверу приложений изначально не предусмотрено, хотя в Huawei над этим задумались и сделали. Поэтому нам придется реализовывать эту функциональность самим. Первое, что приходит в голову — отправлять на сервер HTTP-запрос при получении пуша. Для этого нам потребуется идентифицировать каждый пуш, благо и Firebase, и Huawei это позволяют: можно пробросить произвольные данные при отправке уведомления.
Идея следующая: мы генерируем одноразовый токен подтверждения (в нашем случае это просто UUID) и отправляем его в пуше. Клиент при получении и показе пуша делает HTTP-запрос, в который включается присланный токен подтверждения. Немного дорабатываем бекенд и firebase-messaging-sw.js :
Для APNs же достаточно просто выставить mutable-content в 1, и тогда при обработке пуша можно будет выполнять некоторый код, но с довольно серьезными ограничениями, хотя этого вполне достаточно для простого HTTP-запроса. Собственно, именно из-за ограничений iOS при подтверждении пуша не задействуется пользовательская сессия, а используются одноразовые токены.
Отсюда вытекает еще одна интересная особенность: data-пуши можно использовать не только для уведомлений пользователя, но и для доставки какой-либо информации, настроек и прочего в приложение. Примерно таким способом, например, Telegram обходил блокировки, отправляя адреса серверов через пуши.
Мы же используем механизм подтверждения следующим образом: для некоторых типов уведомлений, если не дождались подтверждения через, скажем, 15 минут после отправки, отправляется смс. А чтобы исключить случай, когда после смс приходит пуш, можно выставить TTL при его отправке.
Также этот механизм позволяет нам собирать статистику по доставляемости. Исходя из собранных данных, доставляемость пушей по платформам получается примерно следующей:
Для Huawei достаточное количество данных еще не накоплено. Следует сказать о том, что мы не предпринимали никаких действий по увеличению доли доставленных пушей, как это сделали, например, в Яндекс.Почте.
Итоговая архитектура получается примерно такой:
Полную версию проекта можно взять на GitHub.
В следующих частях я планирую рассказать о дополнительных возможностях, предоставляемых пуш-сервисами, более детально о подводных камнях на клиентских платформах, а также о том, как можно принимать веб-пуши, не используя браузер.
Push в общей системе маркетинговых коммуникаций
Перед вами глубокий и разносторонний обзор пуш-уведомлений как одного из маркетинговых каналов. Вы узнаете, как настроить пуш-рассылку, как объединить ее с другими маркетинговыми каналами, какой контент лучше для мобильных пушей, а какой — для десктопных. И многое-многое другое.
Статью подготовила Галина Панасюк — Head of CRM Busfor.ua. У Галины за плечами огромный опыт работы с пуш-уведомлениями, а главное — впечатляющие результаты их использования.
Сбор токенов, первичная сегментация и основные метрики для базы
Только размышляете над запуском пуш-рассылок? Этот раздел — для вас!
Создание проекта в Firebase
Веб-Push — это браузерные сообщения, которые настраиваются в системе Firebase.
Если вы хотите делать пуш-рассылки, прежде всего вам нужно создать собственный проект в Firebase и сгенерировать ключ. Это нужно для того, чтобы у вас всегда была возможность перенести базу контактов в другой сервис рассылок.
Например, когда компания BUSFOR переходила в eSputnik, у нее уже был собственный проект в Firebase, благодаря чему около 80% базы токенов удалось сохранить. Если проект создает сервис рассылки, перенести из него контактную базу скорее всего не получится.
Идентификация контактов
Идентификатор пуш-уведомления — это токен устройства. Токен — не персональная информация, если он не связан с емейлом или какими-либо другими персональными данными клиента.
У каждого устройства, с которого пользователь подпишется на пуш-рассылку, уникальный токен.
Срок жизни токена — от 14 дней до года, в зависимости от устройства и поведения пользователя: например, токен меняется при обновлении браузера.
Выбор сервиса
Существует 2 основных типа сервисов рассылки пуш-уведомлений.
Sendpulse, Flocktory, eSputnik и др. Здесь главный плюс — интеграция с другими маркетинговыми каналами (email, SMS, Viber, mobile push) и возможность использовать данные о поведении пользователей на сайте и в рассылке. Обычно минус таких сервисов — более слабая сегментация и статистика по пуш-уведомлениям. Но это не распространяется на eSputnik — этот ESP отличается тем, что предлагает кастомные решения, так что не уступает даже сервисам, специализирующимся на рассылке только пуш-уведомлений.
Виды подписки
Чтобы запускать рассылки, вам нужно получить от клиента разрешение отправлять ему уведомления. Это происходит в браузерном окне подписки.
Браузерная подписка — стандартная, она происходит в один клик. Здесь вы не сможете ни вставить картинку, ни даже поменять цвет или форму кнопок. Язык уведомления зависит от языка браузера пользователя.
Единственное, что можно регулировать в уведомлениях с предложением подписки — это страницы сайта, на которых они показываются.
Мы рекомендуем ставить такое уведомление на страницу входа. На других страницах оно может отвлекать и раздражать пользователей. Особенно опасно ставить уведомления с предложением подписаться на страницы оформления заказа — пользователь может подумать, что разрешает платеж. Если он уже готов платить — не мешайте ему 🙂
Вы можете кастомизировать подписку, сделав ее в два клика. Тогда посетитель сайта сначала увидит ваше кастомное предложение подписаться:
Если пользователь согласится, то после этого покажется стандартное окно:
У подписки в два клика есть свои плюсы и минусы: конверсия по сравнению с подпиской в один клик может уменьшаться на 15-40%, зато подписываются только действительно заинтересованные пользователи. Таким образом, вы будете платить меньше, отправляя пуши только тем, кому они действительно нужны. Кроме того, уменьшатся жалобы на спам.
Нужно отметить, что пуши приводят на сайт огромный трафик, который может занимать третье место в разрезе всех посещений сайта. Но он сложно монетизируется: пуши не столько продающий инструмент, сколько инструмент для расширения охвата, для создания быстрого трафика.
Данные для первичной сегментации
Автоматизация, разработка гипотез и роль канала в общей структуре трафика
Если для старта рассылки всё готово — сделаем ее максимально эффективной!
Автоматизация
Возможности автоматизации пуш-рассылок, которые подходит практически любому типу бизнеса — триггерные сценарии, welcome- и retention-серии.
Триггерные пуши, плюсы
Прежде всего стоит включить пуши во все триггерные цепочки. Конечно, для этого токены должны быть сматчены с емейлом и другими данными пользователей. Например, если клиент забыл товар в корзине, можно сначала напомнить об этом пуш-уведомлением, и тем самым сэкономить на емейле. И только если пользователь не отреагирует, запускать более дорогостоящие каналы.
Способы обогащения данных из пушей:
При всех этих вариантах ESP сможет собрать токен, емейл, ID и другие полученные данные вокруг одного контакта, чтобы впоследствии вести с ним омниканальную коммуникацию.
Настроить омниканальные рассылки
Welcome-серия, плюсы:
Welcome-цепочка в пушах может быть такой же интересной и эффективной, как и в email. Вы знакомите подписчика со своим бизнесом, делитесь ссылками на самые интересные материалы и акции. Но нужно помнить о том, что пуш-сообщение может увести пользователя со страницы. Поэтому лучше всего отправлять первый велком-пуш уже после того, как пользователь уйдет с вашего сайта. Например, если среднее время посещения вашего сайта 10 минут, настройте старт велком-цепочки на 15 минут после подписки.
Retention-серия, плюсы:
Реакция пользователей на retention-сообщения показывает динамику отмирания контактов, как на мобильных, так и на десктопных устройствах. По показателям доставляемости и открываемости можно понять, с какой частью контактов стоит продолжать работать, и какую часть пора удалять.
Построение гипотез
Наблюдения за результатами рассылок позволяют построить ряд гипотез, на основании которых можно оптимизировать стратегию. На что стоит обратить внимание?
Разное поведение с разных устройств
Если мы говорим о пушах в мобильных браузерах, нужно помнить, что параллельно с ними человек получает множество уведомлений из своих приложений. Таким образом, мобильные пуши часто просто теряются в массе других уведомлений. К тому же некоторые недобросовестные сервисы попросту продают базы токенов. В результате человек, подписавшийся на новостной сайт, вдруг начинает получать пуши от онлайн-казино.
Все это приводит к тому, что отписки с мобильных устройств происходят гораздо чаще.
Еще одно отличие мобильных и десктопных пушей — внешний вид. В десктоп-формате обычно это кнопка, текст и картинка.
А на мобильной версии картинка может обрезаться в зависимости от мобильного устройства. Поэтому мы советуем вообще не вставлять картинки в мобильную версию пушей.
Разное поведение с разными посадочными страницами
Анализируя конверсии пушей, не забывайте анализировать качество посадочных страниц.
Главная цель пуш-уведомления — привести пользователя на лендинг. Дальнейшая монетизация зависит уже непосредственно от качества этой страницы: ее дизайна, адаптированности под мобильные, четкости формулировки предложения и т.п.
Влияние дополнительных элементов
С кнопками и картинками в веб-пушах стоит поэкспериментировать. Наш опыт говорит о том, что чем больше в сообщении кликабельных элементов, тем больше переходов. Проверьте, так ли это и для вашего бизнеса.
Время отправки и время жизни сообщения
Время отправки необходимо тестировать — оно должно совпасть со временем пребывания в интернете ваших подписчиков. Плюс веб-пушей в том, что вы можете установить им время жизни (TTL). Это время, в течение которого они могут показываться пользователям.
Например, вы отправили сообщение в 15.00 и установили время жизни 5 часов, потому что в 20.00 акция, которую рекламирует пуш, закончится. Тогда все ваши получатели, которые в течение этих 5-ти часов откроют браузер, сразу получат это уведомление, после чего оно перестанет показываться.
Нужно помнить, что чем короче TTL, тем, соответственно, меньше будет доставляемость. Поэтому для постоянных акций лучше ставить максимальный TTL. И не забывайте указывать дату в метках сообщения, чтобы понимать, откуда пришла конверсия.
Влияние предложения
Тестируйте разные варианты предложений: может оказаться, что скидка в 5% и 6% дает очень разные результаты.
Задачи канала
Условно можно выделить три главных задачи пушей:
1) Быстрый трафик на посадочную
Основная задача пушей — нагнать быстрый трафик на посадочную страницу.
Тут вспоминается забавный кейс компании Bosfor.ua. Чтобы получить народную премию, подписчиков в пуше попросили голосовать за компанию. Сайт народной премии просто лёг, т.к. одновременно на него перешли тысячи сторонников Босфора. Подумайте, выдержит ли ваш сайт возможный трафик из пушей?
2) Продвижение новых страниц
Поисковый робот видит, что множество людей вдруг зашло на новую страницу — это положительно сказывается на рейтинге ее показа.
3) Источник бесплатных установок приложения
Если у вас есть мобильное приложение, добавьте в welcome-цепочку для мобильных устройств пуш с предложением установить его. Вы можете сразу таргетировать пуши по устройствам: Android или IOS. Велком-цепочку получают свежие, лояльные клиенты, которые зачастую очень хорошо реагируют на такое предложение.
Актуализация состояния базы и оптимизация всех этапов воронки
Стандартная воронка пуш-уведомления состоит из таких этапов:
Средняя статистика такова — от 100% отправленных:
Как очистить контактную базу
Выделите группы контактов, которые неактивны на определенный день после регистрации. Обычно 80% неактивны на 35-й день. Отправьте этому сегменту экспериментальное уведомление — измените контент, время отправки и т.д. Удалите из базы все токены, владельцы которых не отреагировали на это уведомление.
То же можно сделать не по сроку жизни, а по количеству уведомлений, полученных контактом: если он получил N уведомлений (допустим, 100), но открытий не было, отправляем экспериментальный пуш, если результата нет — удаляем его из базы.
“Битые”, изначально неправильные токены удаляются в eSputnik автоматически. Если вы будете пользоваться другим сервисом, не забывайте чистить базу и от таких токенов.
Коротко о главном
eSputnik — сервис, который поможет справиться с этими и многими другими задачами. Присоединяйтесь к нам 🙂
Актуализация токенов: как работают push-кампании в AppMetrica
В настройках push-уведомлений AppMetrica появилась одна полезная галочка:
Рассказываем, зачем она нужна и как работает.
Зачем актуализировать токены?
Чтобы отправить пользователю push, нам нужен его уникальный идентификатор — push-токен. Он выдаётся сервисом операционной системы: Apple Push Notifications Service (APNS) в iOS и Firebase Cloud Messaging (FCM) в Android.
AppMetrica Push SDK получает токен устройства и отправляет его на наш сервер, чтобы потом использовать в рассылке.
Как работает AppMetrica Push
Если пользователь долго не запускал приложение, APNS или FCM отзывает его токен. Поскольку токен, который мы храним на сервере, становится невалидным, AppMetrica не сможет доставить пользователю сообщение.
Чтобы решить проблему, мы научились актуализировать push-токены. Поставьте галочку в настройках приложения, и AppMetirca станет автоматически перезапрашивать токен раз в день, посредством silent push. Silent push не побеспокоит пользователя: он не появится в панели уведомлений и обработается в фоновом режиме.
Как настроить silent push в приложении?
В iOS не нужно производить дополнительных настроек. Всё заработает автоматически.
В Android убедитесь, что приложение корректно обрабатывает этот формат сообщений. В противном случае, пользователи могут получить не silent push, а самый обычный: он появится в панели уведомлений аудитория окажется в замешательстве.
Актуализация push-токенов делает кампании эффективнее, ведь теперь в них попадает больше пользователей.
Если для эффективной работы с AppMetrica вам не хватает какой-то функции, опишите идею на нашей платформе для голосований! Мы обязательно рассмотрим ваше предложение со всех сторон.
Руководство по работе с Apple Push Notification Service
Статья представляет собой вольный перевод руководства по работе с Apple Push Notification Service сайта raywenderlich.com и некоторые мои дополнения.
iOS-приложения не могут долгое время находиться в фоновом режиме. В целях сохранения заряда батареи приложениям, работающим в фоне, разрешено выполнять ограниченный набор действий.
Но что если происходит что-то интересное и вы хотите сообщить об этом пользователям, даже если ваше приложение у них не запущено?
Например, пользователь получил ответ в Твиттере, или его любимая команда выиграла игру, или его обед готов. Так как приложение не запущено, оно не может проверить и получить эти данные.
К счастью, корпорация Apple предусмотрела решение этой проблемы. Вместо того, чтобы беспрерывно проверять события или производить какие-либо действия в фоновом режиме, вы можете создать серверную сторону приложения, которая будет выполнять эти действия.
А когда наступит интересующее событие, серверная сторона сможет отправить приложению push-уведомление! Абсолютно любое push-уведомление может выполнять следующие три действия:
Краткий обзор
Схема работы механизма push-уведомлений:
После установки приложения появится всплывающее сообщение с подтверждением принятия push-уведомлений.
Стоит ли по-прежнему использовать push-уведомления, если уже в iOS 4.0 появились локальные уведомления и мультизадачность? Ещё бы!
Локальные уведомления — это ограниченные по времени события. Только VOIP-приложения, навигация и фоновое воспроизведения звука обладают возможностью неограниченного фонового выполнения. Если необходимо уведомить пользователей приложения (пока оно закрыто) о каком-либо внешнем событии, вы всё ещё должны использовать push-уведомления.
В этом руководстве будет детально описана работа системы push-уведомлений и как её интегрировать в своё приложение.
Что необходимо для push-уведомлений
Для интеграции push-уведомлений в приложение необходимо:
iPhone, iPad или iPod touch. Push-уведомления не работают в симуляторе, поэтому для тестирования нужен девайс.
Регистрация в iOS Developer Program. Для каждого приложения, в котором будет интегрирован механизм push-уведомлений, необходимо создать новый App ID и provisioning profile, а также SSL-сертификат для сервера. Эти действия выполняются на iOS Provisioning Portal.
Если хотите полностью выполнять примеры из этого руководства, вам необходимо создать provisioning profile и SSL-сертификат. Я в деталях объясню, как это сделать.
Для работы с push-уведомлениями дешёвого виртуального хостинга недостаточно. Вам необходимо запустить фоновое выполнение на сервере, установить SSL-сертификат, настроить исходящее TLS-соединение на определённых портах. Большинство провайдеров виртуального хостинга не позволят вам это сделать. Хотя если обратиться в службу технической поддержки, то вам, скорее всего, помогут решить все проблемы. Но всё же я настоятельно рекомендую использовать VPS.
Анатомия push-уведомлений
Ваш сервер ответственный за создание сообщений для push-уведомлений. Поэтому полезно знать, как эти сообщения выглядят.
Push-уведомление — это короткое сообщение, состоящее из токена девайса, полезной нагрузки (payload) и ещё некоторой информации. Полезная нагрузка — это актуальные данные, которые будут отправляться на девайс.
Ваш сервер должен преобразовать полезную нагрузку в JSON-словарь. Полезная нагрузка для простого push-сообщения выглядит следующим образом:
Блок, ограниченный фигурными скобками содержит словарь, который состоит из пар «ключ-значение» (так же, как и в NSDictionary).
Полезная нагрузка — это словарь, который состоит из, по крайней мере, одной пары «ключ-значение» «aps», значение которой само по себе является словарём. В примере выше «aps» содержит два поля: «alert» и «sound». Когда на девайс придёт push-уведомление, отобразится всплывающее сообщение с текстом «Hello, world!» и будет воспроизведён стандартный звуковой сигнал.
Кроме этого, в «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-сертификатов для сервера:
Генерация Certificate Signing Request (CSR)
Помните, как вы заходили на iOS Provisioning Portal и создавали сертификат разработчика (Development Certificate) после присоединения к iOS Developer Program? Следующие шаги будут аналогичными. Но всё же я советую выполнять их в точности, как будет описано ниже. У разработчиков большинство проблем с push-уведомлениями как раз и связано с сертификатами.
Цифровые сертификаты базируются на шифровании с использованием открытого-приватного ключа. Вам нет необходимости знать что-либо о шифровании при работе с сертификатами, но вы должны быть осведомлены в том, что сертификат всегда работает в паре с приватным ключом.
Сертификат — это общая часть этой пары ключей. Приватный ключ должен держаться в секрете. Владеете им только вы и никто другой не должен иметь доступ к нему. Отмечу, что невозможно использовать сертификат без приватного ключа.
Всякий раз когда вы запрашиваете цифровой сертификат, необходимо сделать запрос на его подпись (Certificate Signing Request [CSR]). Когда вы создадите CSR, новый ключ будет занесён в связку ключей (keychain). Затем необходимо отправить CSR в центр сертификации (в этом случае это iOS Developer Portal), который сгенерирует SSL-сертификат на основе информации из CSR.
Откройте утилиту «Связка ключей» («Приложения → Утилиты (Другие)») и выберите опцию «Запросить сертификат у бюро сертификации…».
Если вы не видите этой опции меню или появляется сообщение с текстом «Запросить сертификат у бюро сертификации с ключом» («Request a Certificate from a Certificate Authority with key»), тогда необходимо загрузить и установить WWDR Intermediate Certificate. Также необходимо проверить, чтобы ни один приватный ключ не был выделен.
Сейчас перед вами должно быть окно ассистента сертификации:
Здесь введите 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».
Я заполнил поля следующим образом:
Нажмите «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» и перейдите к следующему шагу.
Я заполнил поля следующим образом:
После создания проекта, откройте PCAppDelegate.m. Измените метод didFinishLaunchingWithOptions следующим образом:
Вызов registerForRemoteNotificationTypes сообщает iOS, что это приложение хочет получать push-уведомления.
Соберите и запустите приложение. Для этого необходимо использовать девайс, потому что симулятор не поддерживает push-уведомления. Xcode автоматически выберет новый provisioning profile. Если во время запуска приложения произошла ошибка, убедитесь, что в Code Signing Identity выбран правильный profile.
Когда запуститься приложение, появится сообщение с подтверждением принятия push-уведомлений.
Приложение запросит разрешение только один раз. Если пользователь нажмёт «OK», push-уведомления будут приходить, если «Запретить» — не будут. Своё решение можно изменить в настройках.
Название вашего приложения будет добавлено в настройки push-уведомлений. Здесь пользователь может включить или отключить push-уведомления для вашего приложения, а также индивидуально настроить бейджи, звуки и сообщения.
Ваше приложение может определить, какие типы push-уведомлений включены:
Существует ещё одна вещь, которую вы должны добавить в приложение для того, чтобы иметь возможность получать push-уведомления. Добавьте следующий код в PCAppDelegate.m:
Когда ваше приложение регистрируется на приём push-уведомлений, оно пытается получить токен девайса. Это 32-байтовый уникальный номер, который однозначно определяет ваш девайс. Токен девайса можно сравнить с адресом, на который будут приходить push-уведомления.
После запуска приложения на консоли Xcode отобразиться токен вашего девайса:
Токен — это непрозрачная двоичная структура данных, которая представляет собой объект типа NSData. Для наших целей достаточно знать 32-байтовый токен девайса. Токен можно представить в виде 64 шестнадцатеричных символов. Мы будем использовать именно такой формат.
Если запустить приложение на симуляторе, то вызовется метод didFailToRegisterForRemoteNotificationsWithError:, который выведет ошибку с информацией о том, что симулятор не поддерживает push-уведомления.
Мы закончили с приложением. Теперь давайте опробуем push-уведомления в действии!
Отправка push-уведомления
Как было описано ранее, для отправки push-уведомлений необходимо настроить сервер. Но для тестирования воспользуемся приложением для Mac OS PushMeBaby, которое также можно скачать с сервиса github.
Далее всё просто — открываем PushMeBaby в Xcode, добавляем в проект ранее созданный SSL-сертификат (aps_development.cer), после чего переходим к редактированию файла ApplicationDelegate.m. В методе init делаем следующие изменения:
Добавляем токен девайса, который отобразится в консоли Xcode после запуска приложения, созданного ранее:
Добавляем полезную нагрузку, о которой говорилось ранее (обязательно экранируем кавычки):
И задаём имя добавленного в проект SSL-сертификата:
Теперь запускаем приложение и нажимаем кнопку Push. В течении нескольких секунд вы должны получить push-уведомление.
Со стилем «Баннер» push-уведомление выглядит следующим образом:
Со стилем «Напоминание» более привычно:
Замечание. Уведомление не отобразится, если приложение запущено и активно на девайсе. Однако полезная нагрузка придёт в приложение и её можно обработать с помощью метода didReceiveRemoteNotification:
На этом всё. Все интересующие вас вопросы можно задать в комментариях; я постараюсь на них ответить.