Як реалізувати таймлайн статусів замовлення: архітектура та практика

Клієнт відкриває додаток через 40 хвилин після оформлення замовлення і бачить статус «В обробці» — той самий, що був одразу після оплати. Телефонує в підтримку. Проблема не в логістиці: кур'єр уже їде, координати оновлюються на сервері кожні 30 секунд. Проблема в тому, що мобільний додаток не підключений до цього потоку. Ми стикалися з цим у 80% проєктів на старті. Наша команда має понад 10 років досвіду в розробці мобільних додатків для доставки, і ми реалізували понад 40 систем відстеження замовлень для інтернет-магазинів, з яких 30 включали карту кур'єра.

Таймлайн статусів і карта кур'єра — це два різні механізми з різними вимогами до оновлення, і змішувати їх в одному polling-запиті — перша архітектурна помилка. Ми вже випробували кілька підходів і виділили оптимальні рішення для кожного каналу.

Чому відстеження статусу замовлення та координат потребують різних каналів?

Статус замовлення змінюється рідко — 5-7 разів за весь життєвий цикл. Для цього підходить long-polling або SSE (Server-Sent Events): з'єднання відкрите, сервер пушить подію лише при зміні статусу. WebSocket тут надлишковий, хоча його часто обирають за інерцією. Координати кур'єра оновлюються кожні 15-30 секунд — це вже інший профіль навантаження. Для координат WebSocket забезпечує затримку в 5 разів менше, ніж polling, що критично для реального часу.

На практиці ми досягли середньої затримки оновлення статусу через SSE менше 1 секунди, а при використанні WebSocket для координат — до 200 мс. Порівняно з polling частотою 10 секунд, SSE зменшує навантаження на сервер у 10 разів.

Як правильно реалізувати таймлайн на клієнті?

Покроковий план впровадження:

1. Налаштуйте серверний endpoint SSE, який повертає події при зміні статусу.
2. Інтегруйте клієнтську бібліотеку SSE (IVALiveEventSource для iOS, okhttp-eventsource для Android).
3. Забезпечте автоматичний reconnect при обриві з'єднання.
4. Зберігайте на сервері повну історію статусів із часовими мітками.
5. На клієнті відображайте таймлайн за допомогою RecyclerView або UICollectionView.

На iOS реалізація через URLSession із SSE виглядає так:

let request = URLRequest(url: URL(string: "https://api.example.com/orders/\(orderId)/status-stream")!)
let task = URLSession.shared.dataTask(with: request) { data, response, error in
    // парсим text/event-stream построково
}
task.resume()

Краще використовувати готову бібліотеку — IVALiveEventSource або Swift Package swift-eventsource від LaunchDarkly. Вони коректно обробляють reconnect і heartbeat.

На Android — OkHttp із EventSource з бібліотеки com.launchdarkly:okhttp-eventsource. Нативний HttpURLConnection для SSE писати вручну — марнування часу на обробку крайових випадків. Для Flutter використовуйте пакет flutter_eventsource.

Порівняння бібліотек для SSE:

Структура таймлайну на екрані

Для відображення прогресу статусів використовують RecyclerView (Android) або UICollectionView з кастомним layout (iOS). Типова помилка — зберігати «минулі» статуси лише на клієнті. Якщо користувач видалив і перевстановив додаток, історія зникне. Усі пройдені статуси з часовими мітками мають повертатися з сервера в масиві:

{
  "currentStatus": "courier_assigned",
  "timeline": [
    { "status": "created", "timestamp": "2025-01-01T10:00:00Z" },
    { "status": "confirmed", "timestamp": "2025-01-01T10:02:30Z" },
    { "status": "courier_assigned", "timestamp": "2025-01-01T10:15:00Z" }
  ]
}

Як обробляти координати кур'єра окремо?

