Flutter: от экрана к приложению

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

Объясняет, откуда берутся размеры элементов и почему width: 100 не всегда означает фактическую ширину 100. Row, Column, Expanded, Flex, ограничения и неограниченное пространство. После него вёрстка становится системой правил, а не ритуалом «оберни ещё в один Container и попробуй Expanded».

Связь Widget, Element и RenderObject, обновление дерева, layout, ключи, slivers и ленивое построение. Первый материал даёт карту системы, второй раскрывает алгоритмические решения. Это не руководство по раскладыванию приложения на папки: это объяснение механики, на которой держится интерфейс.

Views/view models, repositories/services, зависимости, тесты и окружения; рядом полный исходный код Compass. Ценность — в связном разборе решений, а не в обязательном количестве слоёв. Авторы прямо допускают другие способы управления состоянием и передачи данных: это рекомендации, не религия MVVM.

Сообщения между Dart и платформенной частью, асинхронность, ограничения потоков и типизированная генерация интерфейсов через Pigeon. Полезный разбор именно границы систем: где сериализуются данные, кто обрабатывает вызов и как возвращается результат. Не путать с FFI: channels и вызовы C ABI решают разные задачи.

Брать не только стартовый пример, но и жизненный цикл providers, disposal, зависимости и overrides в тестах. Именно эти темы показывают, зачем библиотека нужна помимо замены setState. Синтаксис обязательно сверять с текущими руководствами: статья под старую major-версию — не надёжный источник актуального API.

Не очередной counter: есть слой данных, repository, изменения списка, фильтрация и тесты. Его полезно разбирать как альтернативную модель организации логики и сравнивать с Riverpod по конкретным задачам. Необязательно заранее осваивать оба фреймворка до совершенства: полезнее понять, что именно каждый делает явным.

Работа UI- и raster-частей кадра, лишние build/layout/paint, стоимость графических операций и временные трассы. Важная практическая деталь: debug-сборка не подходит для репрезентативной оценки производительности, нужен соответствующий режим профилирования. Полезно, когда хочется заменить «Flutter почему-то тормозит» конкретной измеренной причиной.

Unit-, widget- и integration-тесты, их стоимость и границы. Читать не ради определения трёх терминов, а ради выбора подходящего уровня проверки. Например, тест бизнес-правила и сценарий взаимодействия с реальным устройством не должны автоматически становиться одинаковыми тяжёлыми end-to-end-тестами. В документе есть переходы к практическим руководствам.

Для сценариев с системными разрешениями, уведомлениями и нативными элементами интерфейса. Важное отличие: официальный integration_test сам по себе не умеет взаимодействовать со всем таким UI; документация Flutter отдельно указывает на Patrol для этих задач. Изучать после widget-тестов, а не пытаться заменить им вообще всё тестирование.

Типизированные запросы, реактивные выборки, транзакции и изменение схемы базы. Особенно ценная часть — миграции вместе с тестированием сохранности данных, а не первый SELECT. В руководстве есть инструменты генерации миграций и тестов. Отличный следующий шаг после демо, которое умеет только сходить в HTTP API.

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

Экранные дикторы, подписи элементов, масштабирование текста, контраст и удобство нажатий. Здесь есть практический checklist перед выпуском. Это часть базового понимания мобильного UI: приложение должно оставаться пригодным к использованию при другом размере текста и способе взаимодействия, а не только на устройстве автора.