Разработка мобильного приложения для логистической компании
Мобильное приложение для логистики охватывает несколько ролей одновременно: водитель в поле, менеджер склада, клиент ожидающий доставку, и оператор в офисе. Разработка начинается не с кода, а с картирования этих ролей и точек их пересечения — иначе получается набор разрозненных экранов вместо единой системы.
Управление заказами и маршрутная оптимизация
Логистическая компания обрабатывает десятки или сотни доставок в день. Ключевая проблема водителя — оптимальный порядок объезда точек. Это задача Travelling Salesman Problem (TSP), для практических объёмов решается эвристиками: nearest neighbor, 2-opt, или готовыми API.
Google Routes Optimization API (бывший Route Optimization AI) принимает список адресов и ограничений (временные окна, грузоподъёмность) и возвращает оптимальный маршрут. OR-Tools от Google — open source библиотека для серверной стороны. Для небольших объёмов (до 20-30 точек) можно считать на клиенте; для больших — серверный сервис.
Временные окна доставки — важный бизнес-параметр. Клиент заказал доставку «с 14 до 16». Если водитель приедет в 17:30 — претензия. Алгоритм маршрутизации должен учитывать эти окна и предупреждать диспетчера о нереалистичных расписаниях.
Сканирование штрих-кодов и QR
Подтверждение получения через сканирование — стандарт в логистике. MLKit Barcode Scanning (Google, работает on-device) и Vision Framework (Apple, VNDetectBarcodesRequest) — быстрее и точнее, чем Zxing. MLKit распознаёт QR, Code128, EAN-13, DataMatrix без интернета, что критично для склада с плохим покрытием.
Интеграция в приложение: CameraX (Android) или AVCaptureSession (iOS) с постоянным превью и overlay для прицеливания. Важно: автоматическое закрытие превью после успешного сканирования и вибрация как тактильное подтверждение.
Инвентаризация и склад
Складской модуль — отдельный флоу. Работник сканирует коробку, видит её содержимое и статус, может изменить локацию или отметить повреждение. Нужна работа в офлайне: склад может быть в подвале без LTE. Room (Android) / Core Data (iOS) как локальное хранилище с синхронизацией при восстановлении сети через WorkManager / BackgroundTasks.
Конфликты при синхронизации — если два работника изменили один товар офлайн — нужна стратегия разрешения: last-write-wins, или explicit conflict UI («данные изменились на сервере, выберите версию»).
Трекинг и клиентское приложение
Клиент хочет видеть, где его посылка прямо сейчас. Это либо отдельное приложение, либо публичная web-страница с трекингом по номеру заказа. Для мобильного клиентского приложения: карта с маркером курьера, анимация движения (интерполяция аналогично пассажирскому такси), push-уведомления при смене статуса.
Статусная модель доставки: created → picked_up → in_transit → out_for_delivery → delivered / failed. Каждый переход — push-уведомление. failed с причиной и предложением перенести доставку.
Аналитика и отчётность
Менеджерский модуль: дашборд с KPI — процент доставок в срок, среднее время на точку, маршруты с задержками на карте тепловой карты. Heatmap через Google Maps TileOverlay с кастомным тайловым провайдером или Mapbox HeatmapLayer. Данные — агрегация из backend API, кешируются локально с TTL 5-10 минут.
Стек и архитектура
Clean Architecture обязательна при такой сложности: разные роли → разные модули → общее ядро. Flutter с модульной структурой (feature_core, feature_driver, feature_warehouse, feature_client) — каждый модуль компилируется отдельно, что ускоряет сборку и позволяет командам работать параллельно.
Push: FCM для Android и APNs для iOS через единый backend (Firebase Admin SDK или Expo Notifications). Карты: Google Maps SDK или Mapbox, выбор зависит от географии клиента.
Этапы: аудит бизнес-процессов → ролевая модель → проектирование API → параллельная разработка модулей → интеграция → нагрузочное тестирование → публикация.
Срок: от 16 до 28 недель для полной логистической системы. Стоимость рассчитывается индивидуально.