Разработка мобільного додатку для служби таксі (водій)
Водійське приложение такси — технічно найскладніше з трьох клієнтів системи (водій, пасажир, диспетчер). Повинно працювати в фоні годинами, приймати замовлення навіть при нестабільному інтернеті, точно відстежувати маршрут та не розряджати телефон за зміну. Більшість проблем в готових MVP вспливають саме тут.
Фоновий режим та геолокація: де все ломається
Водій не тримає телефон в руках постійно. Додаток повинен:
- Отримувати нові замовлення через push навіть з wyключеним екраном
- Продовжувати трекінг маршруту в фоні
- Оновлювати серверу поточне положення кожні 3-5 секунд
На iOS це означає CLLocationManager з allowsBackgroundLocationUpdates = true, background mode location в Info.plist та окремо pausesLocationUpdatesAutomatically = false. Додаток утримує фоновий процес тільки поки активний location manager. Якщо водій прийняв замовлення — location оновлюється постійно. Якщо чекає — можна переключитися на startMonitoringSignificantLocationChanges() для економії батареї.
На Android — ForegroundService з постійним уведомленням. Без нього MIUI 14, EMUI 12 та Samsung OneUI 6 вбивають процес через 5-10 хвилин після блокування екрана. FusedLocationProviderClient з PRIORITY_HIGH_ACCURACY та інтервалом 3000 мс у режимі поїздки, PRIORITY_BALANCED_POWER_ACCURACY з інтервалом 30 секунд у режимі очікування. Переключення між режимами — за статусом замовлення з business logic.
Прийом замовлень та офлайн-сценарії
Нове замовлення приходить як FCM/APNs data push. Водій приймає або відхиляє — це повинно працювати навіть при поганому з'єднанні (тунелі, паркінги). Правильна схема: локальна чергу прийнятих/відхилених рішень з retry-логікою на WorkManager (Android) або BackgroundTasks (iOS). Якщо ответ не дійшов за 10 секунд — повторна спроба, інакше диспетчер вважає замовлення непринятим.
Таймаут прийняття замовлення — класична грабля. Сервер дає водієві 15-20 секунд. Якщо push прийшов з затримкою (FCM може затримувати до кількох хвилин в Doze mode) — водій бачить замовлення, натискає «прийняти», отримує ошибку «замовлення вже розподілено». Рішення: timestamp створення замовлення у payload push, клієнт перевіряет вік замовлення перед відображенням діалогу.
Навігація та побудова маршруту
Інтеграція з картами — ключова частина. Варіанти:
| SDK | Плюси | Обмеження |
|---|---|---|
| Google Maps SDK + Directions API | Найкраща якість маршрутів | Платно при великих обсягах |
| Mapbox Navigation SDK | Офлайн-карти, гнучкий UI | Потребує настройки тайлів |
| 2GIS SDK | Гарне покриття СНГ | Обмежений API |
| HERE Navigation SDK | Трафік в реальному часі | Дорожче конкурентів |
Для водійського додатку важливий turn-by-turn з голосовими підказками. Mapbox Navigation SDK для iOS та Android має готовий NavigationViewController / NavigationView з кастомізуємим UI. Google Maps не надає готовий turn-by-turn UI — потрібно будувати самостійно на Directions API + TTS.
Перебудова маршруту при відхиленні — rerouting повинен спрацьовувати автоматично при відхиленні від треку більше ніж на 50-100 метрів. У Mapbox це вбудовано в SDK, у Google — потрібно реалізувати самостійно через періодичні виклики Directions API.
Статусна машина замовлення
Водійське додаток — строго конечний автомат. Стани: idle → offer_received → accepted → en_route_to_pickup → arrived_at_pickup → in_trip → completed. Кожен перехід — запит до сервера з підтвердженням. UI блокує кнопки до отримання ответа щоб виключити двійні натискання.
Ошибка «arrived» натиснута двічі — реальна проблема: водій натиснув кнопку, вона не відреагувала (лаг мережі), натиснув ще раз, обидві команди дійшли. Сервер повинен бути ідемпотентним по transition, клієнт — показувати spinner та блокувати повторні натискання до ответа.
Розрахунок вартості поїздки на клієнті
Попередня ціна вичисляется на сервері. Але фінальна ціна при поїздці повинна оновлюватися в реальному часі: таксометр. Відстань — з накопичених GPS-точок треку (сумування дистанцій між точками через Haversine або vincenty formula), час — системний таймер. Локальний розрахунок важливий для offline-сценарію та щоб водій бачив актуальну суму без постійних запитів до сервера.
Архітектура та стек
Clean Architecture з розділенням на шари: presentation (ViewModel / BLoC), domain (use cases), data (repositories). Для кроссплатформи — Flutter з нативними модулями для location та push; для нативного підходу — Swift + UIKit/SwiftUI на iOS, Kotlin + Jetpack Compose на Android.
Real-time обмін даними — WebSocket або MQTT для координат та статусів. MQTT переважніше при нестабільному з'єднанні: QoS 1 гарантує доставку, малий overhead, підтримка reconnect з коробки.
Етапи: аналіз сценаріїв роботи водія → проектування FSM замовлення → location-модуль → навігація → push та уведомлення → інтеграція з backend → тестування на флоті реальних пристроїв → публікація.
Графік: від 8 до 16 тижнів для повноцінного водійського додатку. Вартість розраховується індивідуально після аналізу вимог.