Я рассматривал аналог стилей, реализованный на databinding. Т.е. делаем свой адаптер и внутри прописываем нужные параметры. Но решил, что пока это перебор.
Собирался задействовать такой способ, но у него оказался один минус. Databinding работает только в рамках layout, в стилях его не применить. Например, в приложении более 100 textview, размер, тип и цвет стандартизирован и вынесен в стили. Чтобы задействовать databinding, надо выносить цвет из стилей.
Оставил эту идею, как резервную, на случай, если текущая реализация подведет.
По сути, сейчас сделано похожим образом. Просто перекраска происходит внутри LayoutInflater, в нем есть доступ к создаваемым View и их аттрибутами из xml. Как следствие, внутри самих Activity надо дописать только обертку надо контекстом.
С shape drawable были проблемы в плане получения id цветов для них, так как сам shape их не хранит. Была идея, что каждый id будет ссылаться на уникальный цвет, а потом программно изменять его на нужный. Но в итоге для перекраски shape тянется его xml и id цветов берётся оттуда.
От велосипеда в Resources я отказался поностью.
Касаемо второго вашего способа. Спасибо. Я отстал от жизни и databinding не использовал вообще. Метод гибкий и его можно поставить в альтернативу LayoutInflater. На этой неделе посмотрю.
Обычно да.
Если в рамках одного приложения, то через стили.
Если твое приложение имеет несколько вариаций (код один, но приложения разные, собраны для разных заказчиков, различаются содержанием и цветовой схемой), то можно использовать productFlavors.
Но в данном случае суть в том, что заказчик может изменить цветовую схему на сервере (вдруг решил, что черный шрифт — плохо, хочет темно-синий) и она поменяется у тебя в приложении без перевыпуска его в Market
Так и делалось. Есть скрипт, который парсит данные, предоставленные заказчиком, и создает нужные xml (там не только цвета).
Но за последнее время были случаи, когда заказчик хотел изменить, например, цвет заголовков в списках или логотип в ActoinBar. Ради этих изменений приходится перевыпускать приложение. Для Android это не особо критично, а вот с iOS беда.
Отсюда всё и пошло. Хотя пока этот функционал ещё не внедрен и мне не особо хочется нагружать им приложение.
Под «70 цветов» подразумевается количество констант в colors.xml. Самих цветов обычно 15-20. Например, для текстовых полей используется 7 констант:
2 для фона (градиент);
3 для рамки (есть фокус, нет фокуса, введено неверное значение);
2 для текста (обычный и подсказки).
Но цвет текста обычно соответствует цвету заголовков, цвет рамки в фокусе – основному цвету темы, фон – белый без градиента.
Это сделано для гибкой настройки. Так как один из заказчиков может захотеть выделить кнопки в диалоге отличным от основной темы цветом. Другой – увидеть градиент в Action Bar, но только там, чтобы остальные элементы были без.
Оставил эту идею, как резервную, на случай, если текущая реализация подведет.
С shape drawable были проблемы в плане получения id цветов для них, так как сам shape их не хранит. Была идея, что каждый id будет ссылаться на уникальный цвет, а потом программно изменять его на нужный. Но в итоге для перекраски shape тянется его xml и id цветов берётся оттуда.
От велосипеда в Resources я отказался поностью.
Касаемо второго вашего способа. Спасибо. Я отстал от жизни и databinding не использовал вообще. Метод гибкий и его можно поставить в альтернативу LayoutInflater. На этой неделе посмотрю.
Если в рамках одного приложения, то через стили.
Если твое приложение имеет несколько вариаций (код один, но приложения разные, собраны для разных заказчиков, различаются содержанием и цветовой схемой), то можно использовать productFlavors.
Но в данном случае суть в том, что заказчик может изменить цветовую схему на сервере (вдруг решил, что черный шрифт — плохо, хочет темно-синий) и она поменяется у тебя в приложении без перевыпуска его в Market
Но за последнее время были случаи, когда заказчик хотел изменить, например, цвет заголовков в списках или логотип в ActoinBar. Ради этих изменений приходится перевыпускать приложение. Для Android это не особо критично, а вот с iOS беда.
Отсюда всё и пошло. Хотя пока этот функционал ещё не внедрен и мне не особо хочется нагружать им приложение.
Но цвет текста обычно соответствует цвету заголовков, цвет рамки в фокусе – основному цвету темы, фон – белый без градиента.
Это сделано для гибкой настройки. Так как один из заказчиков может захотеть выделить кнопки в диалоге отличным от основной темы цветом. Другой – увидеть градиент в Action Bar, но только там, чтобы остальные элементы были без.