Android support library update

Android Support Library: немного о версионности

Mar 11, 2018 · 4 min read

Существуют такие вещи, о которых обычно не говорят: почему небо голубое, когда мне поднимут зарплату и наша любимая android.support.library. У всех них есть нечто общее: мы встречаемся с ними каждый день, но никогда не интересуемся как они устроены внутри и почему все именно так, как есть — примитивное великолепие.

Зачем мы это используем

При разработке приложений, мы часто хотим видеть одинаковую работу нашего кода на разных версиях устройств. Вместо того, чтобы писать код поддержки для ранних версий Андроид, нам достаточно взять готовую реализацию из Support Library и заняться более важными задачами (таски же должен кто-то закрывать).

Однако т а к было ранее, ведь сейчас, библиотека поддержки это куда больше, чем куча if else с проверкой версионности. Она содержит в себе такие полезные view как:

• RecyclerView — отличная альтернатива устаревшему ListView
• ViewPager — для реализации таб-ориентированной навигации или простого слайдинга
• DrawerLayout — позволяющий быстро и просто добавить боковое меню
• CardView — для разнородного контента

И даже помимо этого, в ней содержатся такие замечательные штуки как линтеры, любезно подсказывающие нам вероятные ошибки, различные утилитные классы типа ContextCompat , аннотации и кучу другого. Их использование значительно упрощает жизнь рядовому разработчику.

Как строится нейминг библиотек

В документации можно видеть список всех доступных для подключения библиотек с их кратким описанием.

Большинство библиотек поддержки имеет префикс, который ПО-СЛУХАМ говорит о минимальной версии андроид, необходимой для её работы.

Помимо упомянутых ранее виджетов, библиотека поддержки предоставляет нам улучшенный GridLayout , библиотеку Palette для работы с цветами, а также Preference Library для реализации экрана настроек (которой никто не пользуется, кек)

Подключаются они все примерно одинаково:

за исключением того, что у библиотек v4 отсутствует префикс)) Добро пожаловать в мир андроид разработки, здесь довольно часто в порядке вещей делать, казалось бы, одну и ту же вещь по разному. Даже гугл не стремается, нам то уж чего.

v4 уже считается довольно устаревшей и по дефолту студия генерирует нам семплы именно с v7 , чего и я советую вам придерживаться.

com.android.support:appcompat-v7 тянет за собой целый ворох различных зависимостей (даже архитектурных. а вы тут всё “какааая архитектура в ондроид”)

С одной этой подключенной библиотекой v7 , проект уже использует примерно 30% от всего доступного места (если считать по количеству методов). Ради справедливости стоит отметить, что здесь подключен и Котлин являющийся де-юро (но пока далеко не де-факто) стандартом разработки под Андроид.

и некоторые из этих библиотек мне не нужны, к примеру фрагменты и все её дочерние 13 зависимостей. Вместо них я использую обычные view (на примере Conductor) и кастомный роутинг (на примере Cicreone). Давайте посмотрим, сколько места нам удасться сэкономить если мы их отключим:

Согласно dex-count наши фрагменты занимают 1740 методов.

Отключаем их простой командой из gradle

пытемся собрать и огосподи BUILD FAILED ! Что же могло пойти не так?

Давайте глянем на логи и разберемся:

Это попросту значит, что в пакете фрагментов, лежит реализация FragmentActivity , которая используется в пакете AppCompatActivity , которую уже используем мы для своих активностей.

В принципе оно и логично, зачем пихать в зависимости то, что нигде не используется. А тут прихожу какой-то я и начинаю все отключать не разобравшись. Ну теперь-то разобрался, надеюсь разобрались и вы.

Помимо этого, была замечена вот какая штука

Обратившись к документации мы видим очень явную и понятную строчку, прочитав которую не было бы этой статьи, отнявшей у вас время:

Note: The minimum SDK version for all support library packages is at least API level 14. Some packages require a higher API level, as noted below.

Т.е. какую бы версию библиотек мы не подключили, минимальный API Level будет = 14 или выше.

А это значит, что префикс в названии библиотек не говорит по сути абсолютно ни о чем, ведь использовать их мы можем лишь с минимальной api = 14.

Проверяем и убеждаемся

Расследование можно считать закрытым. Спасибо за внимание!

Источник

Android Support Library 28. Что нового?

По давней традиции вместе с новой версией Android выходит обновление Support Library. Пока библиотека вышла в стадии альфа, но список изменений уже намного интереснее, чем такой же список у Android P. Google несправедливо мало рассказал и написал об основных нововведениях главной библиотеки для Android. Приходится читать исходники и разбираться, в чем особенности новых фич и зачем они нужны. Восстановлю справедливость и расскажу, чем нас порадовал Google:

• RecyclerView selection — выбор элементов теперь из коробки;
• Slices — новый способ отображать контент другого приложения;
• новые элементы дизайна: BottomAppBar, ChipGroup и другие;
• мелкие изменения одной строкой.

RecyclerView selection

В 2014 году, вместе с релизом Lollipop, Google добавила в support новый элемент — RecyclerView, как замену устаревшему ListView. Все было хорошо с ним, да не хватало одного метода из ListView — setSelectionMode(). Спустя 4 года этот метод косвенно был реализован в RecyclerView в виде целой библиотеки.

Что же волшебного в selection? Selection mode — режим, которой инициализируется долгим нажатием по элементу списка. Далее можем выбрать несколько других элементов и сделать общее действие на ними. Пример: в Google Photos selection mode значительно облегчает жизнь.

Давайте разберемся на практике, как обстоит дело в support.

Добавим в gradle зависимости. Интересно, что Google выделила selection в отдельный репозиторий.

Напишем стандартный адаптер для RecyclerView.

Модель Word используем в качестве данных.

Фундамент есть, приступим к реализации выбора. Сперва нужно определиться, что будет идентифицировать элемент списка. Google предлагает на выбор три варианта: Long, String, Parcelable. Для этой цели у нас уже сформирован Word, не хватает только реализации Parcelable. Реализацию добавим аннотацией @Parcelize, которая доступная в экспериментальной версии Kotlin. В Android Studio 3.2 пока есть проблемы со сборкой проекта с экспериментальным Kotlin, но никто не отменял студийные шаблоны.

SelectionTracker — главный класс библиотеки. Объект этого класса обладает информацией про выбранные пользователем элементы и позволяет из кода изменять этот список. Чтобы инициализировать данный класс, понадобятся реализации двух абстрактных классов: ItemKeyProvider и ItemDetailsLookup. Первый нужен для двусторонней связи позиции элемента в коллекции и ключа.

ItemDetailsLookup нужен для получения позиции элемента и его ключа по координатам x и y.

Напишем также интерфейс для получение данных из ViewHolder и реализуем его.

Везде стандартный код. Удивительно, почему разработчики support library не добавили классическую реализацию сами.

Сформируем трекер в Activity.

Поправим ViewHolder, добавим реакцию на изменение состояния выбора.

Добавим трекер в адаптер, переопределим onBindViewHolder с payload. Если изменения касаются только состояния выбора, то в payloads будет находиться константа SelectionTracker.SELECTION_CHANGED_MARKER.

Tracker готов и работает, как часы. Добавим немного красоты и смысла. Пусть AppBar меняет цвет, заголовок начнет отображать количество выбранных элементов и добавляется кнопка Clear в меню, когда пользователь что-нибудь выбирает. Для этого есть ActionMode и поддержка его в AppCombatActivity.

Первым делом напишем реализацию ActionMode.Callback.

Добавим observer к SelectionTracker и свяжем изменения в трекере с ActionMode в Activity.

Теперь точно все. Наслаждаемся простотой и красотой.

Мы сделали стандартный вариант. Кратко отмечу, что в Builder много методов для кастомизации процесса выбора. Например, с помощью метода withSelectionPredicate(predicate: SelectionPredicate) можно ограничить количество выбранных элементов или запретить выбор особых элементов. Также в Builder предусмотрены методы по добавлению поведения, которое может конфликтовать с selection при традиционном способе добавления. Например, при помощи withOnDragInitiatedListener(listener: OnDragInitiatedListener) можно настроить Drag&Drop.

Slices

Самой странной новинкой оказался Slice. Google посвятила очень мало времени объяснениям сообществу, что это за диковина. Есть только код и документации к половине классов. Давайте разбираться.

За основу возьму код отсюда, потому что они придумали, как обходить баги с Permission в Android P DP1. Хочу отметить, что Slices не является новинкой support library. Фича появилась в Android SDK 28, а в support ареал обитания расширен до 24 версии SDK. На этом можно завершить рассказ и продолжить его через несколько лет. Пока minSdkVersion может быть максимум 19, поговорим в общем об идее этой технологии и о том, зачем она вообще нужна.

Slices — библиотека, которая позволит запрашивать из одного приложения (клиент или хост) часть или статичный кусочек другого приложения (отправитель или провайдер). Очень похоже на описание RemoteViews, которое часто используется для программирования кастомных виджетов и уведомлений.

Slice — это данные в каркасе без дизайна и интерактивности, как HTML без CSS и Js. Дизайн будет подстраиваться под тему приложения-хоста. Пример слайса.

Отправитель — это ContentProvider, которому нужно реализовать простой метод onBindSlice(sliceUri: Uri): Slice и внутри метода сформировать Slice. У нас провайдер будет отсылать время и количество вызовов.

Клиенту нужно сделать запрос по URI к провайдеру, запросить через него slice, получить и передать его в SliceView. Все действия производятся через SliceManager. Важно не забыть про permission.

SliceManager предоставляет возможность подписаться с помощью SliceLiveData на изменения Slice в провайдере и внутри подписки обновлять SliceView. К сожалению, оно сейчас не работает. Мы использовали менее реактивный вариант.

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

В большинстве случаев RemoteView используется для виджетов и уведомлений. Slices плохо подходят под эти цели, они мало кастомизируемые и, как я уже писал, подстраиваются под дизайн приложения. Идеально подходят под приложения, которые используют данные других приложений. Под категорию всеобъемлющих подходят голосовые ассистенты — Google Assistant, Алиса и так далее. Как было замечено в блоге компании Novada, с помощью конструктора slice можно собирать слайсы, очень похожие на ответы для Google Assistant.

И тут самое время для теории.

Возьмем за основу то, что Slice сделан для программирования ответов в Google Assistant — стратегически важный продукт для компании. Очевидно, что мы живем во времена, когда графический интерфейс постепенно вытесняется голосовым: растет популярность домашних ассистентов и есть прогресс в разработке голосового искусственного интеллекта посредством ИИ, нейронный сетей и других хайповых технологий.

Для Google самым логичным вариантом было бы развивать и наращивать Google Assistant, чтобы за год-два он стал мощным инструментом. Slice — теоретически отличный инструмент для накачки дополнениями от сторонних разработчиков. Так ассистент станет мощнее, все действия можно проводить через него и отпадет надобность в рабочих столах и иконках. Тогда Google Assistant станет основой для Android.

На данный момент нам ничего не рассказали толком про Slice: ни целей, ни преимуществ над RemoteView. Хотя по количеству кода в новой версии support Slice занимает чуть ли не первое место. Поэтому я думаю, на ближайшей I/O нам будут подробно рассказывать про Slice. И возможно расскажут о планах эволюции ОС или даже представят версию Android с голосовым интерфейсом для разработчиков.

Но все это спекуляция и желание автора раскрыть теорию заговора и добраться к истине. Единственное, что можно сказать на сто процентов, на Google I/O нас ждет развязка истории.

Новые элементы:

MaterialCardView и MaterialButton

MaterialCardView наследуется от CardView и практически ничем не отличается от него. Добавлена только возможность задавать границы карточки и в качестве background используется другой drawable. Найдите 10 отличий.
MaterialButton является наследником AppCombatButton и тут различия заметны. Разработчики сюда добавили больше способов кастомизировать кнопку: цвет ripple эффекта, разные радиусы кнопок, границы, как у MaterialCardView.

Chip и ChipGroup

Тут и слова лишние.

BottomAppBar

Самый интересный и неожиданный виджет в данной подборке, хотя идея очень проста, AppBar разместить внизу. Пользователю с маленькими руками и большими экранами неудобно дотягиваться до кнопки вызова меню или просто кнопки на AppBar вверху. Но никакой другой пользы в этом элементе нет.

Меню на BottomAppBar нужно добавлять искусственно, для этого есть метод replaceMenu(@MenuRes int newMenu).

Дизайнеры классно придумали, как сочетать FloatingActionButton и BottomAppBar. Но без кнопки BottomAppBar смотрится лишним. Убирается вырез, остается подбородок с кнопками меню с одной стороны. Проблему с меню на больших экранах можно было бы решить интересней, например по длинному нажатию на FloatingActionButton трансформировать ее в меню внизу экрана.

Список коротких нововведений:

Для тех, кто хочет поковыряться:

1. Используйте Android studio 3.1 и выше. Эти версии пока не в релизе, но работают стабильно, я работал с 3.2.
2. Немного пошаманить в build.gradle с версиями. Ну и, естественно, нужно добавить нужные зависимости.

Пока код, который использовал support 28, запускался только на эмуляторе с Android P. Все, что старее, ругалось и выдавало кучу ошибок при попытке запуска.

Список новых фич не окончательный. Если анализировать changelog библиотеки за предыдущие 2-3 года и экстраполировать данные на этот год, то в мае нас ожидает ещё много-много интересного. Ждём.

Источник