Разработка Flutter-приложения начинается с работы пользователя, а не макета. Для кого оно создаётся, когда открывается и какое действие должно завершить? Клиентское приложение и программа сотрудника в поле могут требовать разных данных и условий связи.
При разработке мобильного приложения выбор платформы не сводится к предпочтению технологии. Вместе оцениваются backend, возможности устройства, частота использования и порядок публикации. Одинаковой первой версии для всех нет.
Завершите основной пользовательский сценарий
Цель первой версии не в максимальном количестве экранов. Полезнее дать пользователю возможность выполнить одну работу целиком. Например, открыть список, выбрать задачу и передать результат — законченный условный сценарий.
Вход, загрузка, пустой список и ошибка тоже входят в него. Красивый экран с идеальными сведениями не отвечает на все вопросы повседневной работы. Без связи человек должен понимать следующий шаг.
Разделение приложения и backend
Нужно определить серверную часть бизнес-правил. Приложение не должно быть непрозрачным механизмом, который самостоятельно решает всё и отправляет только итог. Разрешения, целостность и организационные границы защищаются также backend.
В планировании PHP/Laravel API рассматриваются контракт ответа, проверка и операции. Знание контракта позволяет понятнее представить ожидаемые и ошибочные состояния.
Слабая связь и повтор
Мобильный пользователь не всегда имеет стабильный интернет. После отправки связь может пропасть, и неизвестный результат приведёт к повтору операции. Поэтому состояния ожидания, повторения и подтверждения планируются заранее.
- Как обозначается устаревание загруженных данных?
- Хранятся ли неотправленные изменения на устройстве?
- Что происходит при изменении записи с двух устройств?
- Как обрабатываются местные данные после выхода?
- Как завершается операция при запоздавшем ответе?
Уведомления и устройство
Цель уведомления должна быть определена: событие, адресат и переход. Отправка по каждому изменению способна снизить пользу. Нужно учитывать открытие уже закрытой задачи или записи, на которую у человека больше нет разрешения.
Камера, файлы, местоположение и другие возможности выбираются при реальной необходимости. Отказ в разрешении не должен оставлять интерфейс непонятным. Пользователю нужны объяснение назначения и доступная альтернатива.
Платформы и общий код
Flutter позволяет готовить приложения для разных платформ, но одинаковое поведение всех устройств не предполагается. Дополнительная проверка зависит от функций проекта. Официальное описание Flutter отдельно рассматривает прикладные сценарии веб-использования.
Если публичному контентному сайту и мобильному рабочему приложению нужны разные интерфейсы, не обязательно принудительно объединять их. Решение подробнее обсуждается в сравнении Flutter и веб-приложения.
Приёмка и публикация
- Реальные размеры устройств и основной сценарий.
- Первый, повторный вход и выход.
- Плохая связь и незавершённая отправка.
- Отказ в разрешении устройства.
- Переход из уведомления к записи.
- Совместимость старой версии с backend.
Публикация — отдельный этап: заранее определяются аккаунты, материалы, тестовая версия и обновление. Решения платформы при проверке не находятся под полным контролем разработчика. Необоснованные гарантии срока принятия неуместны.
Пример заполненного, но не отправленного результата
Сотрудник в поле заполняет форму, после чего связь прерывается. В условной ситуации сохранение на устройстве отличается от завершения на сервере. Пользователь должен видеть разницу отправленного результата и ожидания передачи.
Проверяется судьба формы после закрытия и повторного запуска. При входе другого человека прежние сведения не должны показываться неверному аккаунту. Повтор не должен создавать второе такое же действие. Это отдельное правило приёмки данных.
- Заполните форму без соединения.
- Проверьте состояние после нового запуска.
- Сравните разделение данных при смене аккаунта.
- Посмотрите результат повторной передачи после восстановления.
Пример показывает, что offline не является одной кнопкой. Объём становится ясным после определения местного хранения и согласования с сервером.
Отдельно рассмотрите истёкшую сессию. Связь может появиться уже после окончания разрешённого доступа. Программа не должна молча терять результат или отправлять его от другого пользователя. Нужен понятный способ повторного входа и подтверждения принадлежности работы. Такое поведение обсуждается на условной форме до масштабной разработки, поэтому проверка не требует обещать полноценную работу без интернета для всех функций.
Добавьте в проверку пустой аккаунт нового пользователя. Приложение должно объяснить отсутствие рабочих данных и доступное первое действие. Заглушка загрузки без завершения не заменяет корректный пустой экран, даже если демонстрационная версия уже наполнена примерами.
Частые вопросы
Можно ли использовать API сайта?
Да, если подходят данные, доступ и мобильные сценарии. Самого наличия API недостаточно: контракт проверяется.
Нужна ли первая версия без интернета?
Это бизнес-требование. Полноценный offline может требовать дополнительных правил синхронизации и конфликтов.
Процессы бизнес-платформ вроде Finex дают контекст для обсуждения мобильного интерфейса. Опишите один сценарий, затем уточните связь API и объём мобильной разработки.
