Приложение для заказов офлайн с синхронизацией должно сохранять работу пользователя, не создавая ложного впечатления, что центральная система уже подтвердила результат. Человек может выбрать позиции и количество без подключения, но доступность товара или условия исполнения за это время способны измениться. Граница между локальным черновиком и принятым заказом должна быть видна всем участникам процесса.
Рассмотрим условную компанию, которая принимает заявки на расходные материалы на удалённых площадках. Сотрудник собирает несколько заявок на телефоне и подключается позже. В офисе за это время меняется доступный ассортимент. Система должна сохранить введённые сведения и показать, какие позиции приняты, какие нуждаются в уточнении и кто должен принять решение по оставшимся вопросам.
Уточните смысл офлайн-действия
Перечислите действия, которые действительно должны работать без сети: просмотр ранее полученного каталога, выбор клиента, подготовка строк и добавление примечания. Отдельно укажите операции, требующие актуального подтверждения. Возможность открыть старый экран не доказывает возможность выполнить все связанные с ним изменения. Эти ограничения нужно согласовать до оценки объёма разработки и показать пользователю в момент действия.
Для каждого типа сведений определите допустимую актуальность и необходимый локальный объём. Телефону может быть достаточно назначенных площадок и нужного набора товаров. Скачивание всей клиентской базы необязательно помогает завершить задачу, но усложняет управление данными. Продумайте неполную первоначальную загрузку: пустой список не должен ошибочно означать, что доступных работ или товаров действительно нет.
Сохраняйте черновик и его состояние
Покажите отдельные состояния для сохранения на устройстве, ожидания передачи и подтверждения центра. Пользователь должен видеть, какие записи ещё не покинули телефон, и понимать последствия выхода из учётной записи. Восстановление доступа не должно требовать незаметного удаления работы, которая ещё не была принята сервером. При этом сохранённые данные должны оставаться защищёнными в соответствующем пользовательском контексте.
Если заявка содержит вложения, отслеживайте их отдельно. Текст может быть принят раньше большого файла. Решите, допустимо ли считать заявку завершённой в таком случае и кто подтверждает исключение. Для оператора и пользователя это должно иметь одинаковое значение. Иначе один участник процесса начнёт исполнение, пока другой всё ещё ожидает обязательный документ или изображение.
Различайте повтор передачи и изменение заказа
После обрыва связи пользователь может повторить действие, которое сервер успел обработать. Связывайте новую попытку с прежней операцией, чтобы она не создавала ещё одну заявку. Реальная правка количества или адресата должна иметь собственный понятный контекст. Разработчик должен показать эту разницу на работающем сценарии, а не ограничиться общей формулировкой об устойчивости приложения к сбоям.
Заранее определите правила для изменений каталога и полномочий. Отменённое назначение не должно автоматически восстанавливаться из старого состояния телефона. При этом полезное примечание может потребовать отдельного рассмотрения. Сохраните сведения, необходимые для разбора, и назначьте роль, которая вправе решить конфликт. Обычное сообщение об ошибке не объясняет, кому нужно продолжать такую работу.
Проведите прерванную рабочую смену
Подготовьте тестовую заявку без сети, закройте приложение и измените доступность одной позиции в центральной системе. Восстановите соединение и отправьте тот же заказ несколько раз. Проверьте телефон, центральную запись и очередь исключений. Результатом должна быть одна узнаваемая заявка с понятными подтверждёнными и ожидающими частями, а не набор внешне похожих записей, требующих случайной ручной очистки.
На встречу с Brainbaby Labs принесите пример рабочего дня и разрешённые данные каталога. Это позволит описать первый законченный процесс, правила восстановления и критерии проверки на устройстве. Следует отдельно измерять поведение на выбранных телефонах и соединениях. Офлайн-функция считается объяснимой, когда команда видит, что сохранено, что принято и какие решения ещё остаются открытыми после возвращения связи.