Розроблення мобільного застосунку для диспетчерської служби таксі
Диспетчерське таксі-застосунок — це real-time дашборд на смартфоні або планшеті, де одночасно видні десятки водіїв, черга замовлень та статуси поїздок. Вимоги до продуктивності рендерингу карти тут вищі, ніж у водіївському чи пасажирському застосунках, а логіка бізнес-правил значно складніша.
Карта з десятками рухомих маркерів
Відображення 50-100 маркерів водіїв одночасно — це місце, де ламаються наївні реалізації. Google Maps SDK та MapKit мають обмеження продуктивності при постійному оновленні великої кількості маркерів. На Android оновлення 80 маркерів кожні 3 секунди через marker.position = newLatLng викликає помітні стрибки кадрів на бюджетних пристроях.
Рішення:
Кластеризація — об'єднання близьких маркерів при малих рівнях масштабування. Google Maps Utility Library (MarkerClusterManager на Android, GMUClusterManager на iOS) або Supercluster (JavaScript-порт через React Native Maps). При збільшенні конкретної території кластери розбиваються на окремі машини.
Оптимізація рендеру — використання GoogleMap.setOnCameraIdleListener на Android для оновлення лише видимої площі. Оновлення маркерів тільки для водіїв в поточному VisibleRegion, решту батчити та оновлювати при прокручуванні карти.
Canvas-рендеринг — для агресивного масштабування: Mapbox GL JS (WebView-варіант) або Mapbox Maps SDK з нативним шаром через SymbolLayer — позиція символів оновлюється через GeoJSON source без створення/видалення маркерів. Це принципово швидше для 100+ об'єктів.
Розподіл замовлень
Диспетчер може працювати в двох режимах: ручний розподіл та контроль автоматики. У ручному режимі — бачить замовлення на карті, натискає «назначити», вибирає водія зі списку найближчих (відсортованих за відстанню від точки посадки через Distance Matrix API або серверний розрахунок через PostGIS).
Конфлікт при одночасному призначенні: два диспетчери призначають одне замовлення різним водіям. Оптимістична блокування на сервері (поле версії в замовленні) + повідомлення про помилку в UI з пропозицією перезагрузити список.
Офлайн-режим та нестабільний інтернет
Диспетчер у таксопарку може мати слабкий Wi-Fi. WebSocket reconnect з exponential backoff — обов'язково. При розриві з'єднання — показати банер «немає з'єднання», запросити snapshot стану (всі замовлення, всі водії) при відновленні, а не покладатися на те, що всі события за час розриву прийдуть через чергу.
Сповіщення та звукові сигнали
Нове замовлення — звуковий сигнал + вібрація, навіть якщо застосунок у фоні. На iOS: розширення контенту сповіщення для кастомного UI. На Android: NotificationChannel.IMPORTANCE_HIGH + кастомний звук через Uri ресурсу. Планшет диспетчера має звучати як радіостанція — ніяких системних «дзинькань».
Аналітика в реальному часі
Невеликий модуль статистики прямо в застосунку: кількість активних водіїв, замовлень в роботі, середній час очікування. Дані з WebSocket-подій, агреговані локально. Не потрібна окрема endpoint бекенду для кожного числа — достатньо рахувати з потоку подій в пам'яті.
Архітектура: MVVM або MVI, реактивний стан (StateFlow / RxSwift), WebSocket через OkHttp (Android) або URLSessionWebSocketTask (iOS), карти — Google Maps SDK або Mapbox. Для кроссплатформи — Flutter з нативними плагінами.
Термін: від 10 до 18 тижнів включаючи інтеграцію з усіма клієнтами системи. Вартість розраховується індивідуально.