Польовий технік приїжджає до клієнта, відкриває застосунок — а там білий екран, тому що стільникової мережі немає. Заявка на ремонт, історія обладнання, чек-лист інспекції — все зависло. За 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 застосунку.