Розробка мобільного додатку для кур'єрської служби
Кур'єр прийняв замовлення, виїхав — і додаток упав в background-killed на Android Xiaomi з MIUI. FusedLocationProvider перестав видавати координати, трек оборвався, диспетчер не бачить машину. Це не гіпотетичний сценарій — це стандартна проблема кур'єрських додатків на агресивних лаунчерах MIUI, OneUI, EMUI, де foreground service убивається збірником сміття батареї.
Проблема: геотрекінг на Android
На Android для безперервної геолокації потрібен Foreground Service з явним сповіщенням у рядку статусу. Без нього на Xiaomi/Huawei/OPPO додаток помре через 5–10 хвилин у фоні незалежно від WakeLock. Але й foreground service не панацея: MIUI додає обмеження батареї навіть на запущені сервіси, якщо користувач не дозволив автозапуск вручну.
Правильний підхід: при першому запуску показуємо Intent на системний екран «Автозапуск» (для MIUI — com.miui.securitycenter, для Huawei — com.huawei.systemmanager). Це не завжди красиво, але це єдиний спосіб гарантувати трекінг. Плюс — батч-відправка координат: накопичуємо точки в пам'яті, відправляємо кожні 10–15 секунд одним запитом замість 15 окремих.
На iOS проблем менше: CLLocationManager з allowsBackgroundLocationUpdates = true і pausesLocationUpdatesAutomatically = false працює надійно. Але significant-change location updates не підходять для кур'єрів — вони спрацьовують лише при зміні соти (~500 м точність), що не годиться для відображення на карті в реальному часі.
Архітектура двох додатків
Кур'єрський сервіс — це майже завжди два окремих додатки: для кур'єра й для клієнта. Іноді додається третій — диспетчерський web-інтерфейс. Але мобільна частина може бути в одному проєкті з різними flavor/scheme:
-
Android Flavors:
courierApp/clientApp— різніapplicationId, іконки, дозволи - iOS Targets: два target'и в одному Xcode-проєкті, спільний код через SPM-пакет
Це дозволяє переіспользовувати бізнес-логіку (мережевий шар, моделі даних, геолокаційний модуль) між двома додатками без дублювання коду.
Алгоритм призначення та маршрутизація
Логіка розподілу замовлень живе на сервері. Мобільний клієнт лише отримує призначення через push (FCM/APNs з priority: high) та підтверджує прийняття. Важливо: FCM high priority на Android гарантує доставку навіть в Doze mode, але лише якщо у додатку є RECEIVE_BOOT_COMPLETED і правильно налаштований FirebaseMessagingService.
Маршрут до одержувача будуємо через Google Maps Directions API або OSRM (якщо потрібен self-hosted без плати за API-вклики). Покроку навігацію не реалізуємо в додатку — відкриваємо Google Maps / Яндекс.Навігатор через deep link, передаючи координати точки доставки.
ETA та трекінг для клієнта
Клієнт бачить кур'єра на карті — це WebSocket або Server-Sent Events від сервера до клієнтського додатку. Координати оновлюються кожні 5–10 секунд. На карті використовуємо Marker з анімацією щоб точка не стрибала, а плавно рухалась — ValueAnimator (Android) або CABasicAnimation (iOS).
ETA розраховується на боці сервера через Google Maps Distance Matrix API або HERE Routing API і передається клієнту. Не обчислюємо ETA на пристрої — там немає актуальних даних про пробки.
Підтвердження доставки
Три варіанти підтвердження, які зустрічаються частіше за все:
- Фото посилки/двері —
CameraX(Android) абоAVFoundation(iOS) + завантаження в S3/GCS - PIN-код, який знає одержувач — простий TOTP або статичний код з замовлення
- Підпис на екрані —
Canvas/UIBezierPath, зберігаємо як SVG або PNG
Код підпису робимо з strokeWidth залежним від швидкості руху пальця — виглядає значно натуральніше, ніж лінія постійної товщини.
Етапи та строки
Мінімальний життєздатний продукт — два додатки (кур'єр + клієнт) з геотрекінгом, призначенням замовлень та підтвердженням доставки: 6–10 тижнів при команді 2 розробника + дизайнер. Повна платформа з диспетчерським модулем, аналітикою та інтеграцією з зовнішніми OMS/WMS-системами — 4–6 місяців. Вартість розраховується індивідуально після аналізу вимог.