Кейс — мобильное приложение

тот же API, другой разговор

Что это

Четвёртый потребитель того же API: приложение на Flutter. По смыслу экран тот же, что в статье 14.3, — список городов с температурой, — но разговор с ИИ получается другим, и различия стоит увидеть рядом.

Шаг 1. Что меняется в мини-ТЗ

Три строки по сравнению со статьёй 14.2 — и каждая тянет за собой работу:

Адрес API. localhost в приложении на телефоне указывает на сам телефон, а не на твою машину. При разработке нужен адрес машины в локальной сети, на боевом — настоящий домен. Это первое, обо что спотыкаются, и ИИ об этом не предупреждает, потому что не знает, где ты запускаешь.

Сеть пропадает. У сайта это редкость, у телефона — норма (статья 11.5). Значит, последние данные надо хранить на устройстве и показывать их с пометкой «обновлено тогда-то», а не пустой экран.

Обновление не мгновенное. Сайт обновляется при перезагрузке страницы, приложение — когда пользователь согласится (статья 12.3). Значит, API не может ломать совместимость: поле temp останется temp навсегда.

Шаг 2. Запрос

Flutter 3.38, Dart 3.10. Состояние — provider 6,
других библиотек состояния не добавлять.

Один экран: список городов с температурой.
Данные: GET http://<адрес>/cities,
ответ [{"name": String, "temp": double?}].

Нужно:
- модель City с fromJson, без приведения типов,
  temp честно nullable
- четыре состояния: загрузка, ошибка, пусто, данные
- адрес API вынести в настройку, не вшивать
- проверить вёрстку на ширине 360 и с длинным названием

Сначала список файлов и что в каждом. Код после «да».

Сравни с запросом из статьи 14.3: половина строк совпадает дословно. Четыре состояния, явные типы, адрес в настройке — это не свойства React или Flutter, а свойства задачи «показать данные из сети». Поэтому хороший запрос переносится между стеками почти целиком.

Отличаются три вещи, и все три — про платформу: версии (здесь их называют обязательно), библиотека состояния и проверка на узком экране.

Шаг 3. Что проверять в ответе

Поскольку запустить нельзя, остаётся то, что можно прочитать. По порядку важности:

1. Версия API. Главная проблема стека (статья 11.2). Устаревшие имена виджетов и параметров; flutter analyze обычно находит.

2. !, late, dynamic в разборе JSON. Сервер может ответить ошибкой, и json['temp'] as double уронит приложение. В модели должно быть честное double? и проверка, а не приведение типа.

3. Четыре состояния — все ли. Самое частое: есть «данные пришли», нет остального.

4. Запросы в build. Поход в сеть принадлежит слою данных, а не методу построения (статья 11.4).

5. dispose у контроллеров. Забытая уборка.

6. Фиксированные размеры. Переполнение на узком экране.

Это тот же список, что в статье 11.6, — здесь он просто применён к конкретной задаче.

Шаг 4. Разговор, который стоит завести заранее

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

Ответ на этот вопрос разобран в статье 12.2, и он ровно та причина, по которой мобильный кейс стоит планировать дольше остальных: сайт переделывается за вечер, а идентификатор приложения — никогда.

Шаг 5. Честный итог

Из четырёх потребителей API (бот, сайт, приложение, скрипт) этот — самый дорогой: отдельный стек, отдельная сборка, отдельная публикация, невозможность откатиться. При этом экран у него тот же, что у сайта.

Вопрос, который стоит задать себе до начала, а не после: нужно ли это приложение, или хватит сайта, открытого на телефоне? Для списка городов с температурой ответ чаще «хватит сайта». Приложение оправдано, когда нужно то, чего у сайта нет: работа без сети, уведомления, камера, фоновая работа.

Это и есть архитектурное решение из главы 13 — то самое, которое ИИ примет за тебя, если не принять его самому.

Шпаргалка