Постановка задач по мобильному интерфейсу

что надо назвать, кроме внешнего вида

Что это

Приёмы из статьи 10.5 работают и здесь: описывай состояния, а не пиксели, давай сигнатуру, проси по частям.

Но у мобильного приложения есть то, чего нет у сайта, — и если об этом не сказать, ИИ не спросит.

Как сказать ИИ

Шесть вещей, специфичных для мобильного

1. Версии. Flutter ломает совместимость чаще большинства фреймворков:

Flutter 3.38, Dart 3.10. Код только под эти версии.
Если предлагаешь что-то из более поздних — скажи.

2. Библиотека состояния. Названа — значит, проект не обрастёт второй (статья 11.4).

3. Размер экрана и ориентация. Телефоны разные, и «выглядит хорошо» на одном ничего не значит:

Проверь вёрстку на узком экране (360 логических пикселей)
и при альбомной ориентации. Фиксированных высот не используй.

4. Что при отсутствии сети. У мобильного приложения сеть пропадает постоянно — это норма, а не исключение:

Сеть может пропасть в любой момент. Что показываем:
при загрузке, при ошибке сети, при пустом ответе,
при успешных данных. Нужны все четыре.

5. Разрешения. Камера, геопозиция, уведомления, файлы — всё требует спросить пользователя, и отказ надо обработать:

Нужна геопозиция. Обработай три случая: разрешили,
отказали, отказали навсегда. В последнем случае —
предложение открыть настройки.

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

6. Платформенные различия. Android и iOS ведут себя по-разному: кнопка «назад», безопасные зоны у краёв экрана, вид диалогов.

Под какие платформы собираем — Android и iOS.
Отметь места, где поведение будет отличаться.

Чего не стоит делать

Не проси «сделай красиво». Это антипаттерн из статьи 3.16, и во Flutter он особенно разрушителен: получишь дерево на десять уровней с подобранными на глаз размерами.

Не описывай пикселями. Theme.of(context) и готовые виджеты отступов существуют именно для этого (статья 11.3).

Не проси экран целиком. Четыре шага дешевле: модель данных → виджет карточки → экран со списком и состояниями → обработка ошибок.

Проверка, которую стоит заказывать сразу

После того как напишешь: перечисли, что я должен проверить
руками на устройстве. Включи узкий экран, отсутствие сети
и отказ в разрешении.

Такой список — заготовка чек-листа из статьи 11.6, составленная под конкретную задачу.

На что смотреть

Сделан только удачный случай. Как и в React: есть «данные пришли», нет загрузки, ошибки и пустоты.

Нет обработки отказа в разрешении. Приложение зависает на запросе.

Фиксированные размеры. Развалится на другом телефоне.

Тексты не вынесены. Подписи прямо в виджетах — при добавлении второго языка придётся переписывать всё.

Платформенные различия не учтены. Работает на Android, ведёт себя странно на iOS.

Шпаргалка