В предыдущей статье мы рассмотрели, как настроить Google Cloud Messaging (GCM) в приложениях Android. Мы узнали, что GCM — это бесплатный сервис, который позволяет передавать сообщения из облака ряду мобильных получателей, работающих с нашим приложением Android и зарегистрированных в нашем сервисе.
Push-сообщения могут быть как разборными, так и неразборчивыми . «Разборный» означает, что самое последнее сообщение перезаписывает все предыдущие, поставленные в очередь на отправку. Типичным примером разборчивого обмена сообщениями является живой игровой счет. Если предыдущие обновления результатов еще не достигли пункта назначения, клиенты Android получат только последнее. Это происходит, однако, с максимальной отдачей : порядок, в котором сообщения отправляются в GCM, не гарантируется , поэтому в некоторых случаях «последнее» сообщение может быть не самым последним.
Возьмем в качестве примера игру в бейсбол между Бостон Ред Сокс и Нью-Йорк Янкиз. Вот как мы можем создать разборное обновление для отправки на устройства, зарегистрированные в нашей службе спортивных push-уведомлений . Все примеры кода здесь являются небольшими модификациями демонстрационного приложения GCM . Как отмечалось в предыдущей статье, читателю предлагается загрузить демоверсию (как клиента, так и сервера) и поэкспериментировать. Демонстрация использует вспомогательную библиотеку GCM для Java, которая абстрагирует большую часть низкоуровневого содержимого (например, обработка сообщений в формате JSON ).
Тем не менее, хотя демо-версия довольно полезна для внедрения GCM, на самом деле она не обрабатывает push-контент. Он только запускает и подтверждает событие, в то время как одно и то же уведомление (настроенное в конфигурации клиента) используется во всех случаях («Из GCM: вы получили сообщение!»). Итак, давайте напишем некоторый фактический код отправки и получения сообщений:
Код сервера
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
// in importsimport com.google.android.gcm.server.Message;// Inside send method, construct a collapsible messageMessage message = new Message.Builder() .collapseKey("Fenway Park Game") // The key for all updates. .timeToLive(600) // Time in seconds to keep message queued if device offline. .delayWhileIdle(true) // Wait for device to become active before sending. .addData("team1", "Red Sox:1") .addData("team2", "Yankees:0") .build();// send in chunks of 1,000 devices//... |
Стоит отметить, что данное сообщение GCM может быть отправлено до 1000 мобильных клиентов одновременно. В случае, если наша пользовательская база будет больше, нам нужно будет разбить процесс отправки сообщений на 1000 получателей. Один из способов сделать это — использовать пул потоков java.util.concurrent.Executor и асинхронно отправлять порции, как это делает демонстрационный сервер GCM.
Код клиента
Теперь нам нужно обработать сообщение GCM в нашем приложении Android:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
// inside GCMIntentService@Overrideprotected void onMessage(Context context, Intent intent) { String message = intent.getStringExtra("collapse_key") + "\n" + intent.getStringExtra("team1") + " " + intent.getStringExtra("team2"); displayMessage(context, message); // notify user generateNotification(context, message);} |
Обратите внимание на то, как сервер collapse_key устанавливается и извлекается клиентом. Этот ключ — то, как GCM идентифицирует поток свертываемых обновлений для данного события. Если в очереди на отправку имеется несколько push-уведомлений с одним и тем же ключом сброса «Fenway Park Game», будет доставлено только самое последнее.
Вот как выглядит push-уведомление выше на реальном устройстве Android. Последний экран — это открытое приложение GCMClient, превращенное в «Спортивный центр» для демонстрационных целей:
Мы можем понять, почему складной толчок имеет смысл: давайте предположим, что мы использовали неразборные сообщения, и счет обновлялся, скажем, еще 4 раза в течение игры. Давайте представим себе частый случай, когда некоторые из наших пользователей не получили первые уведомления и снова стали доступными сразу после получения последней оценки. Тогда они получат все пять сообщений, а не только последнее. Все сообщения, кроме самого последнего, были бы бесполезны, и мы бы переоценили этих клиентов. Это было бы не очень умно. Мы хотим, чтобы наше приложение было полезным, а не раздражающим. Как уже упоминалось, складные сообщения не гарантированно доставляются по назначению по порядку, но они все же позволяют нам использовать GCM разумно и воздерживаться от слишком … настойчивых действий.