Интерфейс строится из текущих данных
В декларативном подходе описание интерфейса зависит от состояния. Если материал выбран, показывается одно состояние кнопки; если нет — другое. Разработчик описывает, как должен выглядеть каждый вариант, а не пытается вручную перекрасить отдельный участок экрана. Для простого локального изменения подходит StatefulWidget с отдельным объектом State. Сам виджет остаётся неизменяемым описанием, а изменяемые данные находятся в связанном состоянии. Это различие помогает понять, почему название виджета не означает, что его поля можно произвольно менять как угодно. В учебном примере достаточно логического признака выбора. Метод build использует его, чтобы определить надпись и оформление. Если при построении всё ещё читается другое значение, правильное изменение первой переменной не даст ожидаемого результата.
Изменение нужно связать с уведомлением о сборке
В рассматриваемом локальном подходе вызов setState сообщает Flutter, что состояние изменилось и соответствующий интерфейс следует построить заново. В переданной функции выполняют само изменение нужных данных. Простое присваивание без такого уведомления может не вызвать запланированную повторную сборку. Иногда экран обновится по другой причине, что способно скрыть ошибку. Поэтому не стоит считать случайно появившееся изменение надёжной организацией состояния. Повторная сборка не означает, что разработчику нужно вручную заново создавать всё приложение. Важно правильно определить участок, который зависит от данных. Для одного переключателя не обязательно сразу вводить сложную общую систему управления состоянием.
Локальное состояние имеет ограниченную жизнь
Выбор внутри одного элемента интерфейса и сохранённые настройки приложения — разные задачи. Если отметка должна переживать закрытие приложения, одного локального значения недостаточно: нужно отдельно продумать хранение и восстановление. Также важно не помещать длительную асинхронную работу внутрь функции, переданной в setState. Эта функция выполняется синхронно. Получение данных и последующее обновление состояния организуют так, чтобы изменение происходило в подходящий момент жизненного цикла. Для учебного примера полезно сначала проверить простую цепочку: нажатие меняет признак, уведомление запускает обновление, build читает новое значение. Затем можно разбирать более сложные случаи — общие данные нескольких экранов или результат внешнего запроса. Если экран не изменился, проверяйте эту цепочку по шагам. Дополнительные вызовы обновления в случайных местах могут скрыть причину и усложнить понимание работы приложения.
Попробуйте на практике
На бумаге спроектируйте кнопку выбора материала. Начальное состояние — не выбран; первое нажатие выбирает материал, второе снимает отметку. Запуск проекта для упражнения не обязателен.
- Назовите локальный логический признак и опишите два варианта надписи или оформления.
- Запишите последовательность первого нажатия: изменение признака, вызов уведомления и чтение значения при построении интерфейса.
- Повторите описание для второго нажатия и проверьте возвращение к исходному виду.
- Отдельно решите, должна ли отметка сохраняться после закрытия приложения, и укажите, почему это другой вопрос.
Как проверить результат. В схеме различены данные, уведомление об изменении и построение интерфейса. После двух нажатий состояние возвращается к исходному, а долговременное хранение не приписано локальному значению автоматически.
Частые вопросы
Любое изменение интерфейса требует именно setState?
Нет. Во Flutter есть разные подходы к состоянию. Здесь разобран простой локальный вариант; в других архитектурах уведомление может организовываться иначе.
Можно ли сделать функцию внутри setState асинхронной?
Нет. Переданная функция должна выполняться синхронно. Асинхронную работу организуют отдельно, а затем корректно обновляют состояние с учётом жизненного цикла.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.