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

Офлайн как состояние по умолчанию

Сотрудник не должен думать, есть ли связь. Открыл заявку, заполнил акт, сфотографировал счётчик, поставил подпись на экране – всё это пишется в локальную базу на устройстве. На Android и iOS для этого хватает SQLite или Realm; данные ложатся в очередь на отправку и уходят на сервер, когда сеть появится. Ключевое правило: интерфейс никогда не блокируется в ожидании ответа сервера. Любая операция сначала завершается локально, а сетевой обмен происходит позже.

Это меняет и серверную архитектуру. Бэкенд перестаёт быть синхронным «вопрос-ответ» и превращается в приёмник пакетов изменений. Под такую нагрузку – редкие, но объёмные всплески при возвращении бригад в зону покрытия – удобно разворачивать обработчики по событийной модели; мы разбирали этот подход в материале про serverless и FaaS. Платформа сама масштабирует приём данных под пики, а в простое вы за неё не платите.

Синхронизация и конфликты

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

Слепая стратегия «кто последний записал, тот и прав» теряет данные. Работают другие приёмы. Версионируйте записи: к каждой сущности привязывайте номер ревизии и метку времени устройства. Делите данные на зоны ответственности – поля, которые правит только сервер (статус заявки, назначение), и поля, которые правит только исполнитель (результаты осмотра, фото, замеры). Тогда большая часть изменений сливается автоматически, а на ручное разрешение остаются единичные настоящие конфликты. Для них предусмотрите экран, где человек видит обе версии и выбирает, а не гадает, что произошло.

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

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

Телефон выездного сотрудника теряют и крадут. Для госсектора и финансовых заказчиков это прямой риск утечки персональных данных, подпадающих под 152-ФЗ. Локальную базу шифруйте (SQLCipher или штатное шифрование платформы), доступ закрывайте PIN-кодом и биометрией, давайте администратору возможность удалённо стереть данные на потерянном устройстве через MDM.

Если приложение обращается к внешним сервисам – например, тянет данные из банковских систем по модели, которую мы разбирали в статье про Open Banking API, – токены доступа храните в защищённом хранилище ОС (Keychain, Android Keystore), а не в обычных настройках. Для ускорения полевого ввода уместен голос: продиктовать примечание быстрее, чем печатать в перчатках, и здесь помогает распознавание речи.

Вывод

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