android appcompat что это
В предварительном просмотре компоновка выглядит так:
то есть, шрифт Russo One успешно был задан элементу TextView (путь к файлу шрифта: res\fonts\russo_one.ttf ). Но на реальном телефоне всё выглядит иначе:
Но теперь проблема заключается в другом. До использования библиотеки AppCompat моё приложение весило ≈345 Кб. После того, как я добавил эту библиотеку в мой проект, приложение стало весить 2,6 Мб — это почти в 8 раз больше. Подскажите, используют ли эту библиотеку современные профессиональные программисты в своих Android-приложениях. В чём же заключается суть использования этой библиотеки? В интернете нашёл не много информации о ней, многие лишь утверждали, что она помогает сохранять красивый одинаковый стиль приложений на более ранних версиях Android. У моего приложения я хочу задать минимальный требуемый уровень API 15. Стоит ли мне в данном случае пользоваться этой библиотекой и если стоит, то какими её преимуществами руководствоваться? Очень мало русскоязычных справочников, документаций, форумов на эту тему в интернете я сумел найти.
2 ответа 2
Beginning with Android 3.0 (API level 11), all activities that use the default theme have an ActionBar as an app bar. However, app bar features have gradually been added to the native ActionBar over various Android releases. As a result, the native ActionBar behaves differently depending on what version of the Android system a device may be using. By contrast, the most recent features are added to the support library’s version of Toolbar, and they are available on any device that can use the support library.
For this reason, you should use the support library’s Toolbar class to implement your activities’ app bars. Using the support library’s toolbar helps ensure that your app will have consistent behavior across the widest range of devices. For example, the Toolbar widget provides a material design experience on devices running Android 2.1 (API level 7) or later, but the native action bar doesn’t support material design unless the device is running Android 5.0 (API level 21) or later.
Accompanist — первый аккорд. Обзор библиотеки для Jetpack Compose
Обычно новым фреймворкам не хватает хороших примеров использования, туториалов и инструментов. Но не в случае с Jetpack Compose: параллельно с разработкой фреймворка Google развивал репозиторий, богатый на примеры использования. Вырисовывался набор полезных утилит, переиспользуемых виджетов и прочих удобств для разработки.
Так из репозитория с примерами вырос Accompanist — набор библиотек для Jetpack Compose, которые можно добавить в свой проект как зависимость. В статье рассмотрим подробнее, какой инструментарий он предоставляет.
AppCompat Theme Adapter
В легаси-проекте тема может быть достаточно большой, иметь большое поддерево тем и кастомных атрибутов. В легаси-проектах обычно это AppCompat тема, в то время как Compose использует MaterialTheme. Поэтому нужен «мост» между двумя темами.
В составе Accompanist есть AppCompatTheme — удобная обёртка, которая перенесёт тему из мира легаси и XML в мир Compose. Исходники простые: их можно дополнить или сделать по образу свою реализацию, если в теме много кастомных параметров.
Если проект уже использует Material Design Theme, то, согласно, документации, надо использовать MDC-Android Compose Theme Adapter из Material Design Components.
SystemUiController
SystemUiController — удобная обёртка над WindowInsetsControllerCompat. Помогает из кода управлять свойствами системных баров: видимостью и цветом. Незаменимая вещь, если вы поддерживаете в проекте API от версии 21 (Android 5.0).
Insets
Insets — обёртка над WindowInsetsCompat и набор расширений для совместимости с Compose. Поможет подписаться на изменения Inset’ов.
Кроме параметров из WindowInsetsCompat, можно использовать расширения для Modifier.
Для работы с padding’ами:
Для работы с размерами:
Permissions
Работа с опасными разрешениями требует некоторых усилий. Нужно:
Запросить разрешение у пользователя.
С помощью кастомного диалога (view, snackbar и других) объяснить пользователю, зачем нужно разрешение.
Правильно обработать ответ пользователя.
Предоставить возможность перейти в настройки приложения, чтобы пользователь мог принять решение, какие доступы дать.
Разработчики Accompanist проделали большую работу, чтобы работать с разрешениями было удобно. И что самое классное, они сделали запрос разрешений через ActivityResultLauncher: никакого больше переопределения onActivityResult в Activity, и теперь явно прописывается контракт для запроса разрешения.
API достаточно простое.
permissionState — состояние с параметрами разрешения. Кроме boolean флагов, нужен для запроса разрешения.
permissionNotGrantedContent — контент для состояния, когда нет разрешения.
permissionNotAvailableContent — контент для состояния, когда разрешение нельзя запросить. Тогда пользователя надо направить в настройки приложения.
content — контент для состояния, когда пользователь дал разрешение.
Пара скриншотов с примерами работы из семпла
FlowLayout
FlexBoxLayout — контейнер для гибкой вёрстки. С ним удобно располагать элементы по горизонтали или вертикали: например, чтобы отобразить коллекцию элементов. Он сам рассчитает размеры и поймёт, как лучше перенести элемент на следующую строку или столбец.
FlexBox для Android — не родной контейнер для вёрстки. Первую версию FlexBoxLayout для CSS представили в 2009 году. До мира Android-разработки он добрался сильно позже: в 2016 году вышла первая alpha версия. С того времени вышло немало релизов, самый свежий — 3.0.0.
Также вышел FlexBoxLayoutManager для RecyclerView. Вещь удобная, и она не могла не появиться в Compose. Только назвали контейнер по-другому: FlowLayout. Название не менее лаконичное — и так же точно передаёт суть его работы.
Как и его предки, имеет такие же параметры для вёрстки. Поэтому если вы с ними уже встречались ранее, то и в Compose верстать с его помощью будет несложно.
SwipeRefreshLayout
SwipeRefreshLayout — один из самых известных и используемых контейнеров в Android разработке.
Использовать его просто: в XML необходимо контейнер с контентом обернуть в SwipeRefreshLayout и в коде реализовать интерфейс OnRefreshListener — например, чтобы начать перезагрузку контента на экране. Вроде всё хорошо, больше ничего и не надо.
Трудности начинаются, если разработчику нужно кастомизировать внешний вид лоадера. Возможности кастомизации ограничены — несмотря на громоздкую реализацию (
«Из коробки» можно изменить цвет стрелки, размер и появление индикатора. Если вам необходимо изменить цвет индикатора или (о боже) «а давайте как на iOS», то придётся искать стороннюю библиотеку или писать самостоятельно. Но и то, и другое занимает время и несёт риски.
Accompanist помогает решить эти проблемы.
В Accompanist отсутствует XML, но принцип использования не изменился: контент всё так же оборачиваем в SwipeRefresh и используем лямбду для действия при обновлении.
Рассмотрим, что SwipeRefresh умеет «из коробки» и что с возможностью кастомизации.
state — хранит состояние загрузки и прогресс анимации индикатора.
onRefresh — лямбда-триггер для старта, например, перезагрузки контента.
modifier — модификатор контейнера: размеров, отступов и так далее.
swipeEnabled — включение и выключение реакции контейнера на свайп.
refreshTriggerDistance задаёт расстояние до триггера анимации. Чем расстояние больше, тем позже индикатор отреагирует на свайп.
indicatorAlignment — аналог Gravity. Интересная функциональность, которая пригодится, скорее, при реализации кастомного индикатора.
indicatorPadding — простая кастомизация отступов индикатора. Можно сделать отступ с определённой стороны, можно равный со всех.
indicator — реализация индикатора. «Из коробки» есть стандартная реализация индикатора из material design. Можно модифицировать её или написать полностью свою.
clipIndicatorToPadding — флаг, позволяющий обрезать индикатор по отступу контента.
content — непосредственно сам контент внутри SwipeRefresh.
Примеры работы SwipeRefresh из семпла библиотеки Accompanist.
SwipeRefresh уже «из коробки» предоставляет неплохие возможности кастомизации привычного Android-разработчикам SwipeRefreshLayout. Реализация контейнера и индикатора занимает примерно 600 строк.
Pager
На UI языке Pager — горизонтальный или вертикальный список, у которого каждый элемент занимает всю или почти всю область экрана. Ключевое отличие от обычного списка — Snap-эффект, то есть «доскрол» элемента.
Pager, или ViewPager, имел несколько стадий развития как UI элемент в Android. Сначала был ViewPager, позже появился RecyclerView, и его приспособили под пейджинг. Сравнительно недавно появился ViewPager2, который под капотом использует тот же RecyclerView.
Давайте взглянем, как Pager может выглядеть на «языке» Compose. ViewPager, ViewPager2 и RecyclerView имеют общую черту: как UI-элементам для отображения коллекций, им нужен адаптер для заполнения данными. Pager на Compose этого лишён: взамен адаптера необходимо инициализировать PagerState. С него и начнём.
Параметров немного, а для инициализации обязательный всего один.
pageCount — количество элементов,
currentPage — текущая страница,
currentPageOffset — отступ страницы. Имеет значение от 0.0 до 1.0. Можно использовать для программного скролла страницы.
offscreenLimit — лимит страниц для подгрузки: количество подгружаемых элементов слева и справа от текущего элемента.
infiniteLoop — зацикленный скролл.
Сразу видно, какая функциональность «из коробки» самая крутая — конечно же, это зацикленный скролл. Сколько же было написано костылей для зацикливания ViewPager и RecyclerView 🙂
Accompanist предлагает две реализации для пейджера: HorizontalPager и VerticalPager. Если взглянуть в исходники, и то, и другое — просто обёртка на Compose функцией Pager. Разница только в инициализации параметра isVertical.
Многие параметры могут быть знакомы по RecyclerView и ViewPager. Поэтому рассмотрим те, которые не встречаются у них «из коробки».
verticalAlignment — аналог Gravity. Используется для центровки элемента: например, чтобы элемент доскроливался не до центра, а до края контейнера.
horizontalAlignment — аналогично vercticalAligment, только для горизонтали.
flingBehavior — конфиг поведения скрола: настраивает анимацию, когда пользователь перестаёт скролить или бросает скрол. Эти параметры примечательны тем, что у ViewPager и RecyclerView они не настраиваются легко «из коробки». Для ViewPager придётся «шаманить» с параметрами адаптера и с самим ViewPager. У RecyclerView для доскрола используются наследники SnapHelper’а.
В коде всё выглядит достаточно просто: инициализируем PagerState и заполняем пейджер элементами.
Часто пейджеры используются с индикаторами страниц, табами, а также трансформацией страниц при свайпе. И для этого у Accompanist’а тоже есть решение.
Как я писал выше, состояние Pager’a хранится в PagerState. Для анимации индикаторов, трансформации страниц работы с табами его можно переиспользовать. Очень удобно: одно состояние для всех компонент — нет необходимости проставлять слушателей. Как бонус — получаем минимальную связность.
Coil (Coroutine Image Loader) — сравнительно новая библиотека: первая версия вышла в 2019 году. Написана на Kotlin и Coroutines — и в этом её преимущество перед Glide и Picasso. У неё простое и гибкое API, она легко интегрируется с проектами на Kotlin, а ещё умеет работать с Svg, Gif и видео.
До недавнего времени Accompanist тоже имел в арсенале интеграцию с Coil и Glide. С версии 0.15.0 этот инструментарий помечен как Deprecated: разработчики Coil добавили поддержку Compose и сделали это на основе Accompanist с небольшими изменениями. Поэтому далее код будет из примера работы Coil, а не Accompanist.
Чтобы понять, как происходит интеграция Coil и Compose, рассмотрим параметры элемента ImageView в Compose. Почти все могут быть знакомы Android-разработчику.
painter — сущность для отрисовки графики. Это может быть цвет, Bitmap или Vector.
contentDescription — cпециальный параметр для работы с Accessibility. Вы же хороший разработчик и не ставите туда null? 🙂
modifier — модификатор для выставления параметров элемента: размера, отступов и так далее.
alignment — аналог Gravity.
contentScale — аналог ScaleType из ImageView.
alpha — прозрачность для отрисовки painter.
colorFilter — цветовой фильтр для отрисовки painter.
Вся магия происходит в painter — точнее, в наследниках абстрактного класса Painter. Собственно, Coil для интеграции предоставляет свои реализации Painter’a.
CrossFadePainter отрисовывает cross fade переход между двумя Painter’ами.
CrossFadePainter
DrawablePainter — cамый простой представитель Painter’ов из библиотеки, но не менее полезный. Умеет отображать Drawable и AnimatableDrawable.
DrawablePainter
ImagePainter умеет больше всех. Поддерживает загрузку String, Uri («android.resource», «content», «file», «http», and «https»), HttpUrl, File, DrawableRes, Drawable, Bitmap.
ImageRequest и ImageLoader — базовые классы из Coil.
С помощью ImageRequest настраиваются параметры загрузки картинки: ссылка, листенеры, политика кеширования и декодинга.
ImageLoader запускает ImageRequest, содержит настройки для работы с изображениями. Как правило он настраивается один раз и переиспользуется во всём приложении.
ImagePainter
PlaceHolder
Skeleton-загрузчики уже давно стали стандартом для многих платформ. Во время загрузки пользователь видит псевдовёрстку экрана: по размеру и форме фигур он может предположить, где будет текст, где — фото, а где — кнопка. Это создаёт у пользователя позитивные впечатления.
Accompanist предлагает несколько реализаций placeholder’ов для создания skeleton загрузчиков:
Базовая — placeholder без анимаций.
Fade — placeholder c fade-анимацией.
Shimmer — placeholder c анимацией мерцания.
Accompanist — крутая поддержка для разработчиков на старте внедрения Compose
У Accompanist ещё не вышла версия 1.0, а инструментарий библиотеки уже достаточно богатый и поможет обойти кучу граблей.
Стоит заметить, что Accompanist — не единственная библиотека, которая поможет в поддержке и интеграции с Compose. Уже есть интеграция Compose c Hilt, Rx, Jetpack Navigation, Jetpack Paging. В Lottie 4.0.0 тоже добавили поддержку Compose.
Патчим AndroidX
На Google I/O 2018 была представлена замена существующим support-библиотекам — AndroidX
Изначально, support-библиотеки разрабатывались для обратной совместимости новых API-интерфейсов и были тесно связаны с операционной системой. Разработка support-библиотек велась во внутренних ветках, которые периодически вливались в Android Open Source Project (AOSP). Такой подход ограничивал мерж пулл-реквестов от сообщества небольшими отрезками времени когда код AOSP и внутренний код гугла были синхронизированы. Кроме того, для работы с support библиотеками необходимо было выкачивать весь код платформы, а это более 40ГБ исходного кода. Для моего диска объемом 250 ГБ это достаточно много.
Текущий функционал support-библиотек гораздо шире изначальной задумки. Например, там реализован компонент для упрощения разработки пользовательского интерфейса AppCompat, компонент для работы с базами данных Room, компонент для фоновых задач WorkManager. Многие из этих библиотек изначально имеют обратную совместимость и слабо привязаны к Android API. Цифра в номере support-библиотеки означает минимальный уровень API, который она поддерживает. Например, support-v7 поддерживает Android API версии 7 и выше. Однако, начиная с версии 26.0.0 support-библиотеки поддерживают Android API 14 и выше. Отдельную боль доставляет необходимость одновременного обновления всех support-библиотек. Все это указывает на то, что support-библиотеки изжили себя и нуждаются в переосмыслении.
Команда разработчиков потратила несколько лет на выделение support-библиотек в отдельный небольшой проект, с которым можно работать используя Android Studio и Gradle. Разработка была перенесена в отдельную ветку, которая на днях стала публичной. Обновленные библиотеки получили название AndroidX. Еще одно важное отличие новых библиотек состоит в возможности независимого обновления. Гугл обещает бинарную совместимость в рамках одной мажорной версии, что позволит использовать в проекте recyclerview версии 1.0 и AppCompat версии 1.9 в одном проекте.
На мой взгляд, это правильный и логичный шаг в развитии support-библиотек. Мне приходилось несколько раз сильно кастомизировать компоненты из support-библиотек, что приводило к необходимости создавать в моем проекте пакет com.android.support… для доступа к package-private классам/методам/полям.
Сейчас я предлагаю вместе со мной “хакнуть” какую-нибудь библиотеку из семейства AndroidX. В качестве учебного пособия я выбрал CardView. Я собираюсь повлиять на поведение CardView не внося изменений в код, использующий его.
Нам потребуется: Компьютер под управлением Linux или MacOS (Windows не поддерживается), Android SDK, опционально — Android Studio ( я использовал версию 3.1.3)
Для начала, я подготовил небольшой пример с использованием AndroidX.
В итоге получаем следующее приложение:
Приступим к AndroidX
Сперва, необходимо установить утилиту repo, созданную для упрощения работы с гитом в контексте андроида.
Создадаем рабочую папку для наших манипуляций, хотя можно использовать и домашнюю директорию.
Поясню, что мы сейчас сделали:
В папке androidX создали папку repo, куда скачали файл по ссылке https://storage.googleapis.com/git-repo-downloads/repo, сделали файл исполняемым и добавили папку bin в PATH в рамках текущей сессии терминала.
В моем случае последняя команда выглядела так: PATH=
Качаем исходники AndroidX:
Создаем в папку androidX/androidX-source и делаем ее текущей
Инициализируем локальный репозиторий. Скачается примерно 16 мегабайт данных о существующих ветках в репозитории.
В процессе имя и почта пользователя подтянется из глобального конфига гита, в моем случае, это выглядело так:
На последний вопрос я ответил утвердительно.
В конце получаем сообщение
Далее скачиваем непосредственно исходники (примерно 3 гигабайта)
Скачанные исходники мы можем открыть в Android Studio или любом другом редакторе. Корневая папка gradle-проекта находится по адресу: androidX/androidX-source/frameworks/support/
Там множество модулей с разными фичами и несколько тестовых приложений. Можем их собрать и установить для проверки работоспособности.
Открываем класс androidx.cardview.widget.RoundRectDrawable в модуле cardview
Добавим безобидную шутку в метод onDraw
Для проекте описана gradle-таска createArchive, которая соберет библиотеки androidX и разместит их в локальном мавен-репозитории. Адрес репозитория: androidX/androidX-source/out/host/gradle/frameworks/support/build/support_repo
Для его использования необходимо указать путь в корневом билд-файле.
Обратите внимание, что собранная версия может быть новее чем в репозитории гугла. На момент написания статьи я собрал androidX библиотеку версии 1.0.0-rc01. Посмотреть версию собранной библиотеки можно в локальном мавен репозитории: androidX/androidX-source/out/host/gradle/frameworks/support/build/support_repo/androidx/cardview/cardview/maven-metadata.xml
Пересоберем наше приложение и увидим следующую картину:
AndroidX успешно пропатчен!
Android Support Library: немного о версионности
Mar 11, 2018 · 4 min read
Существуют такие вещи, о которых обычно не говорят: почему небо голубое, когда мне поднимут зарплату и наша любимая android.support.library. У всех них есть нечто общее: мы встречаемся с ними каждый день, но никогда не интересуемся как они устроены внутри и почему все именно так, как есть — примитивное великолепие.
Зачем мы это используем
При разработке приложений, мы часто хотим видеть одинаковую работу нашего кода на разных версиях устройств. Вместо того, чтобы писать код поддержки для ранних версий Андроид, нам достаточно взять готовую реализацию из Support Library и заняться более важными задачами (таски же должен кто-то закрывать).
Однако т а к было ранее, ведь сейчас, библиотека поддержки это куда больше, чем куча if else с проверкой версионности. Она содержит в себе такие полезные view как:
Как строится нейминг библиотек
В документации можно видеть список всех доступных для подключения библиотек с их кратким описанием.
Большинство библиотек поддержки имеет префикс, который ПО-СЛУХАМ говорит о минимальной версии андроид, необходимой для её работы.
Подключаются они все примерно одинаково:
за исключением того, что у библиотек v4 отсутствует префикс)) Добро пожаловать в мир андроид разработки, здесь довольно часто в порядке вещей делать, казалось бы, одну и ту же вещь по разному. Даже гугл не стремается, нам то уж чего.
com.android.support:appcompat-v7 тянет за собой целый ворох различных зависимостей (даже архитектурных. а вы тут всё “какааая архитектура в ондроид”)
и некоторые из этих библиотек мне не нужны, к примеру фрагменты и все её дочерние 13 зависимостей. Вместо них я использую обычные view (на примере Conductor) и кастомный роутинг (на примере Cicreone). Давайте посмотрим, сколько места нам удасться сэкономить если мы их отключим:
Согласно dex-count наши фрагменты занимают 1740 методов.
Отключаем их простой командой из gradle
Давайте глянем на логи и разберемся:
В принципе оно и логично, зачем пихать в зависимости то, что нигде не используется. А тут прихожу какой-то я и начинаю все отключать не разобравшись. Ну теперь-то разобрался, надеюсь разобрались и вы.
Помимо этого, была замечена вот какая штука
Обратившись к документации мы видим очень явную и понятную строчку, прочитав которую не было бы этой статьи, отнявшей у вас время:
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.
Проверяем и убеждаемся
Расследование можно считать закрытым. Спасибо за внимание!