Здесь будет история моего фейла и как не получилась трансляция на FireTV.
FireTV, хоть и внешне похож на Хромкаст (все мои приставки — самые простые стики), является куда более продвинутым устройством. Работает он под управлением модифицированного Андроида 5, то есть на нём можно не только транслировать видео с телефона, но и запускать полноценные Android-приложения (учитывая, однако, особенности управления с пульта).
Последние несколько месяцев я пишу приложение для просмотра видео. И вот, заказчики решили сделать интеграцию с ТВ-приставками. По этой причине у меня образовались три приставки-стика,— Chromecast, FireTV и Roku,— которые оказались совершенно не похожими друг на друга. Расскажу о них с точки зрения разработчика. Кода здесь не будет, просто общие соображения. Получилось много текста, так что про каждую приставку будет отдельная заметка.
С free и premium разобрались, теперь усложним задачу. Пусть наше приложение распространяется на нескольких площадках (Google Play, Samsung Apps и Amazon) и в нём есть встроенные покупки. Хорошо бы также сделать, чтобы библиотеки подключались только для нужной сборки, то есть чтобы версия для Google Play не тянула с собой логику самсунга. Ну и конечно, для каждой площадки мы должны собирать и free, и premium.
Страшно?
А всего-то что надо сделать:
Кому лень читать буквы, пожалуйте сразу в код.
Рассмотрим распространённую задачу: есть приложение, у которого есть две версии — ограниченная и полная. Они выпускаются с разными applicationId, у каждого своя иконка, и в ограниченной отсутствует некоторая функциональность.
Что будем делать?
Первая мысль: делаем в VCS две ветки, работаем в какой-то одной, а потом добавляем изменения в другую. Вполне себе выход. Правда, мержи постепенно превращаются в ад, так что лучше эту мысль сразу отбросить и решать проблему на уровне билд-скрипта.
По сути задачи у нас следующие:
Попробуем всё это сделать.
Во многих приложениях, которые мне приходится разрабатывать, присутствует серверная часть. Так что из проекта в проект кочевали одни и те же куски копипасты для отправки/чтения запросов.
А потом появилась библиотека Volley. Теперь вместо своей копипасты можно тащить в проекты именно её. И это хорошо.
Мне уже довелось использовать Volley в своих проектах, можно и впечатлениями делиться. Речь пойдёт именно о части отправки запросов на сервер. О NetworkImageView и прочих кэшах как-нибудь в другой раз.
Наши серверные коллеги тоже люди, так что API у них получаются разные. Кто-то передаёт параметры POST-ом, у кого-то работает gzip-компрессия, кто-то возвращает ошибки статусами, а у кого-то для них отдельный протокол. Попробую собрать наиболее частые вопросы и предложить решения.
Писать парсеры всегда долго и неинтересно. Особенно для XML — большая куча однообразного неприятного кода. Бывает, что это надоедает и начинаешь пытаться упростить себе жизнь.
Один из способов оптимизировать время разработки — использование библиотек десериализации. API обычно используют форматы JSON и XML. Для первого есть годная библиотека Gson, для второго Simple. Рассмотрим обе.
Собственно, смысл у них обеих один и тот же: разобрать заданную строку в объектную модель. Работа обеих основана на Reflection, что не лучшим образом сказывается на производительности. Обе предоставляют аннотации для маппинга полей, успешно разбирают как объекты, так и списки.
Особенности работы библиотек — не тема данной статьи. Здесь мы будем рассматривать, как скрестить их с Volley, чтоб потом быстро запросы писать и горя не знать. Для этого напишем несколько реализаций нашего любимого класса Request (вернее, написанного в прошлой части ExtendedRequest).
Как известно, у 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; } }
Можно добавлять на экран сколько угодно таких компонентов, они все будут радостно крутиться, и не понадобится никаких дополнительных атрибутов.
Внимание: эта статья устарела! Гуглы довольно сильно перепилили свой GCM, и теперь всё не так. Но скрипт для отправки тестовых пушей всё ещё работает, поэтому убирать статью я пока не буду и постараюсь найти время её актуализировать.
Мы привыкли писать мобильные приложения, которые обращаются к некоторому API и получают оттуда данные. А ведь бывает и обратная ситуация: отправку данных клиенту может инициировать сам сервер. Обычно это используется для так называемых Push-нотификаций.
Мне известны два способа реализации Push-нотификаций. Во-первых это Google Cloud Messaging (бывший C2DM), во-вторых Urban Airship. Про последний я почти ничего не знаю (кроме отзывов коллеги о том, что использование его сильно сажает батарейку на телефоне). А про GCM пойдет речь в посте.
Вкратце процесс выглядит так:
Есть клиентское приложение, серверная часть и облачный сервис Google.
Я расскажу о своем опыте использования этой технологии и выложу рабочий пример.
Я люблю логи, считаю их лучшим инструментом отладки, чем дебаггер и стараюсь использовать везде.
Логгирование в Андроиде меня удивило. С одной стороны, состав инструментов SDK намекает на него как главный инструмент отладки. Да и при тестировании без них никуда: андроидское сообщение "Приложение неожиданно остановилось" обычно совершенно ни о чем не говорит, а логи позволяют воссоздать картину преступления. С другой стороны, API для логгирования, мягко говоря, не блещет. Особенно по сравнению с такими монстрами, как log4j.
Log.i(TAG, "Do something"). И по ним логику работы приложения можно было худо-бедно проследить.В прошлой статье шла речь о работе с PackageManager. Вдогонку к ней расскажу я, как можно реализовать chooser приложений
Мне время от времени приходится решать задачи, связанные с работой с пакетами в Android. В этой статье я приведу несколько сниппетов для решения этих задач.
Не так давно пришлось прикручивать к нашему приложению озвучку с помощью Text-to-Speech (TTS). Об этом-то я и хочу сегодня рассказать.
Каждый раз, когда мне приходится использовать компонент Gallery, я поражаюсь его бестолковости. Кое с чем мириться просто невозможно:
Хотела написать про эту фичу в статье про XML drawables, но как-то не вместилось. Так что пусть будет аддоном.
Например, хочется нам, чтобы в прогрессе крутилась не стандартная крутилка, а какая-нибудь такая:
В Android довольно продуманная система организации ресурсов. И особого внимания заслуживают ресурсы-изображения.
О самих картинках сказать можно мало что. Основная фича тут такая: можно адаптировать картинки для разных разрешений и размеров экранов и складывать в специализированные папки. Для различных разрешений экрана используются drawable-hdpi, drawable-mdpi и пр.. Аналогичное деление для размеров экрана: drawable-normal, drawable-large и т.д.. Можно даже одно с другим совмещать и создавать папки типа drawable-normal-hdpi. Изображения, которые должны оставаться неизменными вне зависимости от разрешения экрана, следует размещать в папке drawable-nodpi.
Но тема данной статьи несколько другая. Изображение (drawable) в Android-приложении — это не обязательно картинка. Бывают еще изображения, заданные с помощью XML. Их-то мы и рассмотрим подробнее. Будет много XML и мелких картинок.
Относительно недавно мы рассматривали способ, как писать собственые компоненты на примере VerticalProgressBar. Однако была в той реализации некоторая некрасивость: свойства компонента (такие как progress и max) можно было инициализировать только в коде:
mProgressBar = (VerticalProgressBar)findViewById(R.id.progress); mProgressBar.setMax(100); mProgressBar.setProgress(0);
А было бы лучше выставлять их прямо в XML-разметке. В этой статье мы разберем, как это делается.
