Розроблення мобільного застосунку для логістичної компанії
Мобільний застосунок для логістики охоплює кілька ролей одночасно: водій в полі, менеджер складу, клієнт, який чекає доставку, та оператор у офісі. Розроблення починається не з коду, а з картування цих ролей та точок їх перетину — інакше вийде набір розрізнених екранів замість єдиної системи.
Управління замовленнями та оптимізація маршруту
Логістична компанія обробляє десятки або сотні доставок на день. Ключева проблема водія — оптимальний порядок об'їзду точок. Це задача Travelling Salesman Problem (TSP), для практичних обсягів вирішується евристиками: найближчий сусід, 2-opt, або готові API.
Google Routes Optimization API (раніше Route Optimization AI) приймає список адрес та обмежень (часові вікна, вантажопідйомність) та повертає оптимальний маршрут. Google OR-Tools — бібліотека з відкритим кодом для серверної частини. Для невеликих обсягів (до 20-30 точок) можна рахувати на клієнті; для більших — серверний сервіс.
Часові вікна доставки — важливий бізнес-параметр. Клієнт замовив доставку «з 14 до 16». Якщо водій приїде в 17:30 — претензія. Алгоритм маршрутизації має враховувати ці вікна та попередити диспетчера про нереалістичні розклади.
Сканування штрих-кодів та QR
Підтвердження отримання через сканування — стандарт в логістиці. MLKit Barcode Scanning (Google, на пристрої) та Vision Framework (Apple, VNDetectBarcodesRequest) — швидше та точніше за Zxing. MLKit розпізнає QR, Code128, EAN-13, DataMatrix без інтернету, що критично для складу з поганим покриттям.
Інтеграція в застосунок: CameraX (Android) або AVCaptureSession (iOS) з постійним перегляданням та overlay для прицілювання. Важливо: автоматичне закриття перегляду після успішного сканування та вібрація як тактильне підтвердження.
Інвентаризація та склад
Складський модуль — окремий флоу. Працівник сканує коробку, бачить її вміст та статус, може змінити локацію або позначити пошкодження. Потрібна робота в офлайні: склад може бути в підвалі без LTE. Room (Android) / Core Data (iOS) як локальне сховище з синхронізацією при відновленні мережі через WorkManager / BackgroundTasks.
Конфлікти при синхронізації — якщо два працівники змінили один товар офлайн — потрібна стратегія розв'язання: останній запис перемагає, або explicit conflict UI («дані змінилися на сервері, виберіть версію»).
Трекінг та клієнтський застосунок
Клієнт хоче бачити, де його посилка прямо зараз. Це або окремий застосунок, або публічна веб-сторінка з трекінгом за номером замовлення. Для мобільного клієнтського застосунку: карта з маркером кур'єра, анімація руху (інтерполяція аналогічно пасажирському таксі), 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 тижнів для повної логістичної системи. Вартість розраховується індивідуально.