Разработка мобильного приложения для паркинга
Пользователь ищет место рядом с торговым центром, карта показывает «свободно» — он едет, а парковка полная. Данные устарели на 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
Стоимость зависит от набора интеграций. Рассчитывается индивидуально после аудита инфраструктуры паркинга.