Офлайн в мобильном приложении: какие сценарии действительно нужны

Начните со сцены, а не с требования «всё работает офлайн». Например, сотрудник уже открыл задание и вошёл в помещение без устойчивой сети. Нужно ли ему прочитать адрес, сделать фото, оставить комментарий или окончательно закрыть заказ? У этих действий разные последствия.

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

Android Developers описывает offline-first через локальный и сетевой источники данных: критичное чтение должно быть доступно без сети. Это не означает, что каждое действие безопасно завершать локально.

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

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

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

Пока сотрудник был без сети, диспетчер мог переназначить задание или другой пользователь — изменить запись. Правило «последний запрос победил» не всегда подходит бизнесу. Можно объединять независимые заметки, отклонять устаревшие операции или отправлять спорное изменение на ручное решение.

Опишите хотя бы один конфликт словами: «Сотрудник закрывает локальный черновик, но сервер уже отменил задание». Что сохраняется, что видит сотрудник, кто разбирает исключение? Молчаливое перезаписывание даёт красивую демонстрацию, но скрывает потерю смысла. Конфликты с реальными последствиями нужно проверять в пилоте.

Документация Apple объясняет, что время запуска фоновых задач выбирает система и доступное время исполнения ограничено. Закрытый экран приложения не является гарантией непрерывной отправки. На Android очередь, повтор и условия выполнения тоже требуют отдельного проектирования.

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

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

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