При розробці додатків для каршерингу ми стикаємося із завданням: як передати команду "відкрити двері" за 2–4 секунди без подвійного натискання? Якщо блок не відповідає 30 секунд, користувач натискає повторно — двері відчиняються двічі. Classic fire-and-forget. Рішення — використовувати idempotency key і підтвердження через callback: додаток надсилає унікальний ключ команди, сервер гарантує одноразове виконання, а результат приходить у push-сповіщенні.
Ми реалізували таку схему в 30+ каршерингових проектах. Досвід показує: навіть при втраті GPRS-з'єднання callback-механізм за 30 секунд повертає статус «автомобіль не відповів», а не «щось пішло не так». Це рятує користувацький досвід і знижує навантаження на підтримку на 30–40%.
Особливості розробки мобільного додатку для каршерингу
Серце каршеринг-платформи — телематичний блок (Teltonika FMB140, Queclink GV620, Neomatica ADM700), який з'єднується з сервером через GPRS/LTE і приймає команди: відкрити/закрити двері, дозволити/заборонити запуск двигуна, увімкнути сигналізацію. Мобільний додаток не спілкується з машиною напряму — все через сервер.
Схема команди:
- Додаток надсилає команду на API (
POST /cars/{id}/commands) з idempotency-key - Сервер записує команду в чергу (RabbitMQ або Kafka)
- Воркер надсилає команду на телематичний блок через TCP/UDP
- Блок підтверджує виконання
- Сервер надсилає push-сповіщення додатку про результат
Якщо крок 4 не відбувся за 30 секунд — сервер повертає помилку, додаток показує конкретний статус. Гарантуємо, що кожен перехід стану оренди (available → reserved → active → completed) атомарний на сервері.
Як забезпечити надійність команд керування автомобілем?
Idempotency key — UUID, який генерує клієнт і повторно використовує при повторних спробах. Сервер перевіряє ключ і не виконує команду повторно. Callback-механізм (Webhook або WebSocket) доставляє результат. Це вирішує проблему подвійного відкриття дверей.
Додатково: додаток відображає прогрес виконання команди — "Надсилаємо команду...", "Автомобіль підтвердив". Якщо через 30 секунд немає відповіді, показуємо "Автомобіль не знайдено". Так користувач розуміє, що робити.
Server-side clustering для відображення флоту
Відображення флоту на карті — 500+ автомобілів онлайн. Client-side clustering гальмує: 800 мс на рендеринг. Server-side clustering: сервер повертає кластери з центроїдами та лічильником, клієнт малює агреговані маркери. Час рендерингу — 200 мс. Порівняння:
| Метод | Час рендерингу (500 маркерів) | Навантаження на клієнт |
|---|---|---|
| Client-side clustering | 800 мс | Високе (CPU, пам'ять) |
| Server-side clustering | 200 мс | Низьке (тільки відмальовка) |
При зумі > 14 переходимо до окремих іконок з кольоровою індикацією заряду батареї або рівня палива. Пошук «знайти найближчу вільну машину» — запит з геолокацією користувача та радіусом. PostGIS на бекенді (ST_DWithin) + індекс на координатах. Відповідь — список з відстанню та маршрутом пішки через Google Maps Directions (режим WALKING).
Які етапи включає розробка каршеринг-додатку?
Ми використовуємо ітеративний підхід: аудит → архітектура → дизайн → розробка → тестування → публікація. Ось що входить у кожен етап:
| Етап | Зміст | Результат |
|---|---|---|
| Аудит телематичної інфраструктури | Аналіз встановлених блоків, протоколів, API | Технічне завдання з сумісністю |
| Архітектура state machine | Проектування станів оренди та API-контракту | OpenAPI-специфікація |
| Дизайн | Карта, пошук, онбординг, екрани сесії | Figma-макети |
| Розробка | Реалізація MVP (карта, бронювання, відкриття, оплата, завершення) | Робочий білд |
| Верифікація | Інтеграція KYC, тестування граничних кейсів | Звіт про тестування |
| Публікація | Підготовка до App Store (категорія Transport) та Google Play | Сторіс-скріншоти, метадані |
Терміни: MVP — 3–4 місяці, повна платформа з аналітикою, корпоративним кабінетом та розширеною телематикою — 6–9 місяців. Вартість розраховується індивідуально після аудиту вимог.
Верифікація та онбординг — розробка мобільного додатку
Каршеринг вимагає верифікації водійського посвідчення та паспорта. Інтеграція з сервісами 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). Знижує навантаження на службу перевірки, але потребує якісного датасету.
Що входить у розробку (deliverables)
- Архітектурна документація (OpenAPI, ER-діаграми)
- Доступи до репозиторію, CI/CD пайплайну, тестового стенду
- Навчання команди замовника (2 дні)
- 3 місяці гарантійної підтримки після релізу
Замовте консультацію для оцінки вашої телематики – ми підберемо оптимальну архітектуру. Зв'яжіться з нами, щоб отримати детальний план розробки. 10+ років досвіду та 30+ каршерингових проектів гарантують стабільну роботу при будь-якому навантаженні.