Как стать автором
Обновить

Android-разработчикам: как сократить время реализации тёмной темы с пары месяцев до недели

Время на прочтение21 мин
Количество просмотров13K
Всего голосов 21: ↑20 и ↓1+19
Комментарии7

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

А ведь было время, когда наличие темной (да и любой другой) темы просто не упоминалось. Пренебрежительно скинами обзывали :). А теперь, блин — прям киллерфича :(
А помните, был такой WinAmp…
Мое почтение! Прям по полочкам и со ссылками.
Одно удовольствие такие статьи считать.
Благодарю!

Спасибо! Рад, что вам понравилось)

Первый вариант именования цветов — использование названия цвета как есть: “realblue”, “darkgrey” и так далее.
Этот вариант рекомендует Google. Об этом упоминается в докладе и так сделано в примере Reply.
Но эти имена не надо напрямую использовать в лайаутах и стилях. Надо завести в теме атрибуты, имеющие уже семантические имена и ссылающиеся на цвета, и использовать их.

А ещё textAppearance можно описывать не все атрибуты — например, там нет свойства android:lineSpacingMultiplier.
Меня это тоже расстроило. Но потом оказалось, что в material-component поддерживается lineHeight (ссылка на код).

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

Спасибо за комментарии и за прочтение статьи!


Этот вариант рекомендует Google. Об этом упоминается в докладе и так сделано в примере Reply.
Но эти имена не надо напрямую использовать в лайаутах и стилях. Надо завести в теме атрибуты, имеющие уже семантические имена и ссылающиеся на цвета, и использовать их.

Нашей команде такой вариант не понравился.


Я вообще хотел, чтобы у нас было две палитры цветов.
1) Палитра цветов: "red", "green"…
2) Палитра цветов конпонентов: "tint", "button"...


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


Я думаю, на каждом проекте вы сами должны выбирать, как правильно сделать для вас. Главное, чтобы выбранный вариант нравился всем: дизайнеру, iOS и Android. А я продолжу поиск лучшего решения и, возможно, расскажу о нем в следующей статье.


Меня это тоже расстроило. Но потом оказалось, что в material-component поддерживается lineHeight (ссылка на код).

Да, но lineHeight не работает для текстовых полей с одной строкой. Я решил эту проблему с помощью minHeight, а его нет в TextAppearance. Список всех атрибутов TextAppearance можно посмотреть тут.


Но опять же, выбирайте то, что удобно именно вам. Я собрал список источников, где можно посмотреть полную информацию о работе с TextAppearance.


Вопрос не по теме. В вашей компании есть опыт использования скриншотов для автоматизации тестирования?

Я настроил запуск эмуляторов на GitLab CI. Работает не идеально, но тесты запускать можно. Мы эксперементировали cо скриншотным тестированием в Android-отделе, но на реальных проектах пока не делали. iOS-команда, с помощью скриншотного тестирования, автоматически собитает скриншоты для стора, но сами тесты не используют.


Мы сейчас работаем над тем, чтобы запускать UI-тесты на большей части проектов. UI-тесты помогают сократить регрессионное тестирование. А данную проверку мы делаем ручным тестированием.


Кстати, на этом проекте iOS-команда вместе с QA покрыли UI-тестами всё, что только можно было замокать. А в Android пока только пару сценариев, но мы не давно начали их писать и, надеюсь, кол-во тестов будет увеличиваться.

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