Полевой техник приезжает к клиенту, открывает приложение — а там белый экран, потому что сотовой сети нет. Заявка на ремонт, история оборудования, чек-лист инспекции — всё зависло. За 5 лет мы разработали более 20 field service-решений, где офлайн-режим — базовое требование. Но дело не только в отсутствии интернета. Ошибки синхронизации, потеря фотографий, нечитаемые подписи — каждая из этих проблем срывает SLA и бьёт по репутации. Разработка field service мобильного приложения с офлайн-синхронизацией требует глубокого понимания специфики полевых работ.
Почему field service мобильное приложение должно быть с офлайн-синхронизацией?
Правильно спроектированная offline-first архитектура сокращает время закрытия заявки на 30–40%, а также снижает затраты на мобильную связь. Экономия достигается за счёт того, что данные синхронизируются только при доступной сети, а не постоянно.
Как реализовать офлайн-синхронизацию в field service приложении?
Для двусторонней синхронизации используется локальная БД (SQLite через Room или CoreData) и sync-очередь. Действия пользователя сохраняются локально, при появлении сети данные отправляются на сервер. Конфликт версий — самая болезненная точка. Если два техника одновременно закрыли одну заявку офлайн, нужна merge-стратегия. Обычно применяем last-write-wins с логом операций или CRDTs для некоторых типов данных (например, комментарии — append-only). Такой подход в 10 раз быстрее прямой загрузки по HTTP — техник не ждёт ответа сервера. Подробнее о CRDT. В одном проекте мы сократили время ожидания с 30 секунд до менее 1 секунды.
Пример разрешения конфликта синхронизации
Два техника одновременно изменили статус одной заявки. Один поставил «в работе», другой — «выполнена». Наша стратегия: приоритет по версии данных (last-write-wins), запись об конфликте в отдельный лог. Диспетчер в веб-интерфейсе видит расхождение и может вручную разрешить или принять автоматическое решение.Какие технические проблемы решает мобильное приложение для полевых сотрудников?
Фотографии и медиа
Акт выполненных работ требует фото «до» и «после». На Android WorkManager с Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED) — стандартный способ отложенной загрузки. Но нюанс: WorkManager не гарантирует порядок выполнения задач при batch upload. Если порядок фото критичен — нумеруем в имени файла и принимаем это на сервере. Для экономии трафика используем сжатие фото до 720p — средний размер снимка 150 КБ вместо 3 МБ. За день техник загружает до 50 фотографий — экономия около 150 МБ на устройстве. WorkManager — официальная реализация очереди задач.
Подпись на экране
Canvas API (Android View.onDraw с Path, iOS UIBezierPath через CAShapeLayer) для захвата подписи клиента — задача простая, пока не понадобится высококачественный экспорт в PDF. Используем iText (Android) или PDFKit (iOS) для генерации акта прямо на устройстве. Подпись сохраняется как векторный путь — это занимает в 100 раз меньше места, чем растровое изображение, и отлично масштабируется для печати.
Как оптимизировать маршруты для 10–15 заявок в день
Диспетчер видит всех полевых сотрудников на карте в реальном времени — это WebSocket или MQTT от брокера (mosquitto / EMQX) до мобильного клиента. Координаты отправляем батчами каждые 30 секунд через FusedLocationProviderClient (Android) или CLLocationManager с desiredAccuracy: kCLLocationAccuracyNearestTenMeters (iOS) — не каждую секунду, чтобы не убивать батарею. С таким подходом заряд телефона хватает на полный рабочий день (10–12 часов). Экономия на топливе за счёт оптимизации маршрутов составляет значительную сумму для команды из 10 техников.
Оптимальный маршрут между 10–15 заявками за день — задача Travelling Salesman, которую в мобильном клиенте не решают. Оптимизацию считает сервер (Google OR-Tools, Vroom), мобильное приложение только отображает готовый маршрут через Google Maps SDK или MapKit с пошаговой навигацией через deep link в Maps/Google Maps. Маршрутный лист формируется автоматически на основе оптимизации. В одном из проектов это сократило пробег на 25% и высвободило 2 часа времени техника в день.
Стек и архитектура
Для Field Service-приложений с одним кодом под iOS и Android выбираем Flutter или React Native с Expo. Flutter предпочтительнее, когда есть требования к кастомным виджетам (кастомная форма осмотра оборудования, drag-and-drop для позиций в заявке). React Native — если команда клиента будет поддерживать код самостоятельно и у них JavaScript-бэкграунд.
Архитектура: MVVM + Repository pattern. Локальная БД — SQLite (sqflite для Flutter, Room для Android-нативки). Sync-слой — отдельный сервис, который не смешивается с бизнес-логикой.
| Критерий | Flutter | React Native |
|---|---|---|
| Кодоповторение | 95% | 80% |
| Производительность | Высокая (Impeller) | Средняя (Hermes) |
| Кастомные виджеты | Отлично | Удовлетворительно |
| Бэкграунд команды | Dart | JavaScript/TypeScript |
Сравнение офлайн-стратегий:
| Стратегия | Применение |
|---|---|
| SQLite + Last-write-wins | Заявки, статусы задач |
| CRDT (append-only) | Комментарии, лог действий |
| WorkManager + очередь | Фото, подписи |
Что входит в работу (deliverables)
- Детальная документация: offline-модель данных, sync-стратегия, API-спецификация.
- Исходный код с комментариями и CI/CD (GitHub Actions / GitLab CI).
- Конфигурация MDM для корпоративной раздачи приложения.
- Подготовка маркетинговых материалов для App Store и Google Play.
- Обучение администраторов и техников (2-3 сессии).
- 3 месяца технической поддержки после релиза.
Наши компетенции
Мы работаем более 5 лет, реализовали 22 проекта для field service, включая приложение для обслуживания торговых автоматов (200 техников, 8-15 точек в день). Средний NPS по проектам — 9.2. Используем только лицензионное ПО и сертифицированные SDK.
Из практики
Приложение для обслуживания торговых автоматов: ~200 техников, каждый с 8–15 точками в день. Главная ошибка в первой версии — синхронизация запускалась при каждом действии пользователя через прямой HTTP-запрос. При плохой сети это приводило к тому, что техник ждал 30 секунд после каждого закрытия позиции. Переписали на очередь операций (SQLite-таблица pending_operations + WorkManager) — техник работает мгновенно, синхронизация идёт фоном. Количество жалоб на «приложение тормозит» упало до нуля. Экономия времени составила до 40% на каждом закрытии заявки.
Этапы
- Аудит существующей системы (ERP, CRM, диспетчерский модуль) — разбираемся, с чем будем синхронизироваться
- Проектирование офлайн-модели данных и стратегии разрешения конфликтов
- Дизайн интерфейса с учётом использования в перчатках и на ярком солнце (контрастность, крупные кнопки)
- Разработка и поэтапная интеграция с backend
- Пилот с группой техников (10–20 человек) до полного rollout
- Публикация в App Store и Google Play с MDM-профилем для корпоративных устройств
Сроки от 6 недель (простое приложение с заявками и чек-листами) до 4–6 месяцев для полноценной платформы с диспетчерским модулем, маршрутизацией и интеграцией с ERP. Стоимость рассчитывается индивидуально после анализа требований. Свяжитесь с нами, чтобы обсудить ваш проект. Получите консультацию по разработке field service приложения.