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

Ми розробляємо диспетчерські додатки таксі — це не просто карта з маркерами. Це 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).