Цветовые схемы и методы распараллеливания

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

Цветовые схемы Figma и Flutter

Если разработчики нашли общий язык с дизайнерами, то можно создавать ошеломляюще красивые приложения. Но на практике разработчики чаще всего недовольны дизайнерами. Мол, нарисовали то вы красиво, а как это воплотить в коде? Чтобы этого избежать, стоит начать с малого — выработать одинаковый подход к использованию цветовых схем.

Разработку дизайна имеет смысл начать с виджета Theme и класса ThemeData. В этом классе доступно для настройки около 60 цветов. Проще всего создать экземпляр класса ThemeData из СolorScheme. После того, как класс ThemeData создан, большая часть приложения уже будет «раскрашена» без необходимости указывать цвет для каждого конкретного виджета.

Это удобно, поскольку можно заранее создать несколько тем и легко задавать переключение между ними (например, тёмная и светлая темы). 

Для этого необходимо отобрать и определить минимум 10 цветов. В схемах Material 3 цвета идут парами: цвет элемента — цвет текста (или другого контента). Стоит дать каждому цвету название, что позволит при обсуждениях ссылаться на них, а не на HEX-коды. При этом несколько цветов с разными именами могут использовать одно и тоже шестнадцатеричное значение.

Важно это сделать правильно и осмысленно, исключив имена, характеризующие оттенок. Не стоит называть цвет LightGray, если он будет переключаться на White при смене темы со светлой на тёмную. Все цвета добавляются в цветовые стили Figma и они же будут использованы для всех элементов дизайна.

Теперь разработчики могут легко создать экземпляр класса из схемы:

ThemeData.from(colorScheme: colorScheme)

Ну а чтобы узнать больше полезных советов, рекомендуем прочитать статью Color Schemes – Figma to Flutter Design Implementation в блоге компании Infinum.

Isolate vs Compute

Плавные анимации и отзывчивость нравятся пользователям мобильных приложений, что косвенно увеличивает доход. Оптимизировать приложение и увеличить его производительность можно с помощью методов параллельной обработки. Во Flutter для этого часто используется два подхода: Isolate и Compute. Между ними есть существенная разница и нужно понимать, когда стоит использовать каждый.

Isolate — это функция, способная запустить любой код на Dart в отдельном изолированном потоке. Такой код будет работать в выделенном пространстве памяти и выполнять вычисления параллельно пользовательскому интерфейсу. Главный поток не блокируется, а значит нет влияния на скорость отклика интерфейса. Таких изолированных потоков может быть несколько и они могут передавать друг другу данные.

Эта функция отлично подходит для «тяжёлых» задач, например, для сложных вычислений, обработки изображений или парсинга данных. Но что делать, если нужно реализовать изоляцию только одной функции, а не большого куска кода? Здесь пригодится вторая функция — Compute. Она берёт одну конкретную функцию и автоматически запускает её параллельно основному потоку.

Получается облегчённая версия механизма Isolate, которая способна точечно распараллелить задачи в полностью автоматическом режиме. Это подойдёт для простых манипуляций с данными, конвертирования форматов данных и сортировки списков. Здесь меньше возможностей контроля, но одновременно и меньше общий уровень сложности.

Оба способа по-своему хороши. Isolate отлично справится с тем, чтобы выполнять ресурсоёмкие задачи отдельно от основного потока. Он мощный, гибкий в настройке и позволяет вручную задать желаемые параметры работы. Compute, напротив, позволяет без особых проблем выделить какую-либо функцию и автоматически пустить её отдельным потоком.

Избегаем ошибок с помощью DCM

Все программисты совершают ошибки. Это часть их большого путешествия в мир разработки, им приходится с этим справляться. К счастью, им в помощь есть множество полезных инструментов. Flutter-разработка не исключение и сегодня мы хотим поговорить про DCM (Dart Code Metrics).

Это инструмент для выполнения статического анализа кода, расширяющий возможности штатного Dart Analyzer. Он позволяет проверить качество и согласованность данных, снижая потенциальное количество багов.

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

Как и другие языки со статической типизацией, Dart заточен на то, чтобы гарантировать правильность работы кода. Но иногда система типизации Dart больше вредит, чем помогает. Некоторые методы сбора данных, такие как contains, remove и difference создают пространство для возникновения ошибок, если программист не будет предельно внимателен. Так, например, следующий код кажется вполне безобидным:

final map = Map<int, String>();
map.containsKey("str")

Но при проверке выяснится, что map может иметь только int-ключи, а вовсе не str. Это лишь одна из десятков возможных ситуаций, в которых статический анализ может помочь. Программисты всё чаще используют большие языковые модели, такие как ChatGPT, для генерации кусков кода. Это повышает риск внести незаметные ошибки и уязвимости. Статический анализ позволяет управлять и этими рисками, сохраняя высокое качество.

 

 

Митапы