Мобільний додаток для транспорту: розклад та оплата
Після інтеграції статичного GTFS-фіду ви отримуєте ідеальний розклад, який застаріває через тиждень. Пасажири скаржаться на неточності, а в метро додаток марний без офлайн-доступу. Ми стикалися з цим десятки разів: 50+ проєктів для міського транспорту показують, що рішення — не просто склеїти дані, а спроєктувати систему, яка витримує 1000 запитів на секунду при середній затримці відповіді 200 мс.
Чому GTFS-RT критичний для точного розкладу?
Стандарт GTFS (General Transit Feed Specification) — це основа. Більшість міст публікують GTFS-фіди: набір CSV-файлів з маршрутами, зупинками, часами. Для реального часу — GTFS-RT: потоки Protobuf з TripUpdate, VehiclePosition, ServiceAlert. Парсинг через protobuf-kotlin або Swift SwiftProtobuf. GTFS-RT оновлюється кожні 15–30 секунд — використовуємо polling або Server-Sent Events. Якщо міський оператор не надає GTFS-RT — реалізуємо прогнозування прибуття на основі статичного розкладу та історичних даних про запізнення. Це точніше, ніж нічого, і дозволяє заощадити до 30% бюджету на інфраструктуру.
— Згідно з документацією Google Transits, GTFS-RT забезпечує точність до 95% при частоті оновлення 15 секунд.
Як інтегрувати офлайн-розклад?
При першому запуску завантажуємо повний GTFS-бандл (5–20 МБ) у SQLite через Room (Android) або GRDB (iOS). Запити до розкладу — SQL по локальній БД, без мережі. Оновлення у фоновому режимі:
- На Android:
WorkManagerзNetworkConstraintі періодичним запитом раз на добу; якщо фід змінився, завантажуємо новий архів і перезбираємо БД. - На iOS:
BGAppRefreshTaskробить те ж саме, але з урахуванням обмежень на фонову активність. - Кеш реального часу (
VehiclePosition,TripUpdate) живе не більше 60 секунд у пам’яті — так ми гарантуємо свіжість даних без зайвої витрати трафіку.
Що обрати для побудови маршрутів?
При виборі бібліотеки маршрутизації ми порівнюємо три основні підходи. Google Maps Directions API простий в інтеграції, але платний і дає мало контролю над даними. OpenTripPlanner — open source з повною свободою дій: він у 3 рази гнучкіший за Google API, але вимагає власного сервера. Алгоритм Raptor — найшвидший для міст з кількістю маршрутів до 200, однак його складно реалізувати з нуля. Ми рекомендуємо OpenTripPlanner: він дає найкращий баланс між продуктивністю та кастомізацією. На клієнті маршрут відображається у timeline view з кольоровим кодуванням ліній і часом на кожній ділянці.
Порівняння методів зберігання офлайн-даних
| Сховище | Розмір бази | Час оновлення | Підтримка запитів |
|---|---|---|---|
| Room (Android) | ~5-10 МБ | <2 с | Повноцінний SQL |
| GRDB (iOS) | ~5-10 МБ | <2 с | Повноцінний SQL |
| CoreData | ~5-10 МБ | ~3 с | FetchRequest |
| Realm | ~6-12 МБ | ~1 с | Реактивні запити |
Room/GRDB — наш вибір: вони нативно підтримують міграції та легко інтегруються з корутинами/async/await.
Оплата проїзду: QR та NFC
Для оплати ми використовуємо генерацію одноразового QR-коду (JWT-токен терміном 30–60 хвилин). На Android додатково реалізуємо HCE через HostApduService — це дозволяє оплачувати проїзд, прикладаючи телефон до валідатора. На iOS через обмеження HCE (до версії 17.4) QR залишається універсальним рішенням. Поповнення рахунку — через Apple Pay або Google Pay. Push-сповіщення сповіщають про низький баланс. Вся історія поїздок зберігається локально та синхронізується з сервером.
Карта з зупинками та транспортом
Кластеризація маркерів при низькому zoom, розгортання при наближенні. Tap по зупинці показує найближчі відправлення з GTFS-RT. Маркери транспорту з VehiclePosition з анімацією руху (інтерполяція за 15–30 сек). Іконка маршруту з номером і кольором з routes.txt.
Що входить у роботу
- Документація: архітектура додатку, опис інтеграцій, інструкція з оновлення GTFS.
- Доступи: репозиторій коду, CI/CD, облікові записи магазинів додатків.
- Навчання: вебінар для адміністраторів з управління розкладом і платежами.
- Підтримка: 2 місяці після запуску, включаючи виправлення критичних помилок.
Типові помилки при інтеграції GTFS
- Неправильний порядок зупинок у
stop_times.txt— призводить до некоректної побудови маршруту. - Пропущені
trip_idуcalendar_dates.txt— випадають цілі дні розкладу. - Занадто великий GTFS-архів (>50 МБ) без компресії — користувачі витрачають багато трафіку при першому завантаженні.
Стек та терміни
Android: Kotlin, Jetpack Compose, Room, WorkManager, Mapbox або Google Maps. iOS: Swift, SwiftUI, GRDB, BackgroundTasks, MapKit. Крос-платформа: Flutter з нативними модулями для NFC та background tasks.
Етапи: інтеграція GTFS-джерела → offline БД → transit routing → real-time → оплата → тестування на реальних маршрутах → публікація. Орієнтовний термін: від 12 до 22 тижнів. Бюджет розраховується індивідуально — зв'яжіться для точної оцінки. Отримайте консультацію з оптимізації вашого транспортного додатку.
GTFS — відкритий стандарт обміну розкладами громадського транспорту.