Офлайн-режим приложения должен сохранять действия до связи и показывать, что ещё не отправлено

Отчёт сохраняют до того, как показывают успех. Данные должны остаться в постоянном хранилище устройства вместе с заданием на отправку. Если места не хватило, приложение сообщает об этом вместо галочки.

Закажите конкретное действие: «закрыть наряд с комментарием без связи». Официальная документация Android отдельно описывает офлайн-чтение и запись важных данных сначала на устройстве. Слова «приложение работает офлайн» не определяют, что именно сотрудник сможет сделать.

Для автоматизации сельского хозяйства полевое задание сохраняют без связи и передают агроному после отправки.

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

Покажите остаток работы на устройстве. Сотруднику нужно найти неотправленный отчёт, время его сохранения и причину остановки. Общая надпись «Нет интернета» не объяснит, почему при вернувшейся сети отчёт остался на телефоне.

В Field Service Microsoft показывает состояние синхронизации и её ошибки. Для вашего приложения названия могут быть другими, но смысл стоит договорить заранее: запись на телефоне, ожидание подтверждения и подтверждённый серверный результат различаются.

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

Самый показательный сбой случается после записи. Сервер принял закрытие наряда, но связь оборвалась до ответа. Телефон повторяет запрос, и без защиты диспетчер может получить повторное действие.

Дайте каждому действию устойчивый идентификатор. Повтор использует тот же идентификатор, а сервер узнаёт уже выполненную операцию и возвращает её результат. Это называется идемпотентностью: повтор запроса не повторяет бизнес-эффект.

AWS описывает этот принцип для API. Для вашего заказа важна граница: узнавать повтор должен сервер, а не только телефон. Срок хранения идентификатора согласуют с допустимой длительностью офлайн; запись результата и защита от дубля не должны расходиться при сбое.

Связь вернулась, но наряд уже изменён диспетчером. Сотрудник офлайн отметил выполнение отменённой работы. Правило «последняя запись побеждает» здесь может вернуть отменённый наряд в работу.

Выберите правило вместе с владельцем процесса. Какие изменения можно объединить, какие отклонить, а какие показать руководителю? Microsoft разбирает конфликт техника и диспетчера как отдельный случай синхронизации. Победитель зависит от настройки продукта, а не от самого наличия интернета.

Отчёт и вложение тоже могут доставляться отдельно. Если комментарий принят, а фотография осталась на телефоне, статус всей работы должен учитывать обязательность фото. Повторная отправка сохраняет связь вложения с исходным отчётом.

Своего клиентского офлайн-приложения у нас нет. Наш опыт относится к vibecoding.ru: инженер ведёт машину агентов, а её работу показывает публичный журнал машины. Переносим отсюда уроки наблюдения и повторов, а работу мобильного клиента проверяем заново.

В нашем веб-конвейере обработка повторяла один и тот же повреждённый пакет. Попытки шли, а публикации не двигались. Поэтому при восстановлении связи мало видеть «Отправляем»: нужно знать, какое действие подтверждено, какое застряло и почему.

Ещё одна граница: живой вход не означает работающий обработчик. На сайте мы стали проверять итог публикации. Для офлайн-приложения аналогичный вопрос звучит так: дошёл ли отчёт сотрудника и сколько времени он ждёт подтверждения?

Задание начинается с рабочего события, а не с выбора библиотеки. В постановке задач агенту важны результат и способ проверки. Здесь результат звучит так: «После обрыва и перезапуска сохранённый отчёт доставлен без повторного закрытия наряда».

Агент может написать локальное хранение, экран очереди и проверки сбоев. Инженер согласует серверный контракт и принимает результат на нужных устройствах. Ответственность за ошибки ИИ остаётся у компании; отчёт автора кода о собственном успехе приёмку не заменяет.

В уроке «Руль, окно и сторож» разбираем правила, наблюдение и проверки машины. Для этого заказа правило запрещает удалять неподтверждённое действие, экран показывает остаток, а проверка ловит потерю и дубль. Это перенос метода, а не готовый мобильный кейс.

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

Если выбираете разработку по подписке, тариф «Один проект» стоит 250 000 ₽ в месяц на 08.10.2026. Офлайн-участок мобильного клиента можно вынести в обсуждение первой задачи. Это цена тарифа, а не обещание собрать любое приложение за месяц.

На разбор вашего проекта принесите рабочее действие, список устройств и описание серверного API. По ним можно определить объём первого участка и кто со стороны компании будет его принимать.

1. Принимайте сохранение после завершения и повторного открытия приложения. Галочка появляется только после записи на устройство.

2. Разделите локальное сохранение и подтверждение сервера. Сотрудник должен видеть остаток и причину остановки.

3. Оборвите ответ после серверной записи и повторите отправку. Один идентификатор действия должен дать один бизнес-результат.

4. Согласуйте конфликт, вложения и повторный вход до разработки. Проверяйте первый рабочий путь на устройстве и сервере вместе.