воскресенье, 3 января 2016 г.

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

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

Страшно?

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

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

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

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

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

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

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

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

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

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

пятница, 29 ноября 2013 г.

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

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

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

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

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

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

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

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

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

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

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

среда, 30 октября 2013 г.

Разбор дат и других нетривиальных классов в 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.

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

четверг, 20 июня 2013 г.

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;
    }
}

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

воскресенье, 2 декабря 2012 г.

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

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

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

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

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

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

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

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

суббота, 24 ноября 2012 г.

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

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

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