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


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


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


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


    • Рассмотрим основные понятия тем и стилей в Android-приложениях, посмотрим какие возможности они нам предоставляют;
    • Создадим простейшую тему с использованием Material Components и поиграемся с переопределением стилей;
    • Разберемся, как работает темная тема;
    • Сформулируем рекомендации для работы со стилями.

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


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


    <style name="MyStyleOrTheme">
        <item name="key">value</item>
    </style>

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


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


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


    Тема


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


    Пример темы:


    <style name="Theme.MyApp.Main" parent="Theme.MaterialComponents.Light.NoActionBar">
        <!--Base colors-->
        <item name="colorPrimary">@color/color_primary</item>
        <item name="colorPrimaryVariant">@color/color_primary_variant</item>
        <item name="colorSecondary">@color/color_secondary</item>
    
        <item name="colorOnPrimary">@color/color_on_primary</item>
        <item name="colorOnError">@color/color_on_error</item>
    
        <!--Style attributes-->
        <item name="textAppearanceHeadline1">@style/TextAppearance.MyTheme.Headline1</item>
        <item name="bottomSheetDialogTheme">@style/ThemeOverlay.MyTheme.BottomSheetDialog</item>
        <item name="chipStyle">@style/Widget.MaterialComponents.Chip.Action</item>
        <item name="textInputStyle">@style/Widget.MaterialComponents.TextInputLayout.FilledBox</item>
    
        <!--Params-->
        <item name="android:windowTranslucentStatus">true</item>
    
        <!-- ... -->
    </style>

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


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


    Стиль


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


    Пример стиля для TextInputLayout:


    <style name="Widget.MyApp.CustomTextInputLayout" parent="Widget.MaterialComponents.TextInputLayout.FilledBox">
        <item name="boxBackgroundMode">outline</item>
        <item name="boxStrokeColor">@color/color_primary</item>
        <item name="shapeAppearanceOverlay">@style/MyShapeAppearanceOverlay</item>
    </style>

    Атрибут


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


    colorPrimary
    colorSecondary
    colorOnError
    boxBackgroundModе
    boxStrokeColor
    shapeAppearanceOverlay
    ...

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


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


    <attr name="myFavoriteColor" format="color|reference" />

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


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


    • color
    • reference
    • string
    • enum
    • fraction
    • dimension
    • boolean
    • flags
    • float
    • integer

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


    <style name="Theme.MyApp.Main" parent="Theme.MaterialComponents.Light.NoActionBar">
        <!-- ... -->
        <item name="myFavoriteColor">@color/color_favorite</item>
    </style>

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



    1 — указывает на то, что мы ищем в теме;
    2 — namespace для поиска (системный ресурс или Material Components Library);
    3 — указывает на то, что мы ищем атрибут (опционально);
    4 — имя атрибута.
    

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


    <androidx.appcompat.widget.AppCompatTextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textColor="?attr/myFavoriteColor"/>

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


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


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


    • Explicit (явно)
    • Implicit (неявно)

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


    <style name="SnackbarStyle" parent="Widget.MaterialComponents.Snackbar">
        <!-- ... -->
    </style>

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


    <style name="SnackbarStyle.Green">
        <!-- ... -->
    </style>

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


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


    <style name="Widget.MyApp.Snackbar" parent="Widget.MaterialComponents.Snackbar">
        <!-- ... -->
    </style>

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


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


    ThemeOverlay


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


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


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



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


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


    • Переопределить стиль?


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

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


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

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


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


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


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


    <style name="ThemeOverlay.MyApp.Login" parent="ThemeOverlay.MaterialComponents.TextInputEditText">
        <item name="colorPrimary">@color/colorBrown</item>
    </style>

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


    <com.google.android.material.textfield.TextInputLayout
            android:theme="@style/ThemeOverlay.MyApp.Login"
            android:hint="Login"
            ... >
    
            <com.google.android.material.textfield.TextInputEditText
            ... />
    
    </com.google.android.material.textfield.TextInputLayout>
    

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



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


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


    ../LayoutInflater.java
    final TypedArray ta = context.obtainStyledAttributes(attrs, ATTRS_THEME);
    final int themeResId = ta.getResourceId(0, 0);
    if (themeResId != 0) {
        context = new ContextThemeWrapper(context, themeResId);
    }
    ta.recycle();

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


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



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


      <Button
              android:textColor="@color/colorRed"
              ... />

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


      <Button
              style=“@Widget.MyApp.ButtonStyle"
              ... />

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


      <style name="Theme.MyApp.Main" parent="Theme...">
          <item name=“materialButtonStyle”>@Widget.MyApp.ButtonStyle</item>
          <!-- ... -->
      </style>

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


      <style name="Theme.MyApp.Main" parent="Theme...">
          <item name=“colorPrimary”>@colorPrimary</item>
          <!-- ... -->
      </style>


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


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


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


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




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


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


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


    Theme.MaterialComponents
    Theme.MaterialComponents.NoActionBar
    Theme.MaterialComponents.Light
    Theme.MaterialComponents.Light.NoActionBar
    Theme.MaterialComponents.Light.DarkActionBar
    Theme.MaterialComponents.DayNight
    Theme.MaterialComponents.DayNight.NoActionBar
    Theme.MaterialComponents.DayNight.DarkActionBar

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


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


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


    <!-- ... -->
    Theme.MaterialComponents.Light.Bridge
    <!-- ... -->

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


    <style name="Theme.MyApp.Main" parent="Theme.MaterialComponents.Light.NoActionBar">
        <item name="colorPrimary">@color/color_primary</item>
        <item name="colorPrimaryVariant">@color/color_primary_variant</item>
        <item name="colorSecondary">@color/color_secondary</item>
        <item name="colorSecondaryVariant">@color/color_secondary_variant</item>
    <style>

    Имена основных цветов (brand-цветов) претерпели изменения:


    colorPrimary — наиболее часто используемый цвет в приложении (как и в AppCompat);
    colorPrimaryVariant — оттенок основного цвета (аналог colorPrimaryDark из AppCompat);
    colorSecondary — второй по частоте использования цвет в приложении (аналог colorAccent из AppCompat);
    colorSecondaryVariant — оттенок вторичного цвета.

    Дополнительную информацию по цветам можно найти на material.io.


    Я уже упоминал, что тема содержит стандартные стили для каждого View-компонента. Например, для Snackbar стиль будет называться snackbarStyle, для checkboxcheckboxStyle и далее все по аналогии. Пример расставит все на свои места:



    Создадим свой стиль и применим его к теме:


    <style name="Theme.MyApp.Main" parent="Theme.MaterialComponents.Light.NoActionBar">
        <!-- ... -->
        <item name="snackbarStyle">@style/Widget.MyApp.SnackbarStyle</item>
    </style>
    
    <style name="Widget.MyApp.SnackbarStyle" parent="Widget.MaterialComponents.Snackbar">
        <!-- ... -->
    </style>

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


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


     <com.google.android.material.button.MaterialButton
            style="@style/Widget.MyApp.SnackbarStyle"
            ... 
    />

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


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


    • shapeAppearanceSmallComponent


    • shapeAppearanceMediumComponent


    • shapeAppearanceLargeComponent



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



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


    <style name="Theme.MyApp.Main" parent="Theme.MaterialComponents.Light.NoActionBar">
        <!-- ... -->
        <item name="shapeAppearanceSmallComponent">@style/Widget.MyApp.SmallShapeAppearance</item>
     </style>
    
    <style name="Widget.MyApp.SmallShapeAppearance" parent=“ShapeAppearance.MaterialComponents.SmallComponent”>
        <item name="cornerFamilyTopLeft">rounded</item>
        <item name="cornerFamilyBottomRight">cut</item>
        <item name="cornerSizeTopLeft">20dp</item>
        <item name="cornerSizeBottomRight">15dp</item>
        <!--<item name="cornerFamily">cut</item>-->
        <!--<item name="cornerSize">8dp</item>-->
    </style>

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


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



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


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


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


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


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


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


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


    <style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
        <!-- ... -->
        <item name="android:forceDarkAllowed">true</item>
    </style>

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


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



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


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


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


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


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


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


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


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


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


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


    ../values/themes.xml
    <style name="Theme.DayNight.Base" parent="Theme.MaterialComponents.Light"/>
    
    <style name="Theme.MyApp.Main" parent="Theme.DayNight.Base>
        <!-- ... -->
    </style>
    
    ../values-night/themes.xml
    <style name="Theme.DayNight.Base" parent="Theme.MaterialComponents"/>

    В обычном ресурсе для темы (values/themes.xml) мы наследуемся от светлой темы, в "ночном" (values-night/themes.xml) ресурсе наследуемся от темной темы.


    На этом все. Мы получили библиотечную реализацию темной темы. Теперь нам следует поддерживать ресурсы для двух тем.


    Чтобы переключаться между темами во время работы приложения можно воспользоваться AppCompatDelegate.setDefaultNightMode, который принимает следующие параметры:


    • MODE_NIGHT_NO — Светлая тема;
    • MODE_NIGHT_YES — Темная тема;
    • MODE_NIGHT_AUTO_BATTERY — Автоматический режим. Включается темная тема, если активен режим энергосбережения;
    • MODE_NIGHT_FOLLOW_SYSTEM — Режим на основе системных настроек.

    Что нам следует учитывать при работе с темами и стилями?


    Как я уже отметил, Google начал официально форсить темную тему. Уверен, что от многих заказчиков начали поступать вопросы — «Сможем ли мы добавить темную тему?». Хорошо, если вы с самого начала все делаете правильно и вам не составит труда поменять светлые цвета на темные, получив при этом полностью перекрашенное приложение.


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


    Давайте вместе попытаемся сформулировать рекомендации для работы со стилями:


    1. Палитра цветов


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


    Правильный ответ — поговорить с дизайнером и попытаться выработать палитру цветов. Сейчас есть множество программ (Zeplin, Sketch и др.), которые позволяют вынести основные цвета и потом переиспользовать их.


    Чем раньше вы этим займетесь, тем меньше у вас будет головной боли в дальнейшем.


    2. Называть цвета своими именами


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


    <color name="green_tiny">...</color>
    <color name="green_light">...</color>
    <color name="green_dark">...</color>

    Согласитесь, выглядит не очень. Сразу возникает вопрос — какой цвет светлее tiny или light? А если у нас будет десяток вариантов?


    Лучше всего придерживаться концепции Google и добавить в имена цветов соответствующую яркость (Google называет это вариантом цвета — colorVariant):


    <color name="material_green_300">...</color>
    <color name="material_green_700">...</color>
    <color name="material_green_900">...</color>

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


    3. Абстрагироваться от конкретного цвета, если он меняется в разных темах


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


    Давайте рассмотрим пример:



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


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


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


    4. Не бояться создавать ресурсные файлы


    Когда в файле styles.xml набирается много различных стилей, тем и атрибутов, то его становится сложно поддерживать.


    Лучше всего разнести все по группам в отдельные файлы:


    themes.xml — Theme & ThemeOverlay
    styles.xml — Widget styles
    type.xml — TextAppearance, text size etc
    shape.xml — ShapeAppearance
    motion.xml — Animations styles
    system_ui.xml — Booleans, colors for UI control
    //may be other files

    Такое простое правило позволит избежать God-файлов и, следовательно, будет проще поддерживать стили.


    5. Переиспользовать по максимуму


    Как мы поступим, если захотим переопределить атрибут, который доступен только с определенной версии API?


    Мы можем создать две отдельные темы:


    ../values/themes.xml
    <style name="Theme.MyApp.Main" parent=”Theme.MaterialComponents.NoActionBar”>
        <!--Many definition-->
    </style>
    
    ../values-v27/themes.xml
    <style name="Theme.MyApp.Main" parent=”Theme.MaterialComponents.NoActionBar”>
        <!--Many definition-->
        <name="android:windowLightNavigationBar">...</item>
    </style>

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


    ../values/themes.xml
    <style name="Theme.MyApp.Base" parent=”Theme.MaterialComponents.DayNight.NoActionBar”>
        <!--Many definition-->
    </style>
    
    <style name="Theme.MyApp.Main" parent=”Theme.MyApp.Base”/>
    
    ../values-v27/themes.xml
    <style name="Theme.MyApp.Base.V27" parent="Theme.MyApp.Base">
        <name="android:windowLightNavigationBar">...</item>
    </style>
    
    <style name="Theme.MyApp.Main" parent=”Theme.MyApp.Base.V27”/>

    По такому принципу построены все темы в стандартной библиотеке.


    6. Использовать векторные ресурсы и tint


    Думаю, не стоит говорить почему векторные ресурсы — это хорошо. Все и так знают (на всякий случай ссылка на документацию). Ну а tinting поможет нам окрасить их в цвета темы.


    Посмотреть что такое tinting и как с ним работать можно в этом примере.


    7. ?android:attr/… vs ?attr/...


    При обращении к ресурсам у нас есть возможность использовать как системные атрибуты, так и атрибуты из библиотеки Material Components. Важно понимать, что некоторые атрибуты существуют только с определенной версии API. Как мы все хорошо знаем, обращение к несуществующему ресурсу ведет к крэшу (lint, конечно, нам подскажет если что-то не так, но не стоит всегда полагаться на него)


    android:background="?android:attr/selectableItemBackgroundBorderless"
    
    android:background="?attr/selectableItemBackgroundBorderless"

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


    Лучше всегда использовать второй вариант.


    8. Всегда указывать родителя для стиля


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


    <style name="Widget.MyApp.LoginInputLayout" parent="Widget.MaterialComponents.TextInputLayout.FilledBox">
        <item name="errorTextColor">@color/colorError</item>
    </style>

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


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


    <style name="Theme.MyApp.Main" parent=”...”/>
    
    <style name="Widget.MyApp.LoginInputLayout" parent="..."/>
    <style name="Widget.MyApp.LoginInputLayout.Brown"/>
    
    <style name="ThemeOverlay.MyApp.Login" parent=”...”/>

    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, чтобы все сразу попробовать на практике.


    Полезные ссылки:


    Redmadrobot
    268,72
    №1 в разработке цифровых решений для бизнеса
    Поделиться публикацией

    Комментарии 10

      0
      Хех, только на выходных видео смотрел которое судя по всему было источником для этой статьи, спасибо, текстом лучше.
        0
        Положение ThemeOverlay в иерархии осталось непонятным.
          0
          Напишите, пожалуйста, поподробнее, что вы имеете в виду. Я постараюсь дополнить статью.
            0
            В разделе «Последовательность применения тем и стилей ко View-компоненту» ThemeOverlay в иерархии отсутствует.
            Как изменения атрибутов в ThemeOverlay повлияют? Что именно будет затронуто? В чем отличие от Theme?
              0

              При применении ThemeOverlay мы меняем атрибуты темы только для одной View.


              Представьте, что есть тема с параметрами attr1, attr2, attr3, attrN и мы применяем ThemeOverlay, где определен только параметр attr2. ThemeOverlay будет наложен на текущую тему и заменит в ней только attr2. Все остальные параметры останутся без изменений.


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

          0
          А как кто решает проблему первого кадра при запуске приложения с разными темами?
          Ведь если тема у приложения указана в манифесте, то ОС берет из неё цвет бэка, заливает фон, а уж потом запускает Application.onCreate() и так далее.
          Уж очень много приложений, показывающих белый экран пока приложение грузится, а потом уже сменяющих тему на тёмную.

          П.С.: Мы решили это прозрачной темой приложения, но в таком случае кажется, что приложение тормозит и слишком долго стартует после нажатия на иконку.
            0
            Можно использовать в качестве фона какой нибудь акцентный цвет который присутствует во всем приложении
              0
              Средний, между тёмным и светлым? Да, я изначально так сделал. Потом это не понравилось новому дизайнеру.
              0
              В стилях определяется отдельная тема с windowBackground для launch экрана.
                <style name="AppTheme" parent="Theme.Base"/>
              
                <style name="AppTheme.Launch">
                  <item name="android:windowBackground">@drawable/bg_launch_screen</item>
                </style>
              


              В манифесте базовой активити сеттится AppTheme.Launch тема, а в onCreate сеттится основная тема
              override fun onCreate(savedInstanceState: Bundle?) {
                setTheme(R.style.AppTheme)
                super.onCreate(savedInstanceState)
                setContentView(R.layout.main_activity)
                ...
              }
                0
                Ага, и если главный цвет приложения зелёный, то делать зелёный сплэш? А тем, у кого красный основной? :)

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

            Самое читаемое