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

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

Что на самом деле значит «работает без интернета»?

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

Ниже — уровни, как мы их разделяем при оценке. Чем выше уровень, тем больше данных на устройстве и тем больше ситуаций, которые нужно продумать и проверить: обрыв посреди отправки, разряженный телефон, две версии одной записи, приложение старой версии с неотправленными данными.

Уровень	Что работает без сети	Где хватает	Сложность
0. Без офлайна	Экран «Нет соединения», данные не видны	Оплата, онлайн-запись, чат с поддержкой	Минимальная
1. Просмотр кэша	Последние загруженные данные только для чтения	Клиентское приложение, каталог, расписание	Низкая
2. Очередь действий	Создать запись, отметить, сфотографировать — отправка при появлении сети	Отчёт прораба, заказ торгового агента, приёмка на складе	Средняя
3. Полная работа без сети	Почти все экраны и справочники на устройстве, сеть нужна для обмена	Долгие смены без связи, удалённые объекты	Высокая

Какие данные хранить на телефоне?

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

• Справочники. Номенклатура, ячейки, виды работ. Обновляются при каждом выходе в сеть, причём по изменениям, а не целиком: иначе загрузка каталога на 20 тысяч позиций съедает мобильный трафик.
• Рабочие данные. Задачи и объекты конкретного сотрудника на сегодня и ближайшие дни, а не всё, что есть в системе.
• Неотправленное. Очередь действий и фото, которые ещё не дошли до сервера. Это самое ценное, что есть на устройстве.
• Чего не хранить. Цены закупки, персональные данные всех клиентов, чужие отчёты. Если телефон потеряли, на нём должно остаться минимум.

Отдельно решите, что происходит при увольнении или смене телефона: доступ отключается на сервере, а при следующем выходе в сеть приложение стирает локальные данные. И что видит человек, у которого давно истёк вход, — он не должен потерять неотправленные записи из-за того, что приложение попросило ввести пароль заново.

Как копятся действия и уходят на сервер?

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

Три вещи, которые отличают надёжную очередь от той, что теряет данные:

1. Уникальный номер операции. Его присваивает телефон в момент действия. По нему сервер понимает, что заказ № 7 от торгового агента уже принят, и не создаёт дубль после повторной отправки.
2. Порядок. Нельзя отправить «закрыть задачу» раньше, чем «создать задачу». Очередь уходит в той последовательности, в которой человек работал, а при ошибке на одной операции следующие, зависящие от неё, ждут.
3. Отправка в фоне. Сотрудник не должен держать приложение открытым, пока ловит сеть. На Android для этого есть WorkManager: по документации Android такие задачи переживают перезапуск приложения и перезагрузку телефона, запускаются при заданных условиях, например когда есть сеть, и повторяются при сбое. На iOS фоновую работу приложения планирует система, поэтому момент отправки там менее предсказуем.

Ещё одна мелочь, которая потом стоит дорого, — время. Часы на телефоне могут стоять неправильно, поэтому в операции хранят и время устройства, и время приёма на сервере, а в отчётах решают заранее, по какому из них считать смену.

Правило	Как работает	Подходит	Риск
Последнее изменение побеждает	Сервер оставляет то, что пришло позже	Личные заметки, настройки, статус своей задачи	Тихо теряется чужая правка
Слияние по полям	Один поменял телефон, другой адрес — сохраняются оба поля	Карточки клиентов и объектов	Два изменения одного поля всё равно нужно решать
Только добавление	Записи не правятся, а дописываются: «принято 5», «списано 2»	Остатки, движения товара, журнал работ	Нужен пересчёт итогов на сервере
Решает человек	Приложение показывает обе версии и просит выбрать	Заказы, акты, цены	Лишний экран и вопрос к пользователю

Что делать, если двое изменили одно и то же?

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

