Вопросы на собеседовании: Flutter-разработчик

Они различаются моментом выбора типа и объёмом статических проверок Dart.

• var выводит один статический тип из инициализатора, поэтому после var count = 1 нельзя присвоить count строку.
• Object принимает любой объект Dart, кроме null, а Object? также принимает null, но оба требуют проверки типа перед обращением к его членам.
• dynamic откладывает проверки членов и присваиваний до выполнения, поэтому я оставляю его только на границах нетипизированных данных и быстро преобразую.

final присваивается один раз во время выполнения, а const обозначает константу времени компиляции.

• Значение final может прийти из DateTime.now() или ответа API, но после этого его нельзя переназначить.
• Значение const и всё содержимое его константной коллекции должны быть известны при компиляции.
• Экземпляры const-виджетов могут быть канонизированы и переиспользованы, поэтому я ставлю const у конструкторов, когда все аргументы постоянны.

Типы Dart по умолчанию не допускают null, а nullable-тип нужно пометить знаком ?.

• String name не может содержать null, а String? name может, поэтому перед использованием значение нужно проверить или безопасно прочитать.
• ?? задаёт запасное значение, а ?. выполняет условный доступ; ! утверждает, что значение не равно null, и может вызвать ошибку при неверном утверждении.
• late откладывает инициализацию, но чтение до присваивания вызывает ошибку выполнения, поэтому я использую его лишь при гарантированном порядке жизненного цикла.

Я выбираю List для упорядоченных значений, Set для уникальных значений и Map для поиска по ключу.

• List сохраняет порядок и допускает повторы, что подходит для последовательности сообщений или товаров.
• Set удаляет повторы и даёт быстрые проверки наличия, например для ID выбранных категорий.
• Map получает значение по ключу, например userById[id], а collection if и for позволяют декларативно строить любую из этих коллекций.

Dart поддерживает необязательные позиционные и именованные параметры, а функции можно передавать и хранить как другие значения.

• Именованные параметры заключаются в фигурные скобки, а required отмечает обязательные, поэтому вызов createUser(name: 'Ana') легко читать.
• Необязательному параметру нужен nullable-тип или значение по умолчанию, а необязательные позиционные параметры заключаются в квадратные скобки.
• Callback типа VoidCallback можно передать кнопке, а короткую функцию из одного выражения записать через =>.

Класс Dart объединяет состояние и поведение, а его конструкторы создают корректные экземпляры.

• Параметр this.name сразу инициализирует поле, а обязательные именованные параметры явно показывают необходимые входные данные.
• Именованный конструктор вроде User.guest() даёт ещё один понятный способ создания, а factory-конструктор может вернуть кэшированный экземпляр или подтип.
• extends переиспользует реализацию одного суперкласса, а переопределённые члены стоит отмечать @override, чтобы анализатор мог их проверить.

Интерфейс задаёт контракт для реализации, а mixin добавляет классам переиспользуемое поведение.

• Каждый класс Dart предоставляет неявный интерфейс, а implements требует реализовать все его члены в новом классе.
• interface class можно реализовать, но нельзя наследовать вне его библиотеки, что явно задаёт границу API.
• mixin подключается через with и позволяет делиться методами между несвязанными классами без глубокой цепочки наследования.

Records позволяют вернуть или объединить несколько типизированных значений без отдельного класса, а patterns распаковывают или проверяют их форму.

• Функция может вернуть (User, bool), сохранив типы обоих полей в статической системе типов.
• Деструктурирующее объявление final (user, cached) = result даёт имена полям record.
• List-, map-, object- и switch-паттерны извлекают вложенные значения, но для данных с идентичностью, методами или стабильной публичной моделью я использую именованный класс.

sealed class задаёт закрытое семейство подтипов, которое switch может обработать исчерпывающе.

• Подтипы должны быть объявлены в той же библиотеке, поэтому компилятор знает полный набор.
• Loading, Success(data) и Failure(error) образуют практичную sealed-иерархию результата для экрана.
• Switch-выражение по такой иерархии выдаёт ошибку компиляции при пропущенном варианте, в том числе после добавления нового подтипа.

Future завершается один раз значением или ошибкой, а Stream может выдавать много значений со временем.

• Я ожидаю Future через await для одного ответа REST или чтения файла и ловлю ошибку через try и catch.
• Я подписываюсь на Stream для повторяющихся событий, например изменений авторизации или обновлений базы в реальном времени.
• Подписки Stream нужно отменять при dispose владельца, а await for может читать события до закрытия потока.

Во Flutter метод build описывает UI для текущего состояния, а не отправляет команды для изменения отдельных представлений.

