Розробка мобільного додатку для паркінгу

Вступ

Розробка мобільного додатку для паркінгу стикається з основною проблемою: реальна завантаженість парковки — це потік подій, а не статична таблиця. Користувач шукає місце біля торгового центру, карта показує «вільно» — він їде, а парковка повна. Дані застаріли на 15 хвилин. Ми вирішуємо цю проблему через пряму інтеграцію з обладнанням та платіжними системами, забезпечуючи достовірну картину в реальному часі.

Інтеграція з паркувальним обладнанням

Реальні дані про зайнятість місць надходять від шлагбаумів, петлевих детекторів або ультразвукових сенсорів через протокол MQTT або WebSocket до брокера (mosquitto, EMQX). Мобільний додаток підписується на топік парковки та отримує оновлення в реальному часі. Це вимагає persistent connection, яку на мобільних пристроях реалізуємо через Starscream (iOS WebSocket) або OkHttp WebSocket (Android). З'єднання розривається при переході додатку в background — для iOS використовуємо BGProcessingTask, для Android — WorkManager з періодичною перевіркою.

Якщо бюджет не дозволяє інтеграцію з «залізом» — використовуємо дані з платіжної системи: в'їзд фіксується при оплаті в'їзду, виїзд — при оплаті/підйомі шлагбаума. Точність нижча, але дані реальні.

Безшовна оплата

Найкритичніший UX-момент — оплата парковки без черги до терміналу. Три поширені сценарії:

1. Передоплата за номером машини. Користувач вводить номер, вибирає час, платить. На виїзді камера ANPR звіряє номер і відкриває шлагбаум. Інтеграція з російськими системами ANPR (Vocord, ITRIUM) або міжнародними (Genetec, Milestone).

2. Scan & Pay. QR-код на в'їзді, користувач сканує, додаток запам'ятовує час в'їзду, оплата при виїзді. Реалізується через AVCaptureSession (iOS) або CameraX з BarcodeScanner з ML Kit (Android) — не потрібне окреме SDK для QR.

3. NFC-мітки. Дотик до NFC-мітки на в'їзді/виїзді. Core NFC (iOS 11+) або NfcAdapter (Android). Обмеження iOS: NFC працює тільки в foreground, не можна сканувати в background без спеціального entitlement.

Для оплати інтегруємо Stripe, ЮKassa або CloudPayments залежно від географії — усі три надають нативні SDK для iOS/Android.

Порівняння способів оплати — розробка мобільного додатку

Як забезпечити live-статус парковки?

Ключовий елемент — вибір протоколу обміну даними. MQTT або WebSocket з event-driven моделлю. В одному з проєктів для мережі з 8 паркінгів (близько 2000 місць) ми замінили polling (кожні 60 секунд) на event-driven архітектуру з MQTT та WebSocket-проксі. Затримка оновлення впала з 60 до 1–2 секунд, а трафік знизився в 30 разів: 1440 запитів на день проти 10–50 повідомлень. Результат: real-time статус став головним драйвером задоволеності користувачів.

Чому real-time статус критичний у мобільному додатку для паркінгу?

Зазначимо: коли водій бачить вільне місце і приїжджає, а воно зайняте — це втрачений час і довіра до додатку. Поллінг з інтервалом хвилина дає застарілі дані в пікові години. Event-driven архітектура (MQTT/WebSocket) гарантує, що користувач отримує лише актуальні зміни, без паразитного трафіку. Порівняння архітектур: event-driven краще polling в 30 разів за обсягом трафіку і в 30-60 разів за затримкою.

Порівняння навантажень: Polling vs Event-Driven

Карта та навігація до вільного місця

Карту паркінгу (порівнева схема місць) відображаємо через SVG-рендеринг або кастомний Canvas. Google Maps та MapKit тут не підходять — потрібен indoor layout. Використовуємо SVG з ідентифікаторами на кожен паркувальний бокс, розфарбовуємо залежно від статусу через DOM manipulation або нативний Canvas.drawPath.

Навігація до парковки — стандартний Google Maps / MapKit deep link. Навігація всередині паркінгу (до вільного місця) — опціонально через BLE-маяки (Estimote, Kontakt.io) з Indoor Positioning. Це додає складність і ціну, обґрунтовано лише для великих багаторівневих паркінгів.

Як впровадити real-time статус: покрокова інструкція

1. Аудит обладнання парковки (шлагбауми, сенсори, платіжні термінали).
2. Вибір протоколу: MQTT або WebSocket залежно від навантажень.
3. Налаштування брокера (mosquitto, EMQX) та підписка мобільного додатку на топіки.
4. Реалізація persistent connection на мобільній стороні (BGProcessingTask/WorkManager).
5. Інтеграція з платіжним шлюзом (Stripe, ЮKassa) для синхронізації в'їздів/виїздів.
6. Тестування на реальному обладнанні протягом 2 тижнів.
7. Розгортання та моніторинг (Firebase Crashlytics + Sentry).

Що входить у розробку під ключ

• Аудит існуючого обладнання та платіжної інфраструктури
• Проектування інтеграцій (MQTT/REST від контролерів, ANPR, платіжний шлюз)
• Дизайн схеми паркінгу та мобільного інтерфейсу
• Розробка MVP за 6–10 тижнів, повна версія з indoor-навігацією до 4 місяців
• Тестування на реальному обладнанні (шлагбауми, сенсори)
• Публікація в App Store та Google Play, налаштування моніторингу (Firebase Crashlytics + Sentry)
• Гарантійна підтримка 3 місяці, навчання адміністраторів

Етапи та терміни