Розробка мобільного додатку для паркінгу
Користувач шукає місце біля торгового центру, карта показує «вільно» — він їде, а парковка повна. Дані застарілі на 15 хвилин. Це найчастіший сценарій провалу паркінг-додатків: реальна завантаженість парковки — це потік подій, а не статична таблиця в базі, яку хтось оновлює раз на N хвилин.
Інтеграція з паркінг-обладнанням
Реальні дані про зайнятість місць надходять від шлагбаумів, петльових детекторів або ультразвукових датчиків через протокол MQTT або WebSocket до брокера (mosquitto, EMQX). Мобільний додаток підписується на топік паркінгу та отримує оновлення в реальному часі. Це вимагає persistent connection, яку на мобільних пристроях реалізуємо через Starscream (iOS WebSocket) або OkHttp WebSocket (Android). З'єднання рветься при переході додатку в background — для iOS використовуємо BGProcessingTask, для Android — WorkManager з періодичною перевіркою.
Якщо бюджет не дозволяє інтеграцію з обладнанням — використовуємо дані з платіжної системи: в'їзд фіксується при оплаті в'їзду, виїзд — при оплаті/підіманні шлагбаума. Точність гірша, але дані реальні.
Безшовна оплата
Найкритичніший UX-момент — оплата паркінгу без черги до терміналу. Три поширених сценарії:
Передоплата за номером машини. Користувач вводить номер, обирає час, платить. На виїзді камера ANPR перевіряє номер і відкриває шлагбаум. Інтеграція з російськими ANPR-системами (Vocord, ITRIUM) або міжнародними (Genetec, Milestone).
Scan & Pay. QR-код на в'їзді, користувач сканує, додаток запам'ятовує час в'їзду, оплата при виїзді. Реалізується через AVCaptureSession (iOS) або CameraX з BarcodeScanner з ML Kit (Android) — не потрібне окреме SDK для QR.
NFC-метки. Прикосновення до NFC-метки на в'їзді/виїзді. Core NFC (iOS 11+) або NfcAdapter (Android). Обмеження iOS: NFC працює лише в foreground, не можна сканувати в background без спеціального entitlement.
Для оплати інтегруємо Stripe, ЮKassa або CloudPayments залежно від географії — всі три надають нативні SDK для iOS/Android.
Карта паркінгу та навігація до вільного місця
Карту паркінгу (поуровнева схема місць) відображаємо через SVG-рендеринг або кастомний Canvas. Google Maps та MapKit не підходять — потрібен indoor layout. Використовуємо SVG з ідентифікаторами на кожен паркомісце, розфарбовуємо залежно від статусу через DOM manipulation або нативний Canvas.drawPath.
Навігація до паркінгу — стандартний Google Maps / MapKit deep link. Навігація всередину паркінгу (до вільного місця) — опціонально через BLE-маячки (Estimote, Kontakt.io) з Indoor Positioning. Це додає складність і ціну, обґрунтовано лише для великих багаторівневих паркінгів.
З практики
Додаток для мережі паркінгів: 8 об'єктів, ~2000 місць. Перша версія оновляла дані про зайнятість через REST API з polling кожні 60 секунд. Скарги на «показує неверно» йшли постійно. Після переходу на MQTT з WebSocket-проксі та серверними подіями затримка оновлення впала до 1–2 секунд. Споживання трафіку знизилось — polling раз в хвилину давав ~1440 запитів в день, WebSocket з event-driven оновленням — 10–50 повідомлень залежно від активності паркінгу.
Етапи та строки
- Аудит існуючого обладнання та платіжної інфраструктури
- Проектування інтеграцій (MQTT/REST від контролерів, ANPR, платіжний шлюз)
- Дизайн схеми паркінгу та мобільного інтерфейсу
- Розробка — зазвичай MVP за 6–10 тижнів, повна версія з indoor-навігацією до 4 місяців
- Тестування на реальному обладнанні (шлагбауми, датчики)
- Публікація та моніторинг через Firebase Crashlytics + Sentry
Вартість залежить від набору інтеграцій. Розраховується індивідуально після аудиту інфраструктури паркінгу.