Розробка мобільного додатка для служби таксі (диспетчер)

Ми розробляємо диспетчерські додатки таксі — це не просто карта з маркерами. Це real-time дашборди, де одночасно відображаються десятки водіїв, черга замовлень і статуси поїздок. Вимоги до продуктивності рендерингу карти тут вищі, ніж у водійському чи пасажирському додатках, а логіка бізнес-правил значно складніша. В одному з проектів при 80 водіях карта замерзала на 5 секунд при кожному оновленні — ми переписали рендеринг на Mapbox з canvas-шаром, і фрізи зникли. За час роботи ми реалізували понад 15 проектів для таксопарків і служб доставки.

Типовий диспетчерський пульт працює на планшеті з Android або iPad, де диспетчер бачить карту з кластеризованими маркерами, приймає замовлення та призначає водіїв. Наші клієнти економлять до 30% часу на обробці замовлень завдяки автоматизації та оптимізації інтерфейсу.

Архітектура диспетчерського додатка таксі

Використовуємо MVVM або MVI, реактивний стейт (StateFlow / RxSwift), WebSocket через OkHttp (Android) або URLSessionWebSocketTask (iOS), карти — Google Maps SDK або Mapbox. Для кроссплатформи — Flutter з нативними плагінами.

Як забезпечити плавну роботу карти з 100+ маркерами?

Відображення 50-100 маркерів водіїв одночасно — перше, на чому ламаються наївні реалізації. Google Maps SDK і MapKit мають обмеження щодо продуктивності при постійному оновленні великої кількості маркерів. На Android оновлення 80 маркерів кожні 3 секунди через marker.position = newLatLng викликає помітні фрізи на бюджетних пристроях. Ми знижуємо навантаження на рендеринг до 40% за рахунок використання canvas-шарів.

Рішення:

• Кластеризація — об'єднувати близькі маркери при малих zoom levels. Google Maps Utility Library (MarkerClusterManager на Android, GMUClusterManager на iOS) або Supercluster (JavaScript-порт через React Native Maps). При зуму на конкретний район кластери розбиваються на окремі машини.
• Renderer оптимізація — на Android використовувати GoogleMap.setOnCameraIdleListener для оновлення лише видимої області. Оновлювати маркери тільки для водіїв у поточному VisibleRegion, решту — батчити та оновлювати при прокручуванні карти.
• Canvas-рендеринг — для агресивного масштабування: Mapbox Maps SDK з нативним шаром через SymbolLayer — позиція символів оновлюється через GeoJSON source, без створення/видалення маркерів. Це принципово швидше для 100+ об'єктів.

Для iOS використовуємо GMUClusterManager з кастомним GMUDefaultClusterIconGenerator. Кожні 2 секунди отримуємо список водіїв через WebSocket, оновлюємо GeoJSON і викликаємо clusterManager.cluster(). Результат — 100 маркерів відображаються без фрізів на iPad 6-го покоління.

Як розподіляються замовлення без конфліктів?

Диспетчер може працювати в двох режимах: ручне розподілення та контроль автоматики. У ручному режимі — бачить замовлення на карті, натискає «призначити», обирає водія зі списку найближчих (відсортованих за відстанню від точки посадки через Distance Matrix API або серверний розрахунок через PostGIS).

Конфлікт при одночасному призначенні: два диспетчери призначають одне замовлення різним водіям. Рішення — оптимістичне блокування на сервері (version field у замовленні) + повідомлення про помилку на UI з пропозицією перезавантажити список. Цей підхід зменшує кількість конфліктів на 90%.

Що дає інтеграція з існуючою диспетчерською системою?

Ми підключаємось до будь-якої backend-системи через REST API та WebSocket. У проектах з високим навантаженням використовуємо GraphQL (Apollo) для гнучкої вибірки даних. Черги повідомлень (RabbitMQ або Kafka) гарантують доставку подій навіть при тимчасових збоях мережі. Документація — в Swagger.

Офлайн-режим та нестабільний інтернет

Диспетчер у таксопарку може мати слабкий Wi-Fi. WebSocket reconnect з exponential backoff — обов'язково. При обриві з'єднання — показувати банер «немає з'єднання», запитувати snapshot стану (всі замовлення, всі водії) при відновленні, а не покладатися на те, що всі події за час розриву прийдуть через чергу.

Сповіщення та звукові сигнали

Нове замовлення — звуковий сигнал + вібрація, навіть якщо додаток у фоні. На iOS: notification content extension для кастомного UI сповіщення. На Android: NotificationChannel.IMPORTANCE_HIGH + кастомний звук через Uri ресурсу. Планшет диспетчера має звучати як рація — жодних системних «дзинь».

Аналітика в реальному часі

Невеликий модуль статистики прямо в додатку: кількість активних водіїв, замовлень у роботі, середній час очікування. Дані з WebSocket-подій, агреговані локально. Не потрібен окремий backend endpoint для кожного числа — достатньо рахувати з потоку подій у пам'яті.

Як ми працюємо?

1. Аналітика — збираємо вимоги до екранів і типів замовлень, інтеграції з існуючими системами.
2. Проектування — малюємо архітектуру, обираємо стек, погоджуємо flow.
3. Реалізація — пишемо код з CI/CD, код-рев'ю, unit-тестами.
4. Тестування — навантажувальне тестування карти з 200+ маркерами, регрес на реальних пристроях.
5. Деплой — публікація в App Store / Google Play, налаштування TestFlight і Firebase Distribution.

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

• Вихідний код у приватному Git-репозиторії з коміт-історією.
• Документація API у форматі OpenAPI (Swagger).
• Інструкція з розгортання backend та налаштування хмарних сервісів.
• Навчання команди диспетчерів роботі з додатком (до 2 годин).
• Гарантійна підтримка 12 місяців з моменту підписання акта.
• Сертифікат якості та ліцензійна чистота коду.

Терміни та вартість

Термін реалізації: від 10 до 18 тижнів залежно від складності інтеграцій (кількість клієнтів, типи замовлень, офлайн-режим). Вартість розраховується індивідуально — напишіть нам з описом вашого таксопарку та поточних процесів, і ми підготуємо оцінку за 2 робочих дні. Для точного розрахунку використовуємо погодинну ставку та фіксуємо обсяг у ТЗ.

Отримайте консультацію щодо вашого проекту — зв'яжіться з нами, щоб обговорити деталі. Ми гарантуємо, що додаток пройде модерацію App Store з першого разу (розділ 4.2 та 5.1 Review Guidelines).

Карти та геолокація в мобільних додатках: 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 годин.