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

Мои заказчики думали, что Roku — это тоже что-то про Android, но всё оказалось не так. У Roku свой отдельный и полный загадок мир.

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

Здесь будет история моего фейла и как не получилась трансляция на FireTV.

FireTV, хоть и внешне похож на Хромкаст (все мои приставки — самые простые стики), является куда более продвинутым устройством. Работает он под управлением модифицированного Андроида 5, то есть на нём можно не только транслировать видео с телефона, но и запускать полноценные Android-приложения (учитывая, однако, особенности управления с пульта).

Кратко о разработке для ТВ-приставок: 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.

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