• При изменении состояния Flutter снова вызывает build и сопоставляет новую конфигурацию виджетов с существующим деревом.
• Флаг загрузки может прямо в дереве выбирать индикатор прогресса или содержимое.
• В build не должно быть сетевых вызовов и других побочных эффектов, поскольку фреймворк может вызывать его много раз.

Я использую StatelessWidget без изменяемого локального состояния и StatefulWidget, когда состояние должно сохраняться между пересборками.

• Объекты обоих виджетов неизменяемы; StatefulWidget создаёт отдельный изменяемый объект State.
• Заголовку только из аргументов конструктора подходит StatelessWidget, а локальному переключателю видимости пароля подходит StatefulWidget.
• Если состояние относится к нескольким экранам или бизнес-логике, я поднимаю его выше или переношу в слой управления состоянием, а не раздуваю локальный State.

Объект State инициализируется, может получать обновления зависимостей или виджета, пересобирается и в конце освобождается.

• initState запускается один раз для настройки без зависимости от inherited-виджетов, например для создания AnimationController.
• didChangeDependencies обрабатывает inherited-зависимости, а didUpdateWidget реагирует на новую конфигурацию виджета от родителя.
• dispose освобождает контроллеры, focus nodes и подписки перед вызовом super.dispose.

BuildContext определяет положение виджета в дереве элементов и служит для поиска предков вроде Theme или Navigator.

• Theme.of(context) ищет вверх именно из этой точки, поэтому нужный provider должен быть её предком.
• Context над только что созданным Scaffold не видит этот Scaffold; Builder может создать context под ним.
• После await я проверяю context.mounted перед навигацией или показом UI, потому что виджет могли удалить.

Widgets являются неизменяемыми конфигурациями, elements управляют их смонтированной идентичностью, а render objects выполняют layout и отрисовку.

• build создаёт лёгкие описания widgets, которые можно заменять при каждой пересборке.
• Element связывает widget с позицией в дереве и сохраняет связанный State, пока совпадают тип и key.
• Экземпляры RenderObject получают constraints, выбирают размер, рисуют пиксели и выполняют hit testing для виджетов с рендерингом.

Keys помогают Flutter сопоставлять конфигурации виджетов с существующими elements при изменении порядка или идентичности соседей.

• ValueKey(item.id) сохраняет правильный State при перемещении элементов в сортируемом списке.
• Keys важны среди соседей одного типа; случайные UniqueKeys принудительно теряют состояние вместо исправления идентичности.
• GlobalKey может обращаться к state или перемещать element по дереву, но он тяжелее и нужен лишь в случаях вроде FormState.

Родитель передаёт constraints вниз, каждый ребёнок выбирает допустимый размер, а родитель размещает его.

• Constraints задают минимальную и максимальную ширину и высоту, а не всегда один точный размер.
• Ребёнок не может выйти за эти пределы, поэтому width 500 не переопределит максимум родителя в 300.
• Неограниченные constraints часто появляются внутри scrollables и конфликтуют с Expanded или ребёнком, который пытается занять бесконечное пространство.

Row и Column используют Flex layout, а Expanded и Flexible определяют, как дети делят оставшееся место по главной оси.

• Row располагает детей горизонтально, Column вертикально, а mainAxisAlignment распределяет свободное место на этой оси.
• Expanded использует tight fit и растягивает ребёнка на его долю flex, что может убрать переполнение текста в Row.
• Flexible по умолчанию использует loose fit и разрешает ребёнку занять меньше своей доли, а значения flex делят пространство пропорционально.

Для длинного или динамического списка я использую ListView.builder, чтобы создавать только видимые элементы и ближайший кэш.

• ListView с явным списком children сразу создаёт каждого ребёнка и подходит лишь для небольшого фиксированного списка.
• SingleChildScrollView создаёт всего ребёнка, поэтому оборачивание большой Column тратит память и время build.
• Для смешанных секций вроде app bar, grid и list CustomScrollView со slivers объединяет их в одну область прокрутки.

MaterialApp предоставляет ThemeData для Material-виджетов, а CupertinoApp предоставляет CupertinoThemeData для виджетов в стиле iOS.

• Theme.of(context) и CupertinoTheme.of(context) читают унаследованные цвета и типографику вместо дублирования констант на каждом экране.
• ColorScheme позволяет Material-компонентам последовательно использовать роли primary, surface и error в светлой и тёмной темах.
• Я выбираю одну цельную дизайн-систему продукта и применяю платформенно-адаптивные элементы лишь там, где пользователи ожидают нативное поведение.