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

Офлайн-режим – это архитектура, а не фича

Офлайн нельзя «прикрутить» к готовому приложению. Его закладывают в основу. Базовый принцип – local-first: приложение всегда читает и пишет в локальную базу на устройстве (SQLite, Realm), а синхронизация с сервером идёт фоном, когда связь появляется.

Главная сложность – не хранение, а разрешение конфликтов. Двое сотрудников меняют один наряд офлайн, потом оба синхронизируются. Кто прав? Мы фиксируем стратегию заранее: для большинства полей работает «последняя запись побеждает» с версионированием по времени сервера, для критичных операций (закрытие заявки, списание материалов) – блокировка на стороне backend и явный пересмотр конфликта оператором.

Объём данных тоже планируют. Тащить весь справочник на телефон не нужно – выгружаем только релевантный срез: заявки на смену, прайс по региону, маршрут на день. Дельта-синхронизация передаёт только изменения, а не всю базу, что экономит трафик в роуминге и на медленных каналах. На стороне сервера такая нагрузка ложится на реляционную СУБД, и переход на надёжную открытую платформу здесь оправдан – мы подробно разбирали миграцию на PostgreSQL для подобных сценариев.

Безопасность данных на устройстве и в канале

Телефон выездного сотрудника теряют, крадут, оставляют в машине. Поэтому данные на устройстве шифруют: база – через SQLCipher или средствами платформы (Keychain на iOS, Keystore на Android), ключи не хранят в коде. Доступ к приложению закрывают PIN-кодом или биометрией с принудительной блокировкой после простоя.

Для госсектора и работы с персональными данными добавляется удалённое стирание (remote wipe) при компрометации устройства и контроль версии ОС. Канал синхронизации защищают TLS с проверкой сертификата (certificate pinning), чтобы исключить подмену сервера в публичных сетях. Аутентификацию строим на коротких токенах с обновлением, а не на постоянных логине и пароле в памяти.

При работе с персональными данными граждан учитываем требования 152-ФЗ: храним на устройстве минимум, обезличиваем где можем, ведём журнал доступа. Это снимает часть рисков ещё на этапе проектирования, а не при проверке.

Где приложению помогает backend

Мобильный клиент тонкий – основная логика и интеллект живут на сервере. Сервисному инженеру удобно получить подсказку по типовой неисправности прямо в карточке заявки: для этого мы подключаем базу знаний на RAG, которая отдаёт релевантную инструкцию по запросу, а не заставляет листать PDF. Накопленные с полей данные (время на объекте, расход материалов, маршруты) питают аналитику и прогнозы – как мы показывали в материале про платформу данных и ML, это превращает рутинную телеметрию в управленческие решения.

Вывод

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