Универсального правила нет, их комбинируют. Для статуса своей задачи хватает «последнее изменение побеждает». Для остатков надёжнее не хранить число, а дописывать движения: «принято 10», «отгружено 3» — тогда два офлайн-устройства не перезапишут друг друга, сервер просто сложит операции. Для заказа с ценой или акта надёжнее показать человеку обе версии и попросить решить.

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

Как не потерять фото, снятые без связи?

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

• Сжатие на устройстве. Снимок современной камеры весит несколько мегабайт. Для фотоотчёта обычно хватает уменьшенной копии, и она уходит по слабой сети намного быстрее — заранее договоритесь, какое качество нужно для споров с заказчиком.
• Данные раньше фото. Сначала уходит сама запись — «работы выполнены, 12 фото», затем фото по одному. Офис видит факт сразу, а снимки догружаются.
• Отправка по одному с повтором. Если оборвалось на седьмом, первые шесть уже на сервере, а седьмое начнёт заново.
• Фон на iPhone. В iOS есть фоновые сессии URLSession для загрузки и выгрузки файлов. По справке Apple, такие задачи продолжают работу, когда приложение приостановлено, а несрочные система может отложить до зарядки или Wi-Fi. Для больших пакетов фото это удобно, но мгновенной отправки не обещает.
• Место. Приложение следит за свободной памятью и предупреждает до того, как камера перестанет снимать.

Что показывать пользователю, когда сети нет?

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

• Значок состояния в шапке: «нет сети», «отправляем 3 записи», «всё отправлено».
• Метка у каждой записи: черновик, ждёт отправки, принята сервером, ошибка.
• Время последнего обновления справочников и данных: «обновлено вчера в 18:40» — чтобы сотрудник не принимал устаревший остаток за текущий.
• Понятная ошибка вместо кода: «Задачу закрыли в офисе, ваш отчёт сохранён как комментарий».
• Запрет выхода из аккаунта и предупреждение при удалении приложения, пока есть неотправленное.
• Кнопка «Отправить сейчас» для тех, кто поймал сеть у окна и хочет убедиться.

Офлайн в PWA и в установленном приложении: в чём разница?

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

Две конкретные причины. По справке MDN о хранилище, Safari при включённой защите от межсайтового отслеживания удаляет данные, созданные скриптом, если у сайта не было кликов или касаний пользователя за последние семь дней использования браузера. А API фоновой синхронизации, по MDN, работает не во всех распространённых браузерах, поэтому PWA часто отправляет очередь, только пока открыта.

При этом PWA вполне рабочий вариант для стройки. В кейсе СтройОко офлайн-режим сделан на PWA с Service Worker, а в поле работают отметки задач на чертеже и чек-листы с GPS и фото-подтверждением. Как выбирать между PWA и сборкой для магазинов в целом — в статье «PWA, кроссплатформа или натив».

Почему офлайн-режим дорожает?

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

• Локальная база на телефоне и её обновление при новых версиях приложения, не теряя неотправленное.
• Очередь, повторы, защита от дублей на сервере.
• Правила конфликтов для каждого вида данных и экран выбора версии там, где решает человек.
• Отдельная очередь фото со сжатием.
• Тесты: режим полёта посреди отправки, слабая сеть, два устройства на одну запись, переустановка.

Базовая цена мобильного приложения у нас — от 200 000 ₽ за iOS и Android из одного кода, до 6–8 экранов, срок — от 2 недель. Офлайн-режима в перечне тарифа нет, поэтому его считаем после брифа и фиксируем цену в договоре до старта. Уровень «просмотр кэша» обычно почти не меняет смету, очередь действий и полная работа без сети — меняют. Подробнее о составе тарифа — на странице разработки мобильных приложений.

Как это выглядит на складе, стройке и у торгового агента?

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

