Приложение с офлайн-режимом продолжает работать, когда пропал интернет: сотрудник открывает задания, заполняет чек-листы, делает фото и сканирует товар, а данные сохраняются на телефоне и отправляются на сервер, как только появилась сеть. Для курьера, сервисного инженера или кладовщика это разница между рабочей сменой и сменой, которая встаёт каждый раз в подвале, лифте или на трассе. Ниже объясняем, как устроен офлайн внутри, где он ломается и как проверить, что подрядчик сделает его правильно.
- Офлайн держится на трёх механизмах: локальная база на устройстве, очередь отправки и правила разрешения конфликтов.
- Самое сложное — не хранение, а синхронизация: что делать, если одну запись изменили и на телефоне, и в 1С.
- Правила конфликтов нужно зафиксировать до разработки, по каждому типу данных.
- Офлайн дороже в разработке, чем «онлайн с заглушкой», поэтому его закладывают в архитектуру сразу, а не добавляют потом.
Что такое офлайн-режим мобильного приложения и чем он отличается от кеша
Многие приложения что-то показывают без сети: последнюю ленту новостей, ранее открытый каталог. Это кеш — сохранённая копия для чтения. Настоящий офлайн-режим означает, что пользователь может не только смотреть, но и создавать и менять данные: закрыть заявку, оформить заказ, провести инвентаризацию. И ни одна из этих операций не потеряется.
Для клиентских приложений часто хватает кеша: покупатель полистает каталог в метро, а заказ оформит, когда поймает сеть. Для рабочих приложений сотрудников — нет. Если инженер на объекте не может закрыть заявку без связи, он закроет её вечером по памяти, и смысл приложения пропадёт. Поэтому в корпоративных приложениях для сотрудников мы используем подход офлайн-first: офлайн — режим по умолчанию, а сеть — способ синхронизироваться, когда она есть.
Как устроено локальное хранение
На устройстве живёт собственная база данных. В неё заранее, пока сеть есть, загружается всё, что понадобится в течение смены: задания, справочники, каталог товаров, история клиентов, чек-листы. Объём подбирается под роль: торговому представителю — его маршрут и точки, кладовщику — номенклатура и ячейки своего склада, а не вся база компании.
Всё, что сотрудник делает, сначала записывается в эту локальную базу. Интерфейс работает только с ней и поэтому реагирует мгновенно — без «крутилок» загрузки даже при плохой сети. Фото и подписи сохраняются как файлы на устройстве и ждут отправки вместе с остальными данными.
Отдельный вопрос — безопасность. На телефоне хранятся рабочие данные компании, поэтому локальная база шифруется, а при отзыве доступа данные удаляются с устройства. Если сотрудник работает на личном телефоне, рабочие данные лежат в изолированном контейнере.
Очередь отправки: как данные уходят на сервер
Каждое изменение, сделанное без сети, превращается в запись в очереди: «создан визит», «добавлено фото», «изменено количество». Когда соединение появляется, приложение отправляет очередь пачкой, в том порядке, в каком действия совершались.
- ДействиеСотрудник закрывает заявку. Запись сохраняется в локальной базе, на экране заявка уже закрыта.
- Постановка в очередьИзменение получает уникальный идентификатор и время, чтобы сервер мог распознать повтор.
- ОтправкаПри появлении сети очередь уходит пачкой. Тяжёлые файлы — фото, акты — отправляются отдельно и докачиваются при обрыве.
- ПодтверждениеСервер отвечает, что принял изменение. Только после этого запись помечается как синхронизированная.
- Получение обновленийПриложение забирает с сервера новое: задания, изменения справочников, ответы на заявки.
Уникальный идентификатор операции нужен для защиты от дублей. Сеть часто рвётся на середине отправки: телефон уже передал заказ, но не получил ответа и отправит его снова. Сервер по идентификатору понимает, что это тот же заказ, а не новый. Без этого в 1С появляются задвоенные документы — одна из самых частых жалоб на плохо сделанные офлайн-приложения.
ПРАВИЛОЗапись считается сохранённой не когда её отправили, а когда сервер подтвердил приём.
Синхронизация данных офлайн и разрешение конфликтов
Конфликт возникает, когда одну и ту же запись изменили в двух местах, пока устройство было без сети. Менеджер в офисе поменял адрес клиента, а торговый представитель в это время записал в карточку новый телефон. Или в 1С списали остаток, а кладовщик на складе провёл пересчёт той же позиции. Какая версия правильная?
Универсального ответа нет, поэтому правила задаются по каждому типу данных. Типовые стратегии:
| Стратегия | Как работает | Где уместна |
|---|---|---|
| Источник правды | По полю всегда побеждает одна система | Цены и номенклатура — из 1С, статусы сделок — из CRM |
| Последнее изменение | Побеждает более позднее по времени | Комментарии, контакты, некритичные поля |
| Слияние по полям | Изменения в разных полях объединяются | Карточки клиентов и объектов |
| Только добавление | Записи не перезаписываются, а добавляются | Фото, визиты, сканирования, журнал действий |
| Ручное решение | Конфликт попадает к ответственному | Редкие и дорогие ошибки: суммы, остатки при расхождении |
Мы фиксируем эти правила на обследовании, до разработки: кто источник правды по каждому полю — 1С по остаткам и ценам, приложение по заказам и фактическим действиям, CRM по статусам сделки. Конфликты логируются и разрешаются по правилу, а не молча. Как спроектировать такой обмен с несколькими системами — отдельная задача интеграции приложения с 1С и CRM, в которой обмен тестируется на копии ваших систем с обрывами связи, откатами и дублями.
Что если недоступна не связь, а 1С
У офлайна есть второй сценарий: интернет у сотрудника есть, но недоступна учётная система — обновление, сбой, обслуживание сервера. Приложение и здесь продолжает работать: данные копятся в очереди на сервере приложения и уходят в 1С при восстановлении. Сотрудник не видит сбоя, а команда поддержки получает алерт и разбирается с обменом.
Поэтому в правильной архитектуре между приложением и 1С стоит собственный бэкенд с очередями, а не прямое подключение телефона к базе. Он принимает данные в любой момент, проверяет их, раскладывает по системам и повторяет отправку при ошибке. О выборе между готовыми облачными сервисами и своим сервером мы писали в статье «Firebase или свой бэкенд».
Когда офлайн нужен, а когда можно обойтись
Офлайн-режим увеличивает объём разработки: локальная база, очередь, конфликты, тестирование обрывов. Поэтому стоит честно оценить, нужен ли он.
- Нужен: полевые сотрудники, склады и цеха, логистика, работа на объектах, в регионах с нестабильной связью, на трассах между городами.
- Достаточно кеша: клиентские приложения магазинов и сервисов, где покупатель может оформить действие, когда сеть появится.
- Можно без офлайна: офисные сценарии с постоянным Wi-Fi, справочные приложения.
Если вы выбираете между веб-приложением и нативным, учтите, что у PWA офлайн ограничен возможностями браузера, особенно на iOS. Плюсы и минусы обоих вариантов — в статье «PWA или мобильное приложение».
Какие вопросы задать подрядчику про офлайн
Фраза «приложение работает офлайн» в коммерческом предложении ничего не гарантирует. Попросите подрядчика ответить на конкретные вопросы — по ответам видно, проектировал ли он офлайн раньше.
- Какие операции сотрудник сможет выполнять без сети, а какие нет?
- Какие данные загружаются на устройство заранее и как часто обновляются?
- Как защищены данные на телефоне и что происходит при увольнении сотрудника?
- Как приложение защищается от дублей при повторной отправке?
- Кто источник правды по каждому типу данных и как разрешаются конфликты?
- Что видит сотрудник, если синхронизация не прошла?
- Как вы тестируете обрывы связи и отключение 1С?
- Как вы узнаете о сбое обмена раньше, чем мы?
Хороший признак — подрядчик сам задаёт встречные вопросы о ваших процессах и предлагает зафиксировать правила конфликтов в документе. Плохой — обещает «всё синхронизируется автоматически» без подробностей.
Как заложить офлайн в проект с первого дня
Добавить офлайн в готовое онлайн-приложение почти всегда означает переписать значительную часть кода: меняется работа с данными на каждом экране. Поэтому решение о нём принимают на старте. У нас офлайн-first архитектура входит в состав разработки корпоративного приложения по умолчанию — от формата «Полевые сотрудники» за 7 000 000 ₸ до «Корпоративной платформы».
Практический порядок такой: на обследовании выясняем, где и как долго сотрудники остаются без связи, составляем список офлайн-операций и правила конфликтов, на пилоте проверяем их в реальных условиях — в подвалах, на трассе, на складе. Сравнить форматы и бюджеты можно на странице цен на мобильные приложения.
Сколько времени приложение может работать без интернета?
Столько, сколько хватает памяти устройства и заранее загруженных данных. Обычно смену или несколько дней — объём загрузки подбирают под роль сотрудника.
Потеряются ли данные, если телефон разрядится до синхронизации?
Нет. Данные сохраняются в локальной базе в момент действия и отправятся после включения устройства.
Как сотрудник понимает, что данные ушли?
В приложении виден статус синхронизации: сколько записей ждёт отправки и когда была последняя успешная синхронизация.
Можно ли сделать офлайн в клиентском приложении магазина?
Каталог кешируется и открывается при плохой сети, но оплата требует связи. Полный офлайн обычно нужен рабочим приложениям, а не клиентским.
