Что такое appcompat android

Activity vs AppCompatActivity

Начал разбираться с андроидом и сразу встал вопрос сабжа. AppCompatActivity не нравится такое имя, сразу какая-то устарелость ассоциируется, в приложение тянется мегабайтная библиотека. Судя по гуглу если я буду использовать Activity, то в 4-м андроиде у меня не будет Material L&F, в принципе я и не против, он мне нафиг не нужен. Ещё одни пишут про какие-то мифические багфиксы в этом compat, другие пишут про то, что эти багфиксы конфликтуют с китайскими андроидами (а мне надо, чтобы работало везде нормально), в общем фиг пойми. Какие ещё могут быть доводы в пользу AppCompatActivity?

Примерно такой же вопрос про ConstaintLayout. Тоже тянет библиотеку на 200 килобайтов, что мне не понравилось. Лэйаут у меня будет несложный, имеет смысл его выкинуть?

Никаких доводов. Аппкомпаты и суппорты — жирное ненужно.

Использовать Material тему можно. Достаточно вызвать setTheme.

а мне надо, чтобы работало везде нормально

Это тебе точно не в Android, без шуток и сарказма. В проде без support жить не очень получается, если его выкинуть — тебе придётся очень сильно прогнуться под суровые реалии и отказываться от того же RecyclerView, а вот без ConstraintLayout жить можно вполне, стандартных Relative/Frame/Linear в несложном UI хватает с головой.

Опять мамкины кодеры подтягиваются. Лол

Уныло, сразу переходить на личности.

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

Фрагменты теперь deprecated из стандартной библиотеки. Юзать нужно теперь только из support библиотеки.

Да и вообще у них теперь не будет support библиотек, переходите на androidx версии.

Писать без appcompat (androidx, что тоже самое, но более kotlin-ориентировано) – это очень изысканный вид извращения.

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

Почему? Можно примеры проблем, с которыми я столкнусь?

ConstaintLayout не нужен. Без AppCompat жить вполне можно, но, как показывает практика сапортные библиотеки вероятней всего втянуть придется, хотя можно и велосипедить.

Сейчас Android SDK (в широком смысле) плавно переходит к следующей модели развития. Android SDK делится на два больших блока библиотек:

• Непосредственно Android SDK. Этот набор инструментов и библиотек обновляется с выходом новой версии Android, и привязан к конкретной версии. Это то что ты указываешь в targetSdk.
• Комплект библиотек appcompat/androidx. Сейчас продвигается бренд Android Jetpack. Библиотеки развиваются отдельно, параллельно Android SDK и созданы для того чтобы предоставлять единый интерфейс и единую функциональность, независимо от конкретной версии Android SDK.

Другими словами, Android SDK – это платформенный низкоуровневый базис, а appcompat и сотоварищи – это непосредственно «кроссплатформенные» инструменты.

Если ты будешь использовать только Android SDK, то ты будешь лишен большей части сторонних библиотек и всех новых компонентов Android Jetpack, которые важны для построения вменяемой архитектуры. И конечно же, тебе руками придётся обеспечивать обратную совместимость.

Советую посмотреть, что сейчас вынесено в библиотеки – https://developer.android.com/jetpack/.

Впрочем, если приложение действительное простое, то возможно, достаточно будет и Android SDK.

Звучит как будто гугл отчаялся обновить ОС на девайсах и решил засунуть часть ОС внутрь каждого приложения 🙂 Примерно понял, хотя всё же хотелось бы конкретных примернов. Библиотеки проглядел, в принципе ничего из перечисленного мне вроде бы не нужно. Приложение простое, два экрана, один HTTP-запрос и пара табличек в локальной БД.

Источник

Патчим 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)

Для скачивания исходников рекомендуется использовать утилиту repo, которая недоступна для Windows. Исходники можно скачать и с использованием git’а, например, так: git clone —single-branch -b androidx-master-dev https://android.googlesource.com/platform/frameworks/support Однако, в данном случае не будут скачаны утилиты и скомпилированные зависимости. Я не проверял насколько это критично для сборки

Для начала, я подготовил небольшой пример с использованием 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 успешно пропатчен!

Что это нам дает:

• Мы можем фиксить критичные проблемы не ожидая апдейта от гугла. Кстати, команда AndroidX принимает пулл-реквесты.
• Сильно кастомизировать androidX библиотеку.