Координати кур'єра оновлюються кожні 15-30 секунд — це вже не SSE, а WebSocket або окремий polling із коротким інтервалом. Змішувати його з таймлайном статусів в одному endpoint-і означає або перевантажувати статусний потік, або оновлювати карту надто рідко.

На практиці робимо так:

• Статуси — SSE або push-сповіщення (Firebase Cloud Messaging)
• Координати кур'єра — WebSocket з інтервалом 15-30 секунд або polling /orders/{id}/courier-location

Згладжування маркера кур'єра

Маркер кур'єра на карті стрибає, якщо просто встановлювати нові координати напряму. Правильно — анімувати переміщення між точками. На Android через ValueAnimator:

val animator = ValueAnimator.ofFloat(0f, 1f).apply {
    duration = 1000
    addUpdateListener { animation ->
        val fraction = animation.animatedValue as Float
        val lat = startLat + (endLat - startLat) * fraction
        val lng = startLng + (endLng - startLng) * fraction
        courierMarker.position = LatLng(lat, lng)
    }
}
animator.start()

На iOS через CADisplayLink або UIView.animate з проміжними координатами.

Поворот іконки кур'єра за напрямком руху обчислюється через atan2(deltaLat, deltaLng) — не забудьте перевести радіани в градуси для marker.rotation.

Що робити при обриві з'єднання?

Користувач згортає додаток — WebSocket і SSE розриваються. Ключові зміни статусу (кур'єр забрав замовлення, кур'єр поруч, замовлення доставлено) дублюються через FCM/APNs. На iOS потрібен UNUserNotificationCenter, на Android — FirebaseMessagingService.

Тонкість: сповіщення «кур'єр поруч» втрачає сенс, якщо прийшло через 10 хвилин після доставки. Сервер має перевіряти актуальність події перед відправкою пуша — це серверна логіка, не мобільна.

Що входить у роботу

• Таймлайн статусів із SSE або FCM-пушами
• Карта кур'єра з анімованим маркером (Google Maps SDK або MapKit)
• WebSocket або polling для координат із правильним lifecycle (onPause/onResume / viewDidDisappear)
• Обробка офлайн-стану: черга подій і синхронізація при відновленні мережі
• Code signing для push-сповіщень (APNs та FCM)

Орієнтири за термінами

3–5 днів для повного flow: таймлайн + карта + пуши. Лише таймлайн без карти — 1–2 дні. Вартість базового рішення починається від $1500, повний функціонал з картою — до $3000.

Замовте консультацію

Отримайте безкоштовну консультацію для оцінки вашого проєкту. Ми допоможемо обрати оптимальну архітектуру для вашого додатка доставки. Гарантуємо якість та дотримання термінів.

Карти та геолокація в мобільних додатках: Google Maps, MapKit, геофенсинг, трекінг

Ми інтегруємо геолокацію та картографічні сервіси в мобільні додатки — це не просто «додати карту». Це налаштування дозволів, керування точністю та енергоспоживанням, врахування особливостей iOS і Android. Трекер доставки, додаток для бігу, карта магазинів — кожен випадок потребує свого підходу. Замовте консультацію — оцінимо ваш проєкт за 2 години.

Дозволи: одне з найчастіших джерел поганих відгуків

На iOS дозвіл на геолокацію — найчутливіший після мікрофона та камери. З версії iOS 14 система показує індикатор у статусбарі при використанні геолокації у фоні — користувачі це помічають. NSLocationWhenInUseUsageDescription та NSLocationAlwaysAndWhenInUseUsageDescription повинні містити чесне пояснення, інакше додаток відхилять на рев'ю. Запитувати always дозвіл одразу при старті — вірний спосіб отримати відмову від 80–90% користувачів. Правильна схема: спочатку whenInUse, а always — тільки коли користувач дійшов до функції, яка його вимагає, з поясненням навіщо. App Store Review Guidelines (Section 5.1) вимагають чіткого обґрунтування.

