Кратко о разработке для ТВ-приставок: Chromecast

Последние несколько месяцев я пишу приложение для просмотра видео. И вот, заказчики решили сделать интеграцию с ТВ-приставками. По этой причине у меня образовались три приставки-стика,— Chromecast, FireTV и Roku,— которые оказались совершенно не похожими друг на друга. Расскажу о них с точки зрения разработчика. Кода здесь не будет, просто общие соображения. Получилось много текста, так что про каждую приставку будет отдельная заметка.

Gradle Product Flavors. Подключение библиотек, организация кода, сочетания вариантов

С free и premium разобрались, теперь усложним задачу. Пусть наше приложение распространяется на нескольких площадках (Google Play, Samsung Apps и Amazon) и в нём есть встроенные покупки. Хорошо бы также сделать, чтобы библиотеки подключались только для нужной сборки, то есть чтобы версия для Google Play не тянула с собой логику самсунга. Ну и конечно, для каждой площадки мы должны собирать и free, и premium.

Страшно?

А всего-то что надо сделать:

• Включение/отключение библиотек
• Добавление в разные сборки специфической логики
• Как-то сочетать несколько flavors

Кому лень читать буквы, пожалуйте сразу в код.

Gradle Product Flavors. Основные понятия и структура проекта

Рассмотрим распространённую задачу: есть приложение, у которого есть две версии — ограниченная и полная. Они выпускаются с разными applicationId, у каждого своя иконка, и в ограниченной отсутствует некоторая функциональность.

Что будем делать?

Первая мысль: делаем в VCS две ветки, работаем в какой-то одной, а потом добавляем изменения в другую. Вполне себе выход. Правда, мержи постепенно превращаются в ад, так что лучше эту мысль сразу отбросить и решать проблему на уровне билд-скрипта.

По сути задачи у нас следующие:

• Использовать для сборок разные ресурсы
• Настроить свой applicationId для каждой сборки

Попробуем всё это сделать.

О Volley немного по-другому

Во многих приложениях, которые мне приходится разрабатывать, присутствует серверная часть. Так что из проекта в проект кочевали одни и те же куски копипасты для отправки/чтения запросов.

А потом появилась библиотека Volley. Теперь вместо своей копипасты можно тащить в проекты именно её. И это хорошо.

Мне уже довелось использовать Volley в своих проектах, можно и впечатлениями делиться. Речь пойдёт именно о части отправки запросов на сервер. О NetworkImageView и прочих кэшах как-нибудь в другой раз.

• Чем мне не нравятся мануалы о Volley
• Решения некоторых часто встречающихся задач
• Volley и библиотеки десериализации

Решения некоторых часто встречающихся задач с Volley

Наши серверные коллеги тоже люди, так что API у них получаются разные. Кто-то передаёт параметры POST-ом, у кого-то работает gzip-компрессия, кто-то возвращает ошибки статусами, а у кого-то для них отдельный протокол. Попробую собрать наиболее частые вопросы и предложить решения.

Volley + библиотеки десериализации

Писать парсеры всегда долго и неинтересно. Особенно для XML — большая куча однообразного неприятного кода. Бывает, что это надоедает и начинаешь пытаться упростить себе жизнь.

Один из способов оптимизировать время разработки — использование библиотек десериализации. API обычно используют форматы JSON и XML. Для первого есть годная библиотека Gson, для второго Simple. Рассмотрим обе.

Собственно, смысл у них обеих один и тот же: разобрать заданную строку в объектную модель. Работа обеих основана на Reflection, что не лучшим образом сказывается на производительности. Обе предоставляют аннотации для маппинга полей, успешно разбирают как объекты, так и списки.

Особенности работы библиотек — не тема данной статьи. Здесь мы будем рассматривать, как скрестить их с Volley, чтоб потом быстро запросы писать и горя не знать. Для этого напишем несколько реализаций нашего любимого класса Request (вернее, написанного в прошлой части ExtendedRequest).

Разбор дат и других нетривиальных классов в Simple

Базовое использование Simple мы рассмотрели, но есть одна особенность, которую хочется разобрать отдельно.

Иногда просто аннотаций бывает недостаточно. Бывает, что в объектной модели есть поля таких типов, к которым мы либо не можем написать маппинги, либо там нужна более сложная логика, чем просто отображение узлов и атрибутов. Обычный пример — любые классы для работы с датами: что стандартный Calendar, что более приятный DateTime из библиотеки joda-time. Дата в XML может представляться миллисекундами, секундами, отформатированной строкой и чем угодно ещё. Задать правила разбора не всегда предоставляется возможным.

В Simple подобные задачи предусмотрены, и для них существует концепция Matcher-ов.

Обзор библиотеки XML-сериализации Simple

Simple — полезная Java-библиотека для XML-сериализации/десериализации объектов. В частности, её можно использовать с Android.

Зачем это нужно?

Все мы любим XML и часто его разбираем. То какой-нибудь сервер нам его пришлёт, то в само приложение зашиты какие-нибудь данные в этом формате, то ещё что-нибудь. Разбор XML всегда выливается в написание кучи унылого однообразного кода вот такого вида (ну или такого). С Simple нам нужно только задать правила отображения объектной модели на узлы XML, дальше сериализатор сделает всё сам. Экономим время, делаем меньше ошибок, получаем более читаемый и сопровождаемый код.

И что нам за это будет?

Jar весит полмегабайта, а значит, увеличивает размер выходного приложения.

А ещё Simple работает через Reflection, так что производительность тоже не блещет. Один не особенно страшный, но разветвлённый XML-файл Simple разобрал в 20 раз медленнее, чем стандартный XmlPullParser.

Так что недостатки тоже есть, а насколько они критичные — решайте сами.

MarqueeTextView

Как известно, у TextView есть полезный атрибут ellipsize. Он позволяет установить, как компонент будет себя вести, если текст не влез в отведенную область. none (по умолчанию) отрежет текст по пробелу, end поставит в конце многоточие, и так далее.

Самое интересное значение этого атрибута – marquee. Оно означает, что текст превращается в бегущую строку: сам прокручивается справа налево либо бесконечное, либо определенное число раз (для этого уже другой атрибут – marqueeRepeatLimit)

Однако, на практике оказывается, что для корректной работы этого атрибута надо долго прыгать с бубном – ставить всякие singleLine (хоть он и значится deprecated, без него никак), focusable и прочие нелогичные вещи. Плюс к тому, marquee работает только тогда, когда компонент в фокусе. Соответственно, добавить на один экран несколько таких компонентов не кажется реальным.

Однако, недавно мне попалось решение, неожиданно простое, и я его сейчас накопипащу:

public class MarqueeTextView extends TextView {
    public MarqueeTextView(Context context, AttributeSet attrs) {
        super(context, attrs);
        setEllipsize(TextUtils.TruncateAt.MARQUEE);
        setMarqueeRepeatLimit(-1);
        setSingleLine(true);
    }

    @Override
    protected void onFocusChanged(boolean focused, int direction, Rect previouslyFocusedRect) {
        if(focused) {
            super.onFocusChanged(focused, direction, previouslyFocusedRect);
        }
    }

    @Override
    public void onWindowFocusChanged(boolean focused) {
        if(focused) {
            super.onWindowFocusChanged(focused);
        }
    }

    @Override
    public boolean isFocused() {
        return true;
    }
}

Можно добавлять на экран сколько угодно таких компонентов, они все будут радостно крутиться, и не понадобится никаких дополнительных атрибутов.

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

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

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

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

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

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

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

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