Источник

Темы и стили в Android-приложениях

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

В преддверии выхода темной темы было решено освежить в памяти всю информацию, касающуюся тем и стилей в Android-приложениях.

О чем пойдет речь:

Начнем с основ

По своей структуре темы и стили имеют общее строение:

Для создания используется тег style . У каждого cтиля есть имя и он хранит в себе параметры key-value .

Все достаточно просто. Но в чем же разница между темой и стилем?

Единственное отличие заключается в том, как мы их используем.

Тема — это набор параметров, которые применяются ко всему приложению, Activity или View-компоненту. Она содержит базовые цвета приложения, стили для отрисовки всех компонентов приложения и различные настройки.

В теме переопределены основные цвета приложения ( colorPrimary , colorSecondary ), стиль для текста ( textAppearanceHeadline1 ) и некоторых стандартных компонентов приложения, а также параметр для прозрачного статус-бара.

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

Стиль

Стиль — это набор параметров для стилизации одного View-компонента.

Атрибут

Атрибутом принято называть ключ стиля или темы. Это маленькие кирпичики из которых все строится:

Все эти ключи являются стандартными атрибутами.

Мы можем создавать свои атрибуты:

Атрибут myFavoriteColor будет указывать на цвет или ссылку на ресурс цвета.

В формате мы можем указать вполне стандартные значения:

По своей природе атрибут является интерфейсом. Его необходимо реализовать в теме:

Теперь мы можем на него ссылаться. Общая структура обращения выглядит так:

Ну и, наконец, давайте поменяем, например, цвет текста у поля:

Благодаря атрибутам мы можем добавлять какие-угодно абстракции, которые будут изменяться внутри темы.

Наследование тем и стилей

Как и в ООП, мы можем перенимать функционал существующей реализации. Сделать это можно двумя способами:

При явном наследовании мы указываем родителя с помощью ключевого слова parent :

При неявном наследовании мы используем dot-notation для указания родителя:

Никакой разницы в работе этих подходов нет.

Очень часто мы можем встретить подобные стили:

Может показаться, что стиль создан путем двойного наследования. На самом деле это не так. Множественное наследование запрещено. В таком определении явное наследование всегда выигрывает.

То есть будет создан стиль с именем Widget.MyApp.Snackbar , который является наследником Widget.MaterialComponents.Snackbar .

ThemeOverlay

ThemeOverlay — это специальные «легковесные» темы, которые позволяют переопределить атрибуты основной темы для View-компонента.

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

С основной темой поле ввода выглядит так:

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

Окей, как мы можем решить такую задачу?

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

Написать свою вьюшку по гайдлайнам и с кастомными параметрами?

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

Переопределить основной цвет в теме?

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

Правильное решение — это использовать ThemeOverlay.

Создаем ThemeOverlay и переопределяем основной цвет темы:

Далее указываем его с помощью специального тега android:theme в наш TextInputLayout :

Все работает так, как нам и нужно.

Конечно же возникает вопрос — как это работает под капотом?

Эту магию позволяет провернуть ContextThemeWrapper . При создании View в LayoutInflater будет создан контекст, где за основу будет взята текущая тема и в ней будут переопределены параметры, которые мы указали в нашей Overlay теме.

Аналогичным образом мы можем самостоятельно переопределить любой параметр темы в приложении.

Последовательность применения тем и стилей ко View-компоненту

Главный приоритет имеет файл разметки. Если в нем определен параметр, то далее все аналогичные параметры будут игнорироваться.

Следующий приоритет имеет стиль View:

Далее используются предопределенные стили для компонента:

Если параметры не были найдены, то используются атрибуты темы:

В общем-то это все, что нужно знать для того чтобы начать работу с темами. Теперь кратко посмотрим на обновленную дизайн-библиотеку Material Components.

Да прибудет с нами Material Components

Material Сomponents была представлена на Google I/O 2018 и является заменой Design Support Library.

Библиотека дает нам возможность использовать обновленные компоненты из Material Design 2.0. Кроме того, в ней появилось множество интересных настроек по кастомизации. Все это позволяет писать яркие и уникальные приложения.

Вот некоторые примеры приложений в новом стиле: Owl, Reply, Crane.

