Разработка мобильного приложения для службы такси (водитель)
Водительское приложение такси — технически самое сложное из трёх клиентов системы (водитель, пассажир, диспетчер). Оно должно работать в фоне часами, принимать заказы даже при нестабильном интернете, точно отслеживать маршрут и не разряжать телефон за смену. Большинство проблем в готовых MVP всплывают именно здесь.
Фоновый режим и геолокация: где всё ломается
Водитель не держит телефон в руках постоянно. Приложение должно:
- Получать новые заказы через push даже с выключенным экраном
- Продолжать трекинг маршрута в фоне
- Обновлять серверу текущее положение каждые 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 недель для полноценного водительского приложения. Стоимость рассчитывается индивидуально после анализа требований.