Push уведомления в Android. Грабли, костыли и велосипеды
На написание данной статьи меня подтолкнула задача, которая была поставлена передо мной в одном из рабочих проектов: реализовать Push-уведомления в приложении. Казалось, все просто: штудируешь документацию, примеры и вперед. К тому же, опыт работы с уведомлениями уже был. Но не тут то было…
Сервис, в рамках которого реализовано приложение под Android, предъявляет довольно жесткие требования к работе Push-уведомлений. Необходимо в пределах 30-60 секунд оповестить пользователя о некотором действии. При успешном оповещении с устройства пользователя отправляется запрос на сервер с соответствующим статусом. Из документации известно, что сервис GCM (Google Cloud Messaging) не гарантирует доставку PUSH-уведомлений на устройства, поэтому в качестве backdoor варианта, при нарушении этих временных рамок, наш сервис уведомляет пользователя с помощью SMS сообщения. Поскольку стоимость SMS сообщения существенно выше чем PUSH-уведомления, необходимо максимально сократить поток SMS сообщений на клиентские устройства.
Проштудировав документацию и прикрутив пуш-уведомления, мы разослали нескольким клиентам первую сборку приложения для теста и стали ждать. Результаты были примерно следующими:
- при активном Wifi соединении все работает идеально: уведомления доставляются, клиенты рады.
- при активном мобильном интернете началось самое веселье.
Некоторые клиенты писали, что испытывают задержки в доставке пушей, либо получали одновременно и PUSH и SMS, что достаточно не практично. Другие писали, что вовсе не получали уведомлений, а только SMS. У третьих, как и у нас на тестовых устройствах, все было ок. Собрав с недовольных клиентов максимально возможную информацию, стали разбираться в проблеме и вывели следующий список ограничений (этот список позже вылился в полноценный FAQ):
- включенный режим Энергосбережения (например, Stamina на устройствах Sony) влияет на работу Push уведомлений;
- у пользователя обязательно должен быть минимум 1 активный Google аккаунт на устройстве;
- необходимо удостовериться в том, что на устройстве установлена актуальная версия приложения “Сервисы Google Play”;
- проверить, не отключены ли уведомления для приложения (галочка на страничке приложения в настройках телефона);
- проверить, не ограничена ли работа фонового режима для приложения (настройка расположена в меню «Использование данных»);
- в документации к GCM указано, что уведомления рассылаются только по определенным портам, поэтому настройки роутера, файервола и антивируса так же стоит учитывать.
Разослав данную памятку по всем клиентам, мы снова стали ждать результатов. И они оказались снова «не очень». Стали копать дальше.
На данном этапе очень сильно помогла статья, написанная ребятами из Mail.ru. В ней очень подробно описаны тонкости реализации GCM на клиентской стороне, а так же моменты, в связи с которыми отказываются работать Push уведомления в мобильных сетях. В конечном счете было принято решение о том, чтобы держать свое соединение с сервером в связке с GCM.
Перед тем, как приступить к решению, стоить выделить несколько очень важных моментов, которые позволяют сузить круг потенциально «нерабочих» устройств:
- проблема возникает только при подключении к мобильному интернету;
- по данным клиентов, проблема возникает на версии андроида 4 и выше.
И так, перейдем к реализации.
Бывалый разработчик под Android сходу скажет, что решений задачи как минимум 2: использовать Service или AlarmManager. Мы попробовали оба варианта. Рассмотрим первый из них.
Для того, чтобы создать неубиваемый системой сервис, который постоянно будет висеть в фоне и выполнять нашу задачу, мы использовали метод:
- notificationId — некоторый уникальный идентификатор уведомления, который будет выведен в статус баре и в выезжающей шторке;
- notification — само уведомление.
В данном случае обязательным условием является отображение уведомления в статус баре. Такой подход гарантирует то, что сервису будет дан больший приоритет (поскольку он взаимодействует с UI частью системы) в момент нехватки памяти на устройстве и система будет выгружать его одним из последних. Нам это уведомление не нужно, поэтому мы воспользовались следующим велосипедом: достаточно запустить одновременно с первым сервисом второй и для обоих сервисов в качестве notificationID использовать одно и тоже значение. Затем убить второй сервис. При этом уведомление пропадет из статус бара, но функциональные и приоритетные возможности первого сервиса останутся.
Реализовав данный подход, мы отправили сборку на тест. По результатам выяснилось, что система все-таки выгружает сервис, а по логам мы видели, как происходили существенные временные разрывы при запросе данных в фоне с нашего сервера. Поэтому приступили к реализации второго варианта — AlarmManager.
AlarmManager — это класс, который предоставляет работу с, грубо говоря, «будильником». Он позволяет указать время, по достижении которого система отправит широковещательное уведомление, которое позволит пробудить наше приложение и даст ему возможность выполнить необходимые действия. В работе этого метода есть некоторые ограничения, и их необходимо обработать:
- данные о «будильниках» будут стерты после перезагрузки устройства;
- данные о «будильниках» будут стерты после обновления приложения.
Первыми граблями, на которые мы наступили, был метод
который позволяет установить повторяющийся с некоторым интервалом «будильник». Прикрутив данный способ, стали тестировать, и тесты показали обратное — «будильник» не повторялся. Стали разбираться в чем дело, посмотрели документацию. И именно там нашли ответ на вопрос — начиная с 19 API lvl (Kitkat) абсолютно все «будильники» в системе стали разовыми. Вывод — всегда читайте документацию.
Эти грабли не были поводом для расстройства, ведь решение задачи довольно простое — запускать единоразовый «будильник» и после срабатывания переустанавливать его. При реализации этого подхода мы наткнулись на следующие грабли — оказалось, что для разных уровней API необходимо по разному устанавливать будильники, при этом в документации ничего сказано не было. Но данная проблема решилась достаточно просто — методом «тыка» и «гугления». Ниже представлен пример кода, позволяющий правильно устанавливать «будильники»:
Хочу обратить внимание на флаг AlarmManager.RTC_WAKEUP — именно с помощью него система позволит нашему приложению «проснуться» при неактивном экране, когда устройство находится в заблокированном состоянии.
Данный подход с «будильникам» дал нам нужный результат — приложение в фоне корректно опрашивает сервер на наличие новых данных. Сейчас мы дорабатываем алгоритм. На данный момент реализуем и тестируем следующую оптимизацию, которая позволит сузить круг устройств и тем самым уменьшить нагрузку на сервер:
- в сообщении, отправленном средствами GCM на устройство, содержится некоторый уникальный ID;
- получив данные GET запросом в фоновом режиме проверяем, существуют ли уже запись с таким ID на устройстве;
- если локально на устройстве таких данных нет, мы запоминаем этот ID и время его получения T1;
- ждем PUSH с таким же ID, при получении запоминаем время T2 и проверяем разницу между T2 и T1;
- если разница составляет больше некоторого временного критерия (значения), то на устройстве наблюдается проблема с доставкой уведомлений и для корректной работы сервиса необходимо постоянно запрашивать данные в фоновом режиме с сервера (критерий советую выбирать исходя из решаемой задачи. В нашем случае, был выбран критерий равный 5 минутам);
- данную разницу стоит вычислять несколько раз, например 5-10 раз, только после этого делать вывод о том, что устройство действительно содержит проблему с получением Push уведомлений (таким образом исключается ситуация банального разрыва соединения, таймаута и пр.);
- необходимо прогонять данный алгоритм периодически (например, раз в неделю, или после обновления ОС на устройстве).
Всем добра. И поменьше подобных костылей.
Источник
Основы успешной реализации push-уведомлений для мобильных приложений
Наши разработчики в Techmas часто сталкиваются с задачами создания уведомлений (push notifications). Несмотря на простоту и популярность технологии, в её реализации есть ряд особенностей, о которых и пойдёт речь в этой статье.
Push-сообщения могут стать великолепным маркетинговым инструментом, если они грамотно реализованы. Любое мобильное приложение или игра должны выполнять не только свои прямые функции, но и (даже в большей степени) так взаимодействовать с пользователями, чтобы последние с удовольствием возвращались в приложение и покупали дополнения к нему. К слову, по статистике сервиса Kahuna хорошо разработанные push-уведомления увеличили показатель возвратов пользователей в приложения более чем в 2 раза. Анализируемые периоды: 30, 60, 90 дней. Но прежде, чем говорить о грамотной реализации, посмотрим, как работают push-уведомления.
Общие сведения о технологии Push Notification
Push-уведомления – это такой способ распространения контента (системных сообщений), когда уведомления отправляются от сервера клиенту по инициативе сервера на основе определённых параметров. В отличие от обратной схемы «клиент-сервер» (Pull), push-технология выгодна тем, что даёт пользователю таргетированную информацию, которая может быть ему полезна, но об этой пользе он может пока не знать.
Изначально технология Push Notification имела отношение не к мобильным приложениям, а к сети PointCast, занимавшейся рассылкой новостей фондового рынка. Эту же систему давно используют суды США для рассылки подписчикам данных о процессах. Позже Microsoft и Netscape включили технологию в свои браузеры, но из-за низкой скорости подключения пользователей в то время она была вытеснена pull-технологией RSS. И лишь потом термин получил широкую известность после внедрения технологии компанией Google в ОС Android (Google Cloud Messaging, GCM) и компанией Apple в iOS 3 (Apple Push Notification Service, APNS). На примере последнего рассмотрим элементарную схему работы Push-уведомлений.
Схема работы Push Notification на примере сервиса APNS
Важно знать! Для того, чтобы уведомление отобразилось на экране устройства, само приложение не обязательно должно быть запущено – именно для реализации этого преимущества посредником здесь выступает OS. Кстати, такой подход позволяет экономить и заряд батареи смартфона (телефона), и трафик.
- Для получения Push-сообщений OS должна зарегистрировать мобильное приложение;
- OS запрашивает у APNS идентификатор устройства (токен);
- Приложение получает токен от сервера APNS;
- Приложение отправляет токен обратно на сервер, чтобы далее сервер пользовался им для отправки Push-уведомлений;
- При наступлении события, определённого разработчиком, сервер, используя токены, отправляет Push-сообщения через APNS;
- APNS делает рассылку уведомлений в приложение.
Зачем нужны промежуточные сервисы
Существуют нюансы в рассылках push-уведомлений для разных мобильных платформ (Android, iOS, Windows Phone). Допустим, если приложение было удалено пользователем, то все сервисы сообщают о том, на какие устройства не следует больше отсылать уведомления. Осуществляется данный процесс посредством сообщения серверу токенов этих устройств. Однако если у GCM отсылка идентификаторов происходит сразу, то у APNS имеется специальный feedback server (сервер обратной связи), с которого список таких токенов забирается раз в сутки. Для рутинной работы с этими различиями и нужны промежуточные сервисы.
В случае разработки мобильного приложения с помощью какого-либо кроссплатформенного решения (к примеру, Appcelerator) такой промежуточный сервис, как правило, интегрирован в него. Допустим, в том же Appcelerator это Appcelerator Cloud Services (ACS), представляющий собой дополнительный сервис каналов уведомлений. Такой канал (channel) объединяет несколько устройств, являясь своеобразным идентификатором, состоящим из цифр и букв. ACS даёт возможность отправлять пуши и по токену устройств. Итак, данный промежуточный сервис берёт на себя функцию обновления информации об устройствах и взаимодействует с APNS и GCM.
Схема такого взаимодействия выглядит так:
- При разработке мобильного приложения в него внедряется ключ, который выдаёт ACS;
- Любое уведомление является словарём формата JSON, состоящим из токена девайса, некоторой служебной информации и полезной нагрузки. Полезная нагрузка (payload) – это сами данные, которые отправляются на телефон.
- Сервер, пользуясь ключом:
- получает список каналов и устройств, подписанных на каналы;
- подписывает (и отписывает) устройства на определённые канал;
- отправляет push-уведомления на все устройства или только по определённым токенам или каналам устройств.
- Устройства, в зависимости от их операционной системы, получают push-сообщения от GCM или APNS.
Форма подписки. Современный пользователь не любит навязчивости. По этой причине лучше не показывать диалоговое окно подписки на уведомления во время старта приложения, потому что пользователь ещё не знает, будут ли ему интересны ваши рассылки. Хорошо, если форма подписки на пуш о, например, новых ценах на товары появляется лишь тогда, когда пользователь активирует подписку на интересные ему лоты или направления. Либо выражает согласие на получение пуш-уведомлений в настройках приложения.
Форма уведомления. Сразу выдавайте интересную информацию, лучше в заголовке. Одинаковые пуши вида «Новые распродажи в нашем магазине» не работают: дайте конкретику. Неплохо также использовать Deep Linking (указывать в сообщение внешние ссылки на конкретную страницу сайта).
Гибкая настройка. Чем более детальна настройка того, о чём именно в рамках вашего продукта хочет получать сообщение пользователь, тем лучшее. Персонализированные рассылки всегда имеют больший отклик. Позвольте пользователю настроить уведомления так, как ему интересно и удобно, с максимумом подробностей.
Интерес пользователя. Сообщайте пользователю о том, что он хочет услышать, а не о том, что вы хотите ему рассказать. Для этого нужно собирать информацию о том, что интересно пользователю. Простой пуш о новом ресторане от городского гида не сравнится с пушем о новом ресторане в том районе, где живёт пользователь с информацией об утренних скидках – ведь он часто завтракает в кафе. Аналитика и ещё раз аналитика.
Статистика. Её нужно собирать, чтобы понять: когда эффективней рассылать сообщения; какие типы уведомлений эффективней; насколько те, кто получают ваши пуши, чаще заходят в приложение, чем те, кто не подписан; сколько пользователей открыли приложение по тому или иному пушу; другие виды анализа поведения пользователей.
Тестирование. Используйте разные формы подписки, тексты уведомлений, время рассылки и общую push-стратегию. Следите за отзывами в сети – это даст вам богатую информацию о том, как улучшить рассылку.
Звук уведомлений. Настройте свой, неповторимый. Чтобы пользователь знал, что новое сообщение пришло именно от вашего приложения. Не делайте его раздражающим – сделайте комфортным.
Сервисы автоматизации Push-рассылки
Push Woosh. Выдаёт удобные и понятные отчёты, совместим со многими платформами, отлично сегментирует аудиторию по разным группам признаков.
Urban Airship. Осуществляет таргетинг и анализ аудитории, позволяет выбирать различные стратегии удержания пользователя и создавать уведомления расширенного формата.
Appsfire`s Appbooster. Бесплатный сервис со стандартным набором функций.
Parse Push. Позволяет собирать уникальные данные для аналитики, с лёгкостью интегрируется в любое приложение.
В заключение отметим, что push-уведомления, конечно, являют собой простой и эффективный способ возврата и удержания пользователя в частности и мощный маркетинговый инструмент в целом. Но это с точки зрения пользователя. Со стороны разработчика же существуют некоторые сложности. Реализация уведомлений сильно зависит от внешних вводных: изменения в OS или в промежуточном софте приводит к необходимости доработки приложения. Так, в Appcelerator появился новый инструмент Arrow Push, который пришел на смену ACS – и это лишь один из примеров. Более того, доставка пуша не гарантирована в принципе, а это поднимает вопрос о надёжности технологии Push Notification. Однако любая технология имеет свои плюсы и минусы, и что перевешивает в данном случае – вопрос открытый.
Источник
