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

При розробці додатків для каршерингу ми стикаємося із завданням: як передати команду "відкрити двері" за 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 і приймає команди: відкрити/закрити двері, дозволити/заборонити запуск двигуна, увімкнути сигналізацію. Мобільний додаток не спілкується з машиною напряму — все через сервер.

Схема команди:

1. Додаток надсилає команду на API (POST /cars/{id}/commands) з idempotency-key
2. Сервер записує команду в чергу (RabbitMQ або Kafka)
3. Воркер надсилає команду на телематичний блок через TCP/UDP
4. Блок підтверджує виконання
5. Сервер надсилає 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 мс. Порівняння:

При зумі > 14 переходимо до окремих іконок з кольоровою індикацією заряду батареї або рівня палива. Пошук «знайти найближчу вільну машину» — запит з геолокацією користувача та радіусом. PostGIS на бекенді (ST_DWithin) + індекс на координатах. Відповідь — список з відстанню та маршрутом пішки через Google Maps Directions (режим WALKING).

Які етапи включає розробка каршеринг-додатку?

Ми використовуємо ітеративний підхід: аудит → архітектура → дизайн → розробка → тестування → публікація. Ось що входить у кожен етап:

Терміни: 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+ каршерингових проектів гарантують стабільну роботу при будь-якому навантаженні.

Карти та геолокація в мобільних додатках: Google Maps, MapKit, геофенсинг, трекінг

Ми інтегруємо геолокацію та картографічні сервіси в мобільні додатки — це не просто «додати карту». Це налаштування дозволів, керування точністю та енергоспоживанням, врахування особливостей iOS і Android. Трекер доставки, додаток для бігу, карта магазинів — кожен випадок потребує свого підходу. Замовте консультацію — оцінимо ваш проєкт за 2 години.

Дозволи: одне з найчастіших джерел поганих відгуків

На iOS дозвіл на геолокацію — найчутливіший після мікрофона та камери. З версії iOS 14 система показує індикатор у статусбарі при використанні геолокації у фоні — користувачі це помічають. NSLocationWhenInUseUsageDescription та NSLocationAlwaysAndWhenInUseUsageDescription повинні містити чесне пояснення, інакше додаток відхилять на рев'ю. Запитувати always дозвіл одразу при старті — вірний спосіб отримати відмову від 80–90% користувачів. Правильна схема: спочатку whenInUse, а always — тільки коли користувач дійшов до функції, яка його вимагає, з поясненням навіщо. App Store Review Guidelines (Section 5.1) вимагають чіткого обґрунтування.

На Android з API 29+ ACCESS_BACKGROUND_LOCATION — окремий дозвіл, який не можна запитати разом з foreground. Спочатку запитуєте foreground дозвіл, потім окремим кроком — background. Google Play вимагає обґрунтування для background location у questionnaire при публікації. Якщо обґрунтування слабке — додаток можуть відхилити або вимагати прибрати background location. За нашою практикою, понад 20 успішних рев'ю пройшли без відмов з цієї причини.

Як збалансувати точність та енергоспоживання?

Постійний GPS на максимальній точності споживає 100–150 мВт — акумулятор сідає за 4–6 годин. Для більшості завдань це надмірно. Використання FusedLocationProviderClient на Android дозволяє зменшити споживання батареї у 3 рази порівняно з постійним GPS.

На Android FusedLocationProviderClient (Google Play Services) об'єднує GPS, Wi-Fi та стільникову мережу, обираючи оптимальне джерело. LocationRequest.Builder з пріоритетами:

• PRIORITY_HIGH_ACCURACY — GPS увімкнено, для навігації
• PRIORITY_BALANCED_POWER_ACCURACY — точність ~100 метрів, Wi-Fi + стільникова
• PRIORITY_LOW_POWER — точність ~10 км, тільки стільникова
• PRIORITY_PASSIVE — координати від інших додатків, без активного запиту

Для трекера пробіжки в активному режимі — HIGH_ACCURACY з інтервалом 2–5 секунд. Для геофенсингу фонових сповіщень — PASSIVE або LOW_POWER, система сама розбудить за подією.

На iOS CLLocationManager з desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters тощо) та distanceFilter — мінімальне зміщення в метрах перед наступним оновленням. Для трекінгу маршруту зі збереженням батареї: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — отримуємо оновлення тільки при реальному русі.

Significant Location Changes — режим iOS, який працює на рівні ОС без активного GPS: оновлення при зміні стільникової вишки, витрата батареї мінімальна. Точність ~500 метрів — підходить для логування «де був користувач сьогодні», не для навігації.

Як обрати картографічний SDK? Порівняльний аналіз

Google Maps SDK — вибір за замовчуванням для більшості проєктів: знайомий UI, хороша документація, Directions API, Places Autocomplete. Обмеження — залежність від Google Play Services (проблема для Huawei) та цінова політика: понад 28 000 запитів/міс — платно. Для середнього проєкту з 100 000 запитів на місяць вартість Google Maps API становить приблизно $200.