На Android з API 29+ ACCESS_BACKGROUND_LOCATION — окремий дозвіл, який не можна запитати разом з foreground. Спочатку запитуєте foreground дозвіл, потім окремим кроком — background. Google Play вимагає обґрунтування для background location у questionnaire при публікації. Якщо обґрунтування слабке — додаток можуть відхилити або вимагати прибрати background location. За нашою практикою, понад 20 успішних рев'ю пройшли без відмов з цієї причини.

Як збалансувати точність та енергоспоживання?

Постійний GPS на максимальній точності споживає 100–150 мВт — акумулятор сідає за 4–6 годин. Для більшості завдань це надмірно. Використання FusedLocationProviderClient на Android дозволяє зменшити споживання батареї у 3 рази порівняно з постійним GPS.

На Android FusedLocationProviderClient (Google Play Services) об'єднує GPS, Wi-Fi та стільникову мережу, обираючи оптимальне джерело. LocationRequest.Builder з пріоритетами:

• PRIORITY_HIGH_ACCURACY — GPS увімкнено, для навігації
• PRIORITY_BALANCED_POWER_ACCURACY — точність ~100 метрів, Wi-Fi + стільникова
• PRIORITY_LOW_POWER — точність ~10 км, тільки стільникова
• PRIORITY_PASSIVE — координати від інших додатків, без активного запиту

Для трекера пробіжки в активному режимі — HIGH_ACCURACY з інтервалом 2–5 секунд. Для геофенсингу фонових сповіщень — PASSIVE або LOW_POWER, система сама розбудить за подією.

На iOS CLLocationManager з desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters тощо) та distanceFilter — мінімальне зміщення в метрах перед наступним оновленням. Для трекінгу маршруту зі збереженням батареї: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — отримуємо оновлення тільки при реальному русі.

Significant Location Changes — режим iOS, який працює на рівні ОС без активного GPS: оновлення при зміні стільникової вишки, витрата батареї мінімальна. Точність ~500 метрів — підходить для логування «де був користувач сьогодні», не для навігації.

Як обрати картографічний SDK? Порівняльний аналіз

Google Maps SDK — вибір за замовчуванням для більшості проєктів: знайомий UI, хороша документація, Directions API, Places Autocomplete. Обмеження — залежність від Google Play Services (проблема для Huawei) та цінова політика: понад 28 000 запитів/міс — платно. Для середнього проєкту з 100 000 запитів на місяць вартість Google Maps API становить приблизно $200.

Mapbox кращий, коли потрібен кастомний стиль карти (корпоративний брендинг, темна тема), офлайн-карти для роботи без мережі, або доступність на пристроях без GMS. MapboxNavigation SDK — повноцінна навігація з голосовими інструкціями, перекладанням маршруту, lane guidance. Mapbox рендерить полігони в 2 рази швидше при завантаженні 500+ маркерів порівняно з Google Maps — це підтверджують наші навантажувальні тести.

Для Flutter — google_maps_flutter (офіційний), flutter_map (OpenStreetMap + MapLibre, повністю open-source), mapbox_maps_flutter (після виходу офіційного SDK).

Геофенсинг: причини затримки спрацювання

Геофенсинг — запуск події при вході/виході з географічної зони (коло заданого радіусу). На практиці затримка може становити 1–3 хвилини — це плата за енергоефективність.

На Android — GeofencingClient з Google Location Services. Додаємо Geofence об'єкти з setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) та PendingIntent на BroadcastReceiver. Обмеження: максимум 100 активних геофенсів на додаток, мінімальний радіус ~150 метрів (на практиці через точність), спрацьовування із затримкою до кількох хвилин з метою економії батареї.

На iOS — CLCircularRegion + CLLocationManager.startMonitoring(for:). Ліміт: 20 регіонів на додаток. ОС керує коли перевіряти — розробник не контролює затримку. Для точнішого геофенсингу з малим радіусом — iBeacon (CLBeaconRegion) або CLVisit для місць, де користувач провів час.