Склад. Связь пропадает в дальних рядах и холодильных камерах, но ненадолго. Достаточно второго уровня: справочник товаров и ячеек на устройстве, сканы приёмки и инвентаризации копятся и уходят, когда кладовщик вернулся в зону Wi-Fi. Остатки — только движениями, резерв под заказ — только онлайн. Выбор устройств и порядок перевода операций разобран в статье о штрихкодировании склада.

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

Торговый агент в регионах. Объезжает точки, где сеть то есть, то нет. На телефоне — его маршрут на день, клиенты, прайс и остатки на момент выезда. Заказ создаётся офлайн, но с пометкой «остаток на 8:00» и подтверждением при отправке: если товар закончился, агент узнаёт об этом при синхронизации и может предложить замену.

Когда офлайн-режим не нужен?

Когда всё, что делает пользователь, без сети и так невозможно: оплатить, записаться на свободное время, написать в поддержку, посмотреть остаток в реальном времени. Тогда достаточно аккуратного экрана «нет соединения» и сохранения недописанной формы, чтобы её не пришлось заполнять заново.

• Клиентское приложение магазина, салона или кофейни: хватит первого уровня — показать последний каталог или карту лояльности.
• Сотрудники работают в офисе или там, где связь стабильна, и обрывы длятся секунды.
• Операции, где важна только текущая цифра с сервера: резервы, бронирования, выдача номеров.
• Пилот на двух-трёх сотрудниках: сначала проверьте, где реально пропадает связь, и добавьте офлайн по фактам.

Какие ошибки делают чаще всего?

Главная — сказать «нужен офлайн» без уточнения уровня и правил, а потом спорить на приёмке, что именно имелось в виду. Остальные ошибки происходят из неё же: решения, которые должны быть в ТЗ, принимаются по ходу разработки.

• Хранить на телефоне всю базу «на всякий случай» вместо данных одного сотрудника.
• Не продумать дубли: после обрыва сервер получает тот же заказ дважды.
• Молча перезаписывать чужие изменения, без правила конфликтов.
• Отправлять фото вместе с данными одним большим запросом, который никогда не проходит по слабой сети.
• Не показывать статус отправки — и сотрудники начинают дублировать отчёты.
• Проверять приложение только в офисе с хорошим Wi-Fi. Тесты с режимом полёта и слабой сетью стоит включить в приёмку перед релизом.

7 вопросов про офлайн для ТЗ

1. Где и как долго пропадает связь: минуты на складе или полдня на объекте?
2. Какие действия разрешены без сети, а какие — только онлайн?
3. Какие данные нужны на телефоне и за какой период: задачи на день, неделю, все объекты сотрудника?
4. Какое правило конфликтов для каждого вида данных: последнее изменение, по полям, только добавление или решает человек?
5. Сколько фото в смену, какого качества и через сколько дней их можно удалять с телефона?
6. Что видит пользователь: статус связи, счётчик неотправленного, время последнего обновления?
7. Что происходит при потере телефона, увольнении и выходе из аккаунта с неотправленными записями?

Ответы на эти вопросы занимают полстраницы, но именно они определяют смету. Остальную структуру ТЗ — роли, экраны, вход, push и публикацию — смотрите в статье про ТЗ на мобильное приложение. С готовыми ответами приходите на бриф по приложению: назовём уровень офлайна, цену и срок до старта.

Короткие ответы на частые вопросы

Входит ли офлайн-режим в базовую цену мобильного приложения?

Нет. В перечне тарифа мобильного приложения (от 200 000 ₽, до 6–8 экранов) офлайн-режим не назван, поэтому его объём и цену считаем после брифа: просмотр кэша обходится заметно дешевле очереди действий и полной работы без сети.

Можно ли добавить офлайн в уже готовое приложение?

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

Что будет с данными, если телефон потеряли до синхронизации?

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

Работает ли PWA без интернета так же, как установленное приложение?

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

Сколько данных можно держать на телефоне?

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

Услуги и кейсы по теме: мобильные приложения · кейс СтройОко · цены и сроки