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