Работаем с Google Cloud Messaging

Внимание: эта статья устарела! Гуглы довольно сильно перепилили свой GCM, и теперь всё не так. Но скрипт для отправки тестовых пушей всё ещё работает, поэтому убирать статью я пока не буду и постараюсь найти время её актуализировать.

Мы привыкли писать мобильные приложения, которые обращаются к некоторому API и получают оттуда данные. А ведь бывает и обратная ситуация: отправку данных клиенту может инициировать сам сервер. Обычно это используется для так называемых Push-нотификаций.

Мне известны два способа реализации Push-нотификаций. Во-первых это Google Cloud Messaging (бывший C2DM), во-вторых Urban Airship. Про последний я почти ничего не знаю (кроме отзывов коллеги о том, что использование его сильно сажает батарейку на телефоне). А про GCM пойдет речь в посте.

Вкратце процесс выглядит так:

Есть клиентское приложение, серверная часть и облачный сервис Google.

1. Клиент регистрируется в облачном сервисе Google, получает токен
2. Токен отправляется серверу
3. Сервер, когда ему нужно, отправляет облаку запрос с этим токеном и какими-то данным
4. Между облаком и девайсом происходит гугловая магия
5. Клиенту приходит Intent с данными, которые отправил сервер.
6. Клиент поступает с данными, как считает нужным (например, показывает нотификацию)

Я расскажу о своем опыте использования этой технологии и выложу рабочий пример.

Моя практика логгирования в Android

Я люблю логи, считаю их лучшим инструментом отладки, чем дебаггер и стараюсь использовать везде.

Логгирование в Андроиде меня удивило. С одной стороны, состав инструментов SDK намекает на него как главный инструмент отладки. Да и при тестировании без них никуда: андроидское сообщение "Приложение неожиданно остановилось" обычно совершенно ни о чем не говорит, а логи позволяют воссоздать картину преступления. С другой стороны, API для логгирования, мягко говоря, не блещет. Особенно по сравнению с такими монстрами, как log4j.

Удаляем логи из Android-приложения с помощью Proguard

Разбирали мы как-то одно приложение. Было оно обфусцировано, и чёрт бы ногу там сломал. Но помогла нам такая вещь: в коде встречались логи. Просто строчки вида Log.i(TAG, "Do something"). И по ним логику работы приложения можно было худо-бедно проследить.
Да даже если не рассматривать возможность реверс-инжиниринга, писание логов может неплохо затормозить приложение, так что в релизной версии их быть не должно. Этого можно добиться несколькими способами.