Перейдем к практике

Для создания темы нужно отнаследоваться от базовой темы:

Все они очень похожи на AppCompat темы, но имеют дополнительные атрибуты и настройки.

Подробнее с новыми атрибутами можно познакомиться на material.io.

Если по каким-то причинам вы сейчас не можете переключиться на новую тему, то вам подойдут Bridge темы. Они наследуются от AppCompat тем и имеют все новые атрибуты Material Components. Нужно всего лишь добавить постфикс Bridge и использовать все возможности без опасений:

А вот и наша тема:

Важно понимать, что когда вы переопределяете стиль в теме, он применится ко всем View этого типа в приложении (Activity).

Если же вы хотите применить стиль только к одной конкретной View, то нужно использовать тег style в файле с разметкой:

Одно из нововведений, которое меня действительно впечатлило — это ShapeAppearance. Оно позволяет изменять форму компонентов прямо в теме!

Каждый View-компонент относится к определенной группе:

shapeAppearanceSmallComponent

shapeAppearanceMediumComponent

shapeAppearanceLargeComponent

Как мы можем понять из названия, в группах вьюшки разных размеров.

Проверим на практике:

Мы создали Widget.MyApp.SmallShapeAppearance для «маленьких» компонентов. Закруглили верхний левый угол на 20dp и правый нижний угол срезали на 15dp .

Получили такой результат:

Выглядит интересно. Будет ли это работать в реальной жизни? Время покажет.

Как и для стилей, мы можем применить ShapeAppearance только для одного View-компонента.

Что там по темной теме?

Совсем скоро состоится релиз Android Q, а вместе с ним к нам придет и официальная темная тема.

Пожалуй, одна из самых интересных и эффектных возможностей новой версии Android — это автоматическое применение темной темы для всего приложения одной строчкой кода.

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

Разрешаем перекрашивать приложение (по умолчанию запрещено):

Атрибут android:forceDarkAllowed доступен с API 29 (Android Q).

Запускаем, смотрим что получилось:

Согласитесь, что для одной строчки кода выглядит очень круто.

Конечно, есть проблемы — BottomNavigationBar сливается с фоном, лоадер остался белым, выделение кода страдает и, вроде бы, все, по крайне мере мне больше ничего серьезного в глаза не бросилось.

Уверен, что потратив не так много времени, можно решить основные проблемы. Например, отключив автоматический темный режим для отдельных вьюшек (да, так тоже можно — android:forceDarkAllowed доступен для View в файле-разметке).

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

Рекомендации по работе можно почитать в документации и на material.io.

А если мы хотим все делать самостоятельно?

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

В API 8 (Froyo) был добавлен квалификатор -night , который и по сей день используется для применения темной темы. Он позволяет автоматически применять нужную тему в зависимости от времени суток.

В темах DayNight уже используется такая реализация, нам достаточно отнаследоваться от них.

Давайте попробуем написать свою:

Нам теперь на каждую версию API делать тему со всеми параметрами? Нет, конечно! Мы сделаем базовую тему, где будут определены базовые атрибуты, доступные для всех версий API и отнаследуемся от нее в нужной версии API:

9. Тема, стиль или… ?

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

10. Использовать TextAppearance

Хорошим тоном будет расширить основные стили для текста и везде их использовать.

Много полезной информации можно найти на сайте Material Design: Typography, Typography Theming.

Заключение

В заключение хочется сказать, что стилизация приложения — это обязанность не только разработчиков, но и дизайнеров. Только благодаря тесному взаимодействию мы сможем получить по-настоящему хороший и красивый продукт. Дизайнеры должны иметь представления о платформе и возможностях Material Components. Ведь именно на их плечи ложится ответственность по поддержке визуальной составляющей приложения. Дизайнерам доступен специальный плагин для Sketch — Material Theme Editor. В нем очень просто выбирать цвета для приложения и строить экраны на основе стандартных компонентов. Если ваши дизайнеры еще не знают о нем, то обязательно расскажите им.

Начать изучать Material Components можно с репозитория на GitHub — Modular and customizable Material Design UI components for Android. В нем собрано очень много информации по стандартным стилям и их возможностям. Кроме того, там есть приложение — sample, чтобы все сразу попробовать на практике.

Источник