Розроблення мобільного додатку для таксі
Додаток для таксі — одна із технічно щільних задач у мобільній розробці. Не тому що який-то компонент сам по собі складний, а тому що тут сходяться сразу кілька систем: геолокація, real-time трекінг, матчинг водіїв, розрахунок вартості, платіжний шлюз, push-сповіщення та підтримка офлайн-стану. Проблеми виникають на стиках.
Два додатки та один бекенд
Додаток пасажира та додаток водія — різні продукти з різною логікою, але спільним API. Проектувати їх як єдину систему одразу, не доробляти по ходу — інакше API буде розростатися непередбачувано.
Мінімальний склад системи:
- Додаток пасажира (iOS + Android)
- Додаток водія (iOS + Android)
- Бекенд API (REST + WebSocket/MQTT)
- Панель адміністратора (опціонально на першому етапі)
Геолокація та пошук водіїв
Ключовий сценарій: пасажир відкриває додаток → бачить найближчих водіїв на карті → призначається оптимальний → бачить його рух у реальному часі.
Водії, перебуваючи в режимі очікування, відправляють координати кожні 5-10 секунд. Сервер зберігає актуальні позиції в Redis Geo: GEOADD drivers_online {lon} {lat} {driver_id}. Пошук найближчих: GEORADIUS drivers_online {lon} {lat} 3 km WITHCOORD WITHDIST COUNT 10 ASC — повертає ID водіїв у радіусі 3 км, відсортованих по відстані, за одиниці мілісекунд.
Після призначення водія — WebSocket-канал між пасажиром та водієм. Проміжний сервер пересилає координати водія тільки призначеному пасажиру. Трансляція координат всіх водіїв всім пасажирам — невірна архітектура.
Розрахунок маршруту та вартості
Google Directions API або OSRM (self-hosted, безплатно) для розрахунку маршруту від водія до пасажира та від пасажира до пункту призначення. Відповідь містить distance (метри) та duration (секунди) — база для передварительного розрахунку вартості.
Формула вартості: base_price + per_km * distance_km + per_min * duration_min. Плюс коефіцієнт спроса (surge pricing) — зберігається на сервері, множиться при дефіциті водіїв. Итоговую вартість завжди рахуємо на сервері, не на клієнті — клієнт тільки показує.
Ціноутворення на маршруті. Передварительна ціна vs фінальна: показуємо пасажиру розраховану вартість до поїздки, фіксуємо фінальну на основі фактичного маршруту. Різницю обмежуємо ± 15-20% — інакше користувачі скаржитимуться на неочікувані списання.
Додаток водія: ключові екрани та логіка
Режим онлайн/офлайн. При переході в онлайн — запускається Foreground Service (Android) / background location (iOS), координати починають відправлятися. Водій з'являється в Redis Geo. При офлайні — сервіс зупиняється, водій зникає з пулу.
Входящий замовлення. Push-сповіщення + WebSocket-подія одночасно. Якщо WebSocket з'єднання активне — приоритет йому (швидше). Звуковий сигнал + вібрація, таймер 15-20 секунд на прийняття. При відсутності відповіді — замовлення передається наступному водієві.
Навігація. Після прийняття замовлення — маршрут на карті з пошаговими інструкціями. Можна використовувати нативну навігацію: MKMapItem.openMaps() на iOS або Intent(ACTION_VIEW, Uri.parse("google.navigation:q=...")) на Android. Або вбудувати навігацію через Mapbox Navigation SDK — це дорожче у розробці, але користувач не уходит з додатку.
Статуси поїздки. accept → arriving → waiting → in_progress → completed. Кожен перехід — явна дія водія (кнопка), не автоматика. Автоматика тільки для таймаутів.
Додаток пасажира
Екран замовлення. Карта з поточною позицією, поле вводу адреси призначення з автодополненням (Google Places API або DaData), вибір класу автомобіля, передварительна вартість, кнопка «Замовити».
Після замовлення. Анімований маркер водія рухається до пасажира. Відстань та час до прибуття оновлюються у реальному часі через WebSocket. Дані водія: ім'я, фото, рейтинг, марка та номер автомобіля.
Під час поїздки. Маршрут на карті, поточне положення, розраховуючи час прибуття. Кнопка SOS → дзвінок в службу безпеки або екстрений контакт.
Після поїздки. Оцінка водія (1-5 зірок), чаївниці, чек на email/SMS.
Платіжна інтеграція
В Росії — CloudPayments, YooKassa (ЮKassa), Tinkoff Acquiring. SDK для iOS та Android — готові, інтеграція займає день. Важливо: для збереження карти користувача використовуємо токенізацію — реальний номер карти не зберігається в додатку та на наших серверах, тільки токен.
CloudPayments iOS SDK: CPCloudPayments → CRPaymentForm.present(with:). Android: CloudPaymentsApi.doPay(context, cryptogram, saveCard).
Apple Pay / Google Pay — пріоритетний спосіб для користувачів без збереженої карти. PKPaymentAuthorizationViewController на iOS, PaymentsClient із Google Pay API на Android.
Push-сповіщення
Firebase Cloud Messaging (FCM) — і iOS, і Android через єдиний SDK. APNs для iOS працює через FCM-прошарок. Типи сповіщень: входящий замовлення водієві, водій прибиває (пасажиру), поїздка завершена, чек.
Критичний сценарій: сповіщення про входящий замовлення повинне розбудити додаток водія, якщо він у фоні. На Android — data-сповіщення (не notification) запускає onMessageReceived навіть у фоні. На iOS — content-available: 1 для silent push + звичайний alert для відображення.
Стек
| Компонент | Технології |
|---|---|
| iOS | Swift, SwiftUI/UIKit, GoogleMaps SDK, FCM |
| Android | Kotlin, Jetpack Compose, Google Maps SDK, FCM |
| Flutter (опціонально) | Dart, google_maps_flutter, firebase_messaging |
| Бекенд | Node.js / Go / Python (FastAPI), WebSocket, Redis Geo, PostgreSQL + PostGIS |
| Платежі | CloudPayments / YooKassa + Apple Pay / Google Pay |
Тривалість проекту
Мінімальний MVP (одна платформа пасажир + водій, базова навігація, один платіжний метод): шість-десять тижнів.
Повноцінне додаток (обидві платформи, surge pricing, історія поїздок, панель адміністратора, аналітика): чотири-шість місяців.
Вартість розраховується індивідуально після аналізу вимог та декомпозиції завдань.