Реализация push уведомлений при разработке мобильных приложений
Технология Push Notification в мобильных приложениях появилась достаточно давно. В отличие от классической модели «клиент-сервер», она подразумевает отправку сообщений от сервера к клиенту, которую инициирует не клиент, а сервер. Сам клиент же является подписчиком.
Сам термин Push Notification имеет отношение не только к области мобильных приложений. Широкую известность он получил благодаря компании Apple, которая внедрила в iOS 3 технологию Apple Push Notification Service (APNS). Справедливости ради, стоит отметить, что компания Google в ОС Android реализовала такой сервис практически на год раньше.
Ключевое преимущество Push Notification: приложение не обязательно должно быть запущено, чтобы уведомление отобразилось на экране мобильного телефона. Посредником для таких уведомлений является операционная система. Это позволяет экономить как трафик, так и заряд батареи устройства.
Рассмотрим общую схему Push Notification на примере сервиса APNS от компании Apple:
Работа уведомлений на примере APNS выполняется следующим образом:
- Мобильное приложение регистрируется в операционной системе для получения Push уведомлений
- Операционная система запрашивает у APNS токен устройства
- Приложение получает токен устройства от сервера APNS…
- …И отправляет его на сервер. В дальнейшем сервер будет пользоваться этим токеном для отправки уведомлений
- При наступлении определенного разработчиком события сервер отправляет Push-уведомления через APNS, используя токен(ы) устройств(а)
- APNS рассылает уведомления.
Push уведомления для основных мобильных платформ — iOS, Android, Windows Phone — различны в деталях. Так, например, все сервисы сообщают идентификаторы устройств на которые не следует рассылать уведомления (например, если приложение было удалено). Но если сервис компании Google — Google Cloud Messaging (GCM) возвращает идентификаторы таких устройств сразу же, то у APNS существует так называемый сервер обратной связи (feedback server), с которого достаточно один раз в сутки забирать список таких идентификаторов. Таких различий немало, поэтому неудивительно появление промежуточных сервисов, берущих на себя рутинную работу.
Когда же разработка мобильного приложения выполняется с помощью какого-либо кроссплатформенного решения, например, Appcelerator, то подобный промежуточный сервис чаще всего оказывается интегрированным в подобное решение. Для упомянутого выше Appcelerator таким сервисом является Appcelerator Cloud Services — ACS.
ACS предоставляет дополнительный сервис каналов (channels) уведомлений. По сути, канал является буквенно-цифровым идентификатором, объединяющим несколько устройств. Конечно, ACS предоставляет возможность отправлять Push Notification и по токену устройства.
Поскольку ACS берёт на себя рутину по обновлению информации об устройствах и взаимодействии с GCM и APNS, схема взаимодействия уже выглядит иначе.
В разрабатываемое мобильное приложение внедряется ключ, выданный ACS. Сервер, пользуясь этим ключом, может, в частности:
- Получить список каналов и устройств, подписанных на эти каналы;
- Подписать устройства на определенные каналы (как, впрочем, и «отписать» устройства от каналов);
- Отправить Push-уведомления как для всех устройств, так и по определенным каналам или токенам устройств;
- Устройства получают уведомления от соответствующих сервисов (APNS или GCM).
Само уведомление представляет собой JSON-словарь, состоящий из токена девайса, полезной нагрузки (payload) и некоторой служебной информации. Полезная нагрузка — это собственно данные, которые будут отправляться на устройство.
В заключение стоит отметить, что Push Notification, несмотря на всю простоту и удобство, являются всё же ненадёжной технологией, т.к. доставка такого сообщения не гарантирована. Так что если ваша задача – надёжный обмен сообщениями между клиентами или между клиентами и сервером, придётся поискать какой-либо другой способ передачи информации.