Разработка мобильного приложения для каршеринга
Пользователь нажимает «разблокировать» на карте — команда уходит на CAN-шину автомобиля через IoT-блок, дверь открывается через 2–4 секунды. Если через 30 секунд ничего не произошло, он нажимает ещё раз. Дверь открывается дважды. Вот почему команды управления автомобилем требуют idempotency key и подтверждения через callback, а не fire-and-forget.
Телематика и управление автомобилем
Сердце каршеринг-платформы — это телематический блок в машине (Teltonika FMB140, Queclink GV620, Neomatica ADM700 или аналоги), который соединяется с сервером через GPRS/LTE и принимает команды: открыть/закрыть двери, разрешить/запретить запуск двигателя, включить сигнализацию. Мобильное приложение само по себе с машиной не разговаривает — всё через сервер.
Схема команды:
- Приложение отправляет команду на API (POST
/cars/{id}/commands) с idempotency-key - Сервер пишет команду в очередь (RabbitMQ или Kafka)
- Воркер отправляет команду на телематический блок через TCP/UDP
- Блок подтверждает выполнение
- Сервер отправляет push-уведомление приложению о результате
Если шаг 4 не произошёл за 30 секунд — сервер возвращает ошибку, приложение показывает конкретный статус. Не «что-то пошло не так», а «автомобиль не ответил на команду — возможно, нет сети в данной точке».
Карта и поиск автомобиля
Отображение флота на карте — это clustering маркеров при низком зуме. Google Maps SDK и MapKit оба поддерживают это нативно, но при 500+ автомобилях онлайн нужен server-side clustering: сервер возвращает кластеры с центроидами и счётчиком, клиент рисует агрегированные маркеры. При зуме > 14 переходим к отдельным иконкам с цветовой индикацией заряда батареи / уровня топлива.
Поиск «найти ближайшую свободную машину» — запрос с геолокацией пользователя и радиусом. PostGIS на бэкенде (ST_DWithin) + индекс на координатах. Ответ — список с расстоянием и маршрутом пешком через Google Maps Directions (режим WALKING).
Онбординг и верификация
Каршеринг требует верификации водительского удостоверения и паспорта. Стандартный путь — интеграция с сервисами liveness + document recognition:
- Smile Identity или Onfido для международных проектов
- Суфтех, GetID или ЕЦРН (через Госуслуги / ГИС МВД) для российского рынка
Техническая реализация: нативная камера с подсказками по расположению документа (оверлей с рамкой), загрузка фото через multipart/form-data, polling статуса верификации через WebSocket. Не храним фото документов на устройстве дольше сеанса загрузки.
Аренда и оплата
Сессия аренды — это state machine: available → reserved → active → completed. Каждый переход атомарен на сервере. Мобильный клиент отображает текущий статус через WebSocket subscription или long-polling с ETag.
Оплата — Stripe (международно) или ЮKassa/CloudPayments (РФ). Важный нюанс: холдирование суммы (payment_intent со статусом requires_capture) при начале аренды, реальное списание после завершения с пересчётом по факту времени. Stripe SDK для iOS и Android предоставляет готовые Payment Sheet, которые уже обрабатывают 3DS, SCA, сохранение карт.
Проверка состояния автомобиля
До начала аренды пользователь фотографирует царапины и повреждения. Это защита и для него, и для оператора. Реализуем через CameraX с multiple captures, загружаем в облако (S3/GCS) с геометкой (EXIF GPS данные) и timestamp. После завершения аренды — то же самое.
Автоматическое распознавание повреждений через ML-модель (YOLOv8 fine-tuned на повреждения авто) — опциональная фича, которую реализуем через Core ML (iOS) или TensorFlow Lite (Android). Снижает нагрузку на службу проверки, но требует качественного датасета.
Архитектура и стек
| Компонент | Технология |
|---|---|
| Кроссплатформенная разработка | Flutter (BLoC) |
| Нативный Android | Kotlin + Compose + Hilt |
| Нативный iOS | Swift + SwiftUI + Combine |
| Карты | Google Maps SDK / MapLibre |
| Телематика | REST API + WebSocket |
| Оплата | Stripe SDK / ЮKassa SDK |
| Верификация | Onfido / GetID |
| Краш-мониторинг | Firebase Crashlytics |
| A/B тесты | Firebase Remote Config |
Этапы разработки
- Аудит телематической инфраструктуры — какие блоки установлены, какой протокол, есть ли API
- Архитектура state machine аренды на сервере + API-контракт с мобильным клиентом
- Дизайн — карта, поиск, онбординг, сессия аренды
- Разработка — MVP включает: карту с флотом, бронирование, открытие автомобиля, оплату, завершение аренды
- Верификация — интеграция с KYC-провайдером, тестирование пограничных кейсов (просроченное ВУ, нечёткое фото)
- Публикация — App Store (категория Transport) + Google Play
Сроки: MVP — 3–4 месяца, полная платформа с аналитикой, корпоративным кабинетом и расширенной телематикой — 6–9 месяцев. Стоимость рассчитывается индивидуально после аудита требований.