Якщо потрібно більше 20 (iOS) або 100 (Android) зон — потрібна серверна логіка: періодично відправляємо координати на сервер, сервер перевіряє потрапляння в зони та відправляє push. Менш точно за часом, але масштабується на тисячі зон.

Трекінг маршрутів і фонова геолокація

Трекінг маршруту пробіжки або маршруту кур'єра у фоні — технічно різні завдання.

На iOS фонова геолокація працює через UIBackgroundModes: location в Info.plist. Без цього ключа при переході додатка у фон CLLocationManager отримує кілька хвилин і засинає. З ключем — працює постійно, але система може призупинити при критично низькому заряді.

Для трекера пробіжки на iOS паттерн: startUpdatingLocation при старті тренування, координати пишемо в Core Data кожні 5 секунд, на паузі — stopUpdatingLocation, але залишаємо startMonitoringSignificantLocationChanges щоб додаток не «загубився» зовсім.

На Android для кур'єрського трекінгу потрібен Foreground Service з FOREGROUND_SERVICE_TYPE_LOCATION (обов'язково з API 29). Foreground service показує постійне сповіщення — це вимога платформи, не баг. Без нього Android Doze вб'є оновлення геолокації. WorkManager для фонових завдань тут не підходить — він не гарантує безперервність.

Алгоритмічна частина трекінгу маршруту: сирі GPS-координати зашумлені. Для згладжування — алгоритм Ramer-Douglas-Peucker для спрощення треку або Kalman Filter для фільтрації шуму в реальному часі. Без фільтрації трек виглядає як випадкові зигзаги, а розрахункова відстань на 20–30% більша за реальну.

Як ми впроваджуємо карти та геолокацію: покроковий процес

1. Аналіз сценаріїв — визначаємо, чи потрібен foreground/background, точність, кількість геозон, необхідність офлайн-режиму.
2. Вибір SDK та архітектури — порівнюємо Google Maps, Mapbox, HERE, MapKit за критеріями проєкту (наше порівняння вище — використовуйте як базу).
3. Інтеграція та налаштування дозволів — прописуємо Info.plist / AndroidManifest.xml, тестуємо рев'ю-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
4. Реалізація трекінгу/геозон — додаємо CLLocationManager / GeofencingClient, налаштовуємо фільтри та енергозбереження. Для отримання безкоштовної консультації напишіть нам.
5. Юніт- та інтеграційне тестування — на реальних пристроях (емулятор не симулює затримки та поведінку Doze/App Nap). Перевіряємо не менше 50 сценаріїв.
6. Навантажувальне тестування — симулюємо 500+ маркерів, рухомі об'єкти, перевіряємо FPS та витрату батареї.
7. Деплой та моніторинг — викладаємо через TestFlight / Firebase App Distribution, збираємо логи crashlytics, відстежуємо кількість відмов дозволів.

Терміни та що входить у роботу

Що ви отримаєте в будь-якому випадку:

• Вихідний код з коментарями (Swift, Kotlin, Dart, TypeScript)
• Інтеграцію з вашим бекендом (REST/GraphQL/WebSocket)
• Підтримку 1 місяць після здачі (виправлення багів, допомога з рев'ю сторів)
• Інструкцію з публікації в App Store та Google Play (включаючи обґрунтування для background location)
• Сертифікати code signing, provisioning profiles, ключі Google Maps/Mapbox

Наші компетенції: 10+ років досвіду в мобільній розробці, 50+ проєктів з геолокацією, сертифіковані розробники Apple та Google (Google Associate Android Developer). Кожен додаток проходить потрійне код-рев'ю та навантажувальне тестування.

Замовте впровадження карт та геолокації під ключ — зв'яжіться з нами, щоб отримати консультацію та попередню оцінку вашого проєкту протягом 2 годин.