Водійський додаток таксі — технічно найскладніший із трьох клієнтів системи (водій, пасажир, диспетчер). Він має працювати у фоні годинами, приймати замовлення навіть при нестабільному інтернеті, точно відстежувати маршрут і не розряджати телефон за зміну. На Android 13+ система вбиває фонові сервіси через 3 хвилини, якщо не дотримано вимог. Таке траплялося з одним клієнтом: водії скаржилися, що не бачать нових замовлень. Довелося переробити location-модуль на ForegroundService та додати постійне сповіщення. Після цього втрати замовлень знизилися на 25%. Грамотна архітектура економить до 40% часу на доробках після запуску. Ми розробляємо такі додатки під ключ.
Як організувати фонову геолокацію в додатку водія таксі?
Водій не тримає телефон у руках постійно. Додаток має отримувати замовлення через push, трекати маршрут та оновлювати сервер кожні 3–5 секунд. На iOS використовуємо CLLocationManager з allowsBackgroundLocationUpdates. Відключаємо pausesLocationUpdatesAutomatically. У режимі очікування перемикаємося на significant-change для економії батареї. На Android — ForegroundService зі сповіщенням. Без нього MIUI 14, EMUI 12 та Samsung OneUI 6 вбивають процес через 5–10 хвилин. Використовуємо FusedLocationProviderClient з PRIORITY_HIGH_ACCURACY у поїздці та PRIORITY_BALANCED_POWER_ACCURACY в очікуванні. Перемикання за статусом замовлення. Згідно з документацією Android, ForegroundService — єдиний спосіб.
| Платформа | API | Особливості | Економія батареї |
|---|---|---|---|
| iOS | CLLocationManager, allowsBackgroundLocationUpdates, background mode location | Система автоматично призупиняє оновлення при бездіяльності; можна переключитися на significant-change | Автоматично через pausesLocationUpdatesAutomatically |
| Android | ForegroundService + FusedLocationProviderClient | Потрібне постійне сповіщення; для тривалого фону — тільки ForegroundService | Перемикання між high accuracy та balanced power за статусом замовлення |
Як забезпечити надійний прийом замовлень при поганому інтернеті?
Нове замовлення приходить як FCM/APNs data push. Водій приймає або відхиляє — це має працювати навіть при поганому з'єднанні (тунелі, паркінги). Правильна схема: локальна черга прийнятих/відхилених рішень з retry-логікою на WorkManager (Android) або BackgroundTasks (iOS). Якщо відповідь не дійшла за 10 секунд — повторна спроба, інакше диспетчер вважає замовлення неприйнятим. Використання MQTT з QoS 1 гарантує доставку повідомлень швидше, ніж стандартний REST. Таймаут прийняття замовлення — класична грабля. Сервер дає водію 15–20 секунд. Якщо push прийшов із затримкою (FCM може затримувати до кількох хвилин у Doze mode) — водій бачить замовлення, натискає «прийняти», отримує помилку «замовлення вже розподілено». Рішення: timestamp створення замовлення в payload push, клієнт перевіряє вік замовлення перед відображенням діалогу. Локальна черга з WorkManager знижує втрати даних на 90%.
Чому важлива статусна машина замовлення?
Водійський додаток — строго скінченний автомат. Стани:
| Статус | Опис | Дія |
|---|---|---|
| idle | Очікування замовлення | Прослуховування push |
| offer_received | Отримано нове замовлення | Діалог прийняття |
| accepted | Замовлення прийнято | Блокування інших замовлень |
| en_route_to_pickup | Їде до пасажира | Відображення маршруту |
| arrived_at_pickup | На місці посадки | Сповіщення пасажира |
| in_trip | Поїздка | Таксометр, трек |
| completed | Поїздку завершено | Розрахунок, історія |
Кожен перехід — запит до сервера з підтвердженням. UI блокує кнопки до отримання відповіді, щоб виключити подвійні натискання. Помилка «arrived» натиснутої двічі — реальна проблема: водій натиснув кнопку, вона не відреагувала (лаг мережі), натиснув ще раз, обидві команди дійшли. Сервер має бути ідемпотентним по transition, клієнт — показувати spinner і блокувати повторні натискання до відповіді.
Як вибрати навігаційний SDK для таксі?
Інтеграція з картами — ключова частина. Для водійського додатку важливий turn-by-turn з голосовими підказками. Mapbox Navigation SDK для iOS та Android має готовий NavigationViewController / NavigationView з кастомізованим UI. Google Maps не надає готовий turn-by-turn UI — доведеться будувати самостійно на Directions API + TTS. Mapbox потребує менше часу на інтеграцію, ніж Google Maps з самостійною реалізацією. Також доступні 2GIS (хороше покриття СНД) та HERE Navigation SDK (трафік у реальному часі). Вибір залежить від регіонів роботи та бюджету. Перебудова маршруту при відхиленні — rerouting має спрацьовувати автоматично при відхиленні від треку більш ніж на 50–100 метрів. У Mapbox це вбудовано в SDK, у Google — потрібно реалізовувати самостійно.
Яка архітектура підходить для додатку таксі?
Чиста архітектура (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 з коробки. Налаштування ProGuard/R8 потребує правил для збереження моделей та Location API.
Що входить в роботу
- Проектування FSM замовлення та архітектури
- Реалізація location-модуля з фоновим режимом
- Інтеграція навігації та push-сповіщень
- Налаштування код-підпису та provisioning profile (iOS), ProGuard/R8 (Android)
- Публікація в App Store та Google Play, включаючи TestFlight та Firebase App Distribution
- Документація API та коду
- Навчання водіїв роботі з додатком
- Пост-релізна підтримка протягом місяця
Які етапи та терміни розробки?
- Аналіз сценаріїв роботи водія — 1–2 тижні
- Проектування FSM та архітектури — 1–2 тижні
- Розробка location-модуля — 2–3 тижні
- Інтеграція навігації та push — 2–3 тижні
- Інтеграція з backend — 2–3 тижні
- Тестування на реальних пристроях — 1–2 тижні
- Публікація — 1 тиждень
Загальний термін: від 8 до 16 тижнів. Вартість розраховується індивідуально, виходячи зі складності інтеграцій та вимог до платформ.
Наш досвід — понад 50 реалізованих проектів у сфері мобільної розробки. Отримайте консультацію з архітектури додатку та термінів розробки. Зв'яжіться з нами, щоб обговорити ваш проект.