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.
Проверяем и убеждаемся
Расследование можно считать закрытым. Спасибо за внимание!
Источник
Полный список
— разбираемся, зачем нужна библиотека Support Library
— на примере фрагментов используем библиотеку v4
Support Library – библиотека, которая на старых версиях Android делает доступными возможности новых версий. Например, фрагменты появились только в третьей версии (API Level 11). Если вы хотите использовать их в своем приложении, это приложение не будет работать на более старых версиях Android, т.к. эти старые версии никогда не слышали про класс android.app.Fragment. Какие тут есть выходы?
1) Добавить в код проверку версии системы и в зависимости от результата выполнять тот или иной код. Т.е. если версия 11 и выше, используем фрагменты, иначе Activity. Вполне выполнимо, но не совсем просто. Можно ошибиться и запутаться. Т.е. при запуске приложения на старых версиях приходится либо отказываться от новшеств и пользоваться тем, что есть, либо изобретать велосипед и реализовывать новшества самому.
2) Можно забить на старые версии и позиционировать свое приложение только для новых версий. Тогда теряется ощутимая часть потенциальных пользователей вашей программы. На момент написания этого материала на версии Android ниже третьей сидит 69,7% пользователей. Ощутимая такая потеря получится — больше, чем две трети! Конечно, со временем все перейдут на третью и последующие версии, и смогут использовать ваше приложение. Но к тому времени выйдут новые версии Android с новыми возможностями, вы их реализуете в своем приложении и, тем самым, снова отсеете часть пользователей. В общем, вырисовывается постоянная дискриминация пользователей по версии.
3) Использовать библиотеку Support Library. Она содержит классы — аналоги новшеств последних версий, которые будут работать на старых версиях.
На данный момент есть две библиотеки v4 и v13. Цифра здесь указывает минимальный API Level на котором можно использовать эту библиотеку. Т.е. приложение, использующее v4, может быть запущено на API Level >= 4 и ему будут доступны новшества, которые входят в эту библиотеку (например, фрагменты).
Библиотеки эти периодически обновляются, в них добавляются новые классы, реализующие новые возможности. Так что, если вы не нашли в них сейчас то, что вам нужно, вполне возможно, что это появится в будущем. Самый яркий пример – ActionBar. Его, к сожалению, в v4 пока нет. И я, честно говоря, не знаю, появится ли. Умельцы пишут свои аналоги, т.е. реализуют первый вариант из рассмотренных нами выше и предоставляют нам возможность использовать его, как третий вариант. Ведь мы вовсе не обязаны ограничиваться стандартной Support Library от гугла. Можно использовать и другие библиотеки от других разработчиков. Самая популярная реализация ActionBar – это ActionBarSherlock.
Разобрались с тем, что такое Support Library и зачем она нужна. Теперь посмотрим, как ее использовать. Работать будем с v4.
Если у вас библиотека загружена, а версия ADT одна из последних, то Eclipse сам автоматически добавит в проект эту библиотеку. И вы сразу после создания нового проекта сможете ее использовать.
Если не все так радужно, то надо скачать и добавить самим. Несложный и недолгий процесс. На официальном сайте есть инструкция. И я здесь просто напишу перевод этой инструкции со своими дополнениями. Но не спешите все это проделывать! Возможно, вам это не понадобится.
Чтобы загрузить библиотеку:
Откройте SDK Manager, найдите там Android Support Library и установите ее
Библиотека v4 загрузится в папку: /extras/android/support/v4/android-support-v4.jar
Чтобы добавить библиотеку в ваш проект:
В проекте создайте папку libs. Он должна быть в корне, на том же уровне, что и res, bin и прочие. Поместите в папку libs загруженную библиотеку android-support-v4.jar. Далее, правой кнопкой на этой библиотеке в папке libs, и в контекстном меню Build Path > Add to Build Path.
Обновите манифест, указав в нем, что минимальная требуемая версия для вашего приложения – API Level 4.
При создании нового проекта проверьте — если папка libs с библиотекой в проекте есть, то выше приведенная инструкция вам не нужна.
Из рассмотренных нами в прошлых уроках классов, библиотека содержит Fragment, FragmentManager, FragmentTransaction, ListFragment, DialogFragment.
Полный список объектов можно посмотреть, открыв API на сайте. Вот основной пакет — android.support.v4.app. Слева видны остальные.
Напишем простейший пример использования фрагмента в приложении для API Level 10.
Project name: P1141_SupportLibrary
Build Target: Android 2.3.3 (не 4.1 . )
Application name: SupportLibrary
Package name: ru.startandroid.develop.p1141supportlibrary
Create Activity: MainActivity
Сначала layout fragment.xml:
Пустой красный LinearLayout.
Далее создаем класс — MyFragment. Если мы сделаем это по старинке, наследуя android.app.Fragment, то в созданном классе получим ошибку The import android.app.Fragment cannot be resolved. И это логично, т.к. в Android 2.3.3 (API Level 10) нет такого класса.
И, собственно, именно тут и пригодится нам библиотека v4. Будем наследовать ее класс android.support.v4.app.Fragment при создании фрагмента
Только FrameLayout, который будет контейнером для фрагмента.
Далее есть один нюанс. Чтобы в старой версии Android использовать фрагменты из Support Library, нам необходимо использовать не стандартное Activity, а также из библиотеки – android.support.v4.app.FragmentActivity.
В коде видим еще одно отличие. FragmentActivity использует метод getSupportFragmentManager (а не getFragmentManager) для получения FragmentManager. В остальном, работа с фрагментами не будет отличаться от прошлых уроков. Различие будет только в секции import. Если раньше было, например так:
import android.app.Fragment;
import android.app.FragmentManager;
import android.app.FragmentTransaction;
(это работает только на новых версиях)
то с использованием v4 будет так:
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentManager;
import android.support.v4.app.FragmentTransaction;
(это будет работать и на старых и на новых версиях)
Цель проста — работоспособность вашего приложения на старых версиях, которые ничего не знают про фрагменты. Старые версии будут использовать для работы с фрагментами классы библиотеки v4. Но, разумеется, этот код без проблем сработает и на последних версиях Android.
Все сохраняем, запускаем приложение и видим работающий фрагмент на Android версии 2.3.3
Ради интереса запустим его же на Android 4.1
Итого, благодаря библиотеке, один и тот же код работает на старых и новых версиях и использует возможности новых версий.
На следующем уроке:
— учитываем ориентацию и размер экрана в работе приложения
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
Введение в новый CoordinatorLayout
В этом году на конференции Google IO компания Google представила новую библиотеку Android Design Support Library, которая создана для того, чтобы помочь разработчикам внедрять материальный дизайн в их приложения. Билиотека содержит много компонентов, нужных для этого нового стиля, и работает со всеми уровнями API, начиная с седьмого. Если по какой-то причине вы пропустили её анонс, можете ознакомиться с постом Ian Lake, выложенным на Android Developers Blog.
Встречайте Android CoordinatorLayout
Из всех компонентов, включенных в Android Design Support Library, наиболее интересным выглядит новый «прокачанный FrameLayout», он же герой нашей статьи — CoordinatorLayout. По названию можно догадаться, что CoordinatorLayout позволяет координировать некие зависимости между включенными в него виджетами.
Всё, что нужно сделать — обернуть необходимые нам виджеты в CoordinatorLayout. Давайте посмотрим, как это будет выглядеть в коде. Наш демонстрационный код очень прост — Floating Action Button, по нажатию на которую на экране появляется Snackbar.
Сначала добавим Support Design Library в gradle:
Теперь создадим разметку для нашей Activity:
И, заодно, саму MainActivity:
Посмотрим на демо:
Но что если мы захотим использовать другую реализацию FAB? FAB из Support Library не умеет разворачиваться по нажатию на неё в список доступных опций (прим. переводчика: так, как это показано в спецификациях дизайна от самой Google), поэтому давайте-ка попробуем другую реализацию FAB:
В этом случае CoordinatorLayout не работает из коробки, и связано это с тем, что наша новая FAB не имеет подключенной к ней реализации класса CoordinatorLayout.Behavior (прим. переводчика: далее по тексту будет использоваться слово «поведение»). Что можно сделать? Можно подождать, пока кто-нибудь не добавит её…
… или написать свою собственную реализацию CoordinatorLayout.Behavior, специфичную для FAB в нашем проекте.
Виджеты учатся вести себя правильно
Чем по-настоящему хорош CoordinatorLayout, так это тем, что нам не нужно иметь доступа к исходникам того виджета, для которого нужно реализовать его поведение. Также можно изменить поведение по умолчанию для любого виджета.
Сначала отнаследуемся от класса CoordinatorLayout.Behavior:
Добавим конструктор с параметрами Context и AttributeSet для того, чтобы наша реализация могла получить необходимые ей аттрибуты из xml-файла:
Следующий шаг — переопределить метод layoutDependsOn() и возвращать true только тогда, когда мы хотим отреагировать на происходящие в разметке изменения. В нашем случае, мы хотим реагировать только на изменения виджета Snackbar:
Теперь перейдем к реализации поведения. Метод onDependentViewChanged вызывается всякий раз, когда с виджетом, который находится в CoordinatorLayout и изменения которого мы отслеживаем, что-то происходит (прим. переводчика: имеются в виду изменения, приводящие к тому, что нужно пересчитать положение на экране виджета, для которого мы реализуем поведение, то есть понятно, что изменение, скажем, цвета Snackbar нас никак не интересует). В этом методе мы можем узнать текущее состояние Snackbar, и, соответственно, подвинуть FAB вверх, когда Snackbar появляется на экране. Для этого нужно изменить значение translationY у FAB на величину, равную высоте Snackbar. В начале анимации Snackbar, свойство translationY SnackBar’a выставлено в величину, равную высоте самого Snackbar, а значит, чтобы получить правильное значение translationY для FAB, нам нужно вычесть высоту Snackbar из его же translationY. Согласно документации, нам нужно вернуть true тогда, когда объект меняет своё положение на экране.
Последнее, что остаётся сделать — указать, что CoordinatorLayout должен использовать FloatingActionButtonBehavior. Сделать это можно в разметке:
И вот результат:
Если вы хотите указать для своего виджета поведение по умолчанию, пометьте его аннотацией DefaultBehavior, указав в параметрах аннотации путь к нужной вам реализации класса Behavior.
Хотите взглянуть на полную реализацию? Вам на github.
Источник