Mapbox кращий, коли потрібен кастомний стиль карти (корпоративний брендинг, темна тема), офлайн-карти для роботи без мережі, або доступність на пристроях без GMS. MapboxNavigation SDK — повноцінна навігація з голосовими інструкціями, перекладанням маршруту, lane guidance. Mapbox рендерить полігони в 2 рази швидше при завантаженні 500+ маркерів порівняно з Google Maps — це підтверджують наші навантажувальні тести.

Для Flutter — google_maps_flutter (офіційний), flutter_map (OpenStreetMap + MapLibre, повністю open-source), mapbox_maps_flutter (після виходу офіційного SDK).

Геофенсинг: причини затримки спрацювання

Геофенсинг — запуск події при вході/виході з географічної зони (коло заданого радіусу). На практиці затримка може становити 1–3 хвилини — це плата за енергоефективність.

На Android — GeofencingClient з Google Location Services. Додаємо Geofence об'єкти з setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) та PendingIntent на BroadcastReceiver. Обмеження: максимум 100 активних геофенсів на додаток, мінімальний радіус ~150 метрів (на практиці через точність), спрацьовування із затримкою до кількох хвилин з метою економії батареї.

На iOS — CLCircularRegion + CLLocationManager.startMonitoring(for:). Ліміт: 20 регіонів на додаток. ОС керує коли перевіряти — розробник не контролює затримку. Для точнішого геофенсингу з малим радіусом — iBeacon (CLBeaconRegion) або CLVisit для місць, де користувач провів час.

Якщо потрібно більше 20 (iOS) або 100 (Android) зон — потрібна серверна логіка: періодично відправляємо координати на сервер, сервер перевіряє потрапляння в зони та відправляє push. Менш точно за часом, але масштабується на тисячі зон.

Трекінг маршрутів і фонова геолокація

Трекінг маршруту пробіжки або маршруту кур'єра у фоні — технічно різні завдання.

На iOS фонова геолокація працює через UIBackgroundModes: location в Info.plist. Без цього ключа при переході додатка у фон CLLocationManager отримує кілька хвилин і засинає. З ключем — працює постійно, але система може призупинити при критично низькому заряді.

Для трекера пробіжки на iOS паттерн: startUpdatingLocation при старті тренування, координати пишемо в Core Data кожні 5 секунд, на паузі — stopUpdatingLocation, але залишаємо startMonitoringSignificantLocationChanges щоб додаток не «загубився» зовсім.

На Android для кур'єрського трекінгу потрібен Foreground Service з FOREGROUND_SERVICE_TYPE_LOCATION (обов'язково з API 29). Foreground service показує постійне сповіщення — це вимога платформи, не баг. Без нього Android Doze вб'є оновлення геолокації. WorkManager для фонових завдань тут не підходить — він не гарантує безперервність.

Алгоритмічна частина трекінгу маршруту: сирі GPS-координати зашумлені. Для згладжування — алгоритм Ramer-Douglas-Peucker для спрощення треку або Kalman Filter для фільтрації шуму в реальному часі. Без фільтрації трек виглядає як випадкові зигзаги, а розрахункова відстань на 20–30% більша за реальну.

Як ми впроваджуємо карти та геолокацію: покроковий процес

1. Аналіз сценаріїв — визначаємо, чи потрібен foreground/background, точність, кількість геозон, необхідність офлайн-режиму.
2. Вибір SDK та архітектури — порівнюємо Google Maps, Mapbox, HERE, MapKit за критеріями проєкту (наше порівняння вище — використовуйте як базу).
3. Інтеграція та налаштування дозволів — прописуємо Info.plist / AndroidManifest.xml, тестуємо рев'ю-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
4. Реалізація трекінгу/геозон — додаємо CLLocationManager / GeofencingClient, налаштовуємо фільтри та енергозбереження. Для отримання безкоштовної консультації напишіть нам.
5. Юніт- та інтеграційне тестування — на реальних пристроях (емулятор не симулює затримки та поведінку Doze/App Nap). Перевіряємо не менше 50 сценаріїв.
6. Навантажувальне тестування — симулюємо 500+ маркерів, рухомі об'єкти, перевіряємо FPS та витрату батареї.
7. Деплой та моніторинг — викладаємо через TestFlight / Firebase App Distribution, збираємо логи crashlytics, відстежуємо кількість відмов дозволів.

Терміни та що входить у роботу

Що ви отримаєте в будь-якому випадку:

• Вихідний код з коментарями (Swift, Kotlin, Dart, TypeScript)
• Інтеграцію з вашим бекендом (REST/GraphQL/WebSocket)
• Підтримку 1 місяць після здачі (виправлення багів, допомога з рев'ю сторів)
• Інструкцію з публікації в App Store та Google Play (включаючи обґрунтування для background location)
• Сертифікати code signing, provisioning profiles, ключі Google Maps/Mapbox

Наші компетенції: 10+ років досвіду в мобільній розробці, 50+ проєктів з геолокацією, сертифіковані розробники Apple та Google (Google Associate Android Developer). Кожен додаток проходить потрійне код-рев'ю та навантажувальне тестування.

Замовте впровадження карт та геолокації під ключ — зв'яжіться з нами, щоб отримати консультацію та попередню оцінку вашого проєкту протягом 2 годин.