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