Привет!

Я — Сергей Кольцов, с 2020 года Flutter разработчик в команде мобильного приложения Яндекс Про.

Помимо своих прямых рабочих обязанностей, я помогаю всем желающим встать на путь Flutter-ниндзя: несу Flutter в массы студентов Школ Мобильной Разработки от Яндекса, Университета Иннополис, менторю в личных встречах, ну и с некоторой регулярностью участвую в конференциях и митапах.

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

Если вы оказались в этом канале, то очень вероятно, что мы очно или заочно пересекались: на занятиях, менторских встречах или конференциях.

Ещё раз привет и спасибо, что заглядываете!

Универсальный ответ на вопросы "С чего начать?" и "Как систематизировать знания?": плейлист с лекциями по Flutter от Яндекса.

Это сборник из лекций со Школ Мобильной Разработки 2021 и 2022 годов. Лекции сгруппированы по темам и по порядку усложнения. В части лекций материал повторяется, но большинство — органично дополняют друг друга.

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

#edu

Вариантов организации структуры проекта куча, нет строго правильного, и часто зависит от конкретных задач. Но после разных экспериментов, мне понравилась вот такая feature-first структура. Это не истина в последней инстанции, но неплохо подойдет в качестве опорной точки, плюс хорошо структурирует понимание существующих частей и их взаимосвязей.

app
Объединяет приложение воедино. Роутинг, сборка зависимостей и обработка ошибок. Слой app потенциально знает обо всех слоях приложения, но при этом остальные слои не знают об app.

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

data
Обработка сырых данных, API-клиент. Прямая работа с сервером или локальной базой данных. Data-слой может зависеть только от core-слоя.

features
Содержит фичи любого рода. Можно выделить фичи двух видов:
1. Функциональные — фичи без продуктового смысла. Такие фичи не должны зависеть от продуктовых фичей.
2. Продуктовые — фичи, отвечающие за определённую бизнес-логику. Такие фичи могут зависеть от функциональных фичей.

Каждая фича может содержать как только бизнес-специфичные сущности, так и вложенное дробление по слоям data и ui, но обязательно непосредственно связанные с этой фичой.

Знает о существовании data-слоя, но не знает о существовании screens.

screens
Экраны приложения. Могут быть сгруппированы по пользовательским сценариям. Слой screens использует слой features. Допустимо, чтобы screens знал о слое app — через который предоставляется доступ к продуктовым фичам.

Хотя этой связи можно избежать, если использовать Provider/Riverpod или любой другой инструмент прокидывания зависимостей в виджеты.

#tips

Если начинать Flutter-проект с расчетом, что это будущее полноценное качественное приложение, а не быстрый прототип, то помимо продуктовой продуманности, помните про ряд важных технических моментов, которые стоит учесть как можно раньше, чтобы обеспечить достойный технический уровень проекта прямо со старта. В общем, написал статью для Яндекс Академии с подробным чеклистом, а тут краткое содержание:

1. Настройте проверку качества кода статическим анализатором, aka линтер, aka dart analyze.
2. Подготовьте релизную сборку. Да-да, прямо на старте проекта!
3. Подготовьте окружение и удобные скрипты для автоматической настройки этого окружения. Например, если есть несколько проектов с разными версиями, то fvm — must have.
4. Настройте как минимум Continuous Integration, а хорошо бы и CD.
5. Воспользуйтесь централизованным логгером, благо вариантов на pub.dev достаточно.
6. В корне приложения пропишите централизованную обработку необработанных исключением.
7. Реализуйте интернационализацию. Про отличие от локализации тоже читайте в чеклисте.
8. Опишите централизованную дизайн-тему и UI-компоненты приложения.

#tips

Блок и кубит — это сущности для управления состоянием, обе поставляются из пакета bloc. Фундаментально, блок и кубит — это одно и то же — они наследники BlocBase. Это сущность, хранящая в себе состояние и стрим с изменениями этого состояния. И единственный инструмент изменения этого состояния — метод emit. В аргумент методу мы передаём новое состояние, и метод синхронно изменяет его и отправляет в стрим. Отличие блока и кубита лишь в том, как мы будем вызывать метод emit.

Кубит — это, буквально, BlocBase. Следовательно, единственный способ вызывать метод emit — просто напрямую. Но, он protected — значит его можно вызывать только внутри класса или внутри дочерних классов. Поэтому в каждом конкретном кубите мы описываем наши собственные публичные методы с нужным набором аргументов, и уже внутри них вызываем метод emit, чтобы обновить состояние по результатам выполнения.

Блок — это BlocBase на стероидах. Ключевое отличие — в блоке появляется стрим событий. В блоке мы описываем события (базовый класс + дочерние) с набором аргументов и кидаем их в блок через единственный метод add. А логику обработки событий описываем в методах, которые регистрируем в конструкторе блока через метод on. Кайф в том, что этот метод принимает коллбек EventHandler, который может быть асинхронным. И все события, которые попадают в один и тот же обработчик, будут обрабатываться асинхронно, но последовательно, образуя очередь событий. Ну и чтобы обновить состояние блока из EventHandler'а, у него в аргументах есть Emitter, в который мы по готовности закидываем новое состояние.

Короче, что кубит, что блок — это просто класс с мутабельным полем (стейтом) и стримом. В кубите мы обновляем это поле через метод emit, а в блоке — через отправку событий в отдельный стрим, обработка которого происходит в обработчике EventHandler. В нём написана асинхронная логика обновления состояния.

В Dart очень изящно избавились от ключевого слова interface, а теперь снова его добавляют (и, на мой взгляд, не зря). Но независимо от его наличия/отсутствия мне всегда немножко грустно от избыточного использования сущности интерфейсов в любой непонятной ситуации. Потому что пользы это не добавляет, зато добавляет много бесполезного кода, который точно никогда не пригодится.

В дарте любой класс — это уже неявный интерфейс. Поэтому по умолчанию у класса уже есть интерфейс, его не нужно писать дополнительно! А выделять в отдельный класс-интерфейс его имеет смысл в трех случаях:

1. Когда есть несколько реализаций одного и того же публичного API класса.

2. Когда у реализации публичный интерфейс для “потребителя” шире, чем для внутреннего использования, и его нужно сузить.

3. Когда реализации в принципе не существует и её должен написать сам "потребитель".

И вот ещё статейка на эту тему (правда не про Dart).