Оптимізація введення адреси: автодоповнення у мобільних застосунках

Оптимізація введення адреси: автодоповнення та кешування

Уявіть: користувач вводить «Тверск», система за 300 мс пропонує 5 варіантів. Без правильної реалізації кожне натискання — окремий запит до API, 70% користувачів кидають форму при затримках понад 2 секунди. Середній час введення адреси з автодоповненням — 8 секунд, без нього — 35 секунд (за даними Nielsen Norman Group). Технічна складність — не просто прикрутити бібліотеку, а обрати провайдера, налаштувати дебаунс, кеш та session token. Розберемо, як це зробити правильно.

Як обрати провайдера для геокодування?

Для більшості українських проєктів ми рекомендуємо зв'язку DaData + Google: DaData як перший пріоритет, Google як fallback для закордонних адрес. Це знижує вартість запитів на 40% відносно використання лише Google. DaData в 2 рази точніший за Nominatim для адрес України — це критично для логістики. Google Places з session token в 3–5 разів дешевший, ніж без токена.

Чому важливий session token у Google Places?

На iOS використовуємо GooglePlaces pod та GMSPlacesClient.findAutocompletePredictions(fromQuery:filter:sessionToken:callback:). Ключовий момент — GMSAutocompleteSessionToken: один токен на всю сесію пошуку (від першого символу до вибору результату). Це знижує вартість у 3–5 разів порівняно із запитом без токена. Як зазначає Google Places documentation: «Використання сесійних токенів дозволяє згрупувати кілька запитів в один білінг».

let token = GMSAutocompleteSessionToken()
let filter = GMSAutocompleteFilter()
filter.type = .address
filter.countries = ["UA", "BY", "KZ"]

placesClient.findAutocompletePredictions(
    fromQuery: query,
    filter: filter,
    sessionToken: token
) { results, error in
    guard let results else { return }
    self.suggestions = results.map { $0.attributedFullText.string }
}

Після вибору адреси викликаємо fetchPlace(fromPlaceID:placeFields:sessionToken:) для отримання координат — і обнуляємо токен. Без fetchPlace координати не отримати через автодоповнення.

На Android — Places.initialize(context, apiKey) + PlacesClient. У Jetpack Compose:

val placesClient = Places.createClient(context)
val request = FindAutocompletePredictionsRequest.builder()
    .setQuery(query)
    .setSessionToken(AutocompleteSessionToken.newInstance())
    .setTypesFilter(listOf(PlaceTypes.ADDRESS))
    .setCountries("UA", "BY")
    .build()

placesClient.findAutocompletePredictions(request)
    .addOnSuccessListener { response ->
        _suggestions.value = response.autocompletePredictions
    }

Що дає дебаунс запитів?

Без дебаунса кожне натискання клавіші — окремий API-запит. При середньому введенні 4 символи на секунду це 4 запити замість одного. Наш досвід показує, що правильний дебаунс 350 мс скорочує кількість запитів на 70%.

Покрокова реалізація дебаунса:

1. Створіть Publisher/Flow з текстового поля.
2. Застосуйте оператор debounce(for: 350 ms).
3. Додайте фільтр довжини запиту >= 3 символи.
4. Використовуйте flatMapLatest для відміни попереднього запиту.

На iOS через Combine:

searchTextField.textPublisher
    .debounce(for: .milliseconds(350), scheduler: DispatchQueue.main)
    .removeDuplicates()
    .sink { [weak self] query in
        guard query.count >= 3 else { return }
        self?.fetchSuggestions(for: query)
    }

На Android через StateFlow:

searchQuery
    .debounce(350)
    .filter { it.length >= 3 }
    .distinctUntilChanged()
    .flatMapLatest { fetchSuggestions(it) }
    .stateIn(viewModelScope, SharingStarted.Lazily, emptyList())

flatMapLatest відміняє попередній запит при новому введенні — без цього старі результати можуть перекрити актуальні.

Офлайн і кеш: як покращити UX?

Останні 10–20 обраних адрес зберігаємо локально (UserDefaults / SharedPreferences) і показуємо при порожньому полі введення. Це вирішує найчастіший кейс: користувач кожного разу замовляє додому.

Для історії пошуку — Room / Core Data з колонками address_string, lat, lon, last_used_at. При введенні спочатку шукаємо по локальній базі (LIKE-запит), потім паралельно запитуємо API — показуємо спочатку локальний результат, замінюємо на API-результат при приході. Час відгуку з кешу — 2–5 мс проти 200–500 мс з API.

class AddressSearchViewModel: ObservableObject {
    @Published var query = ""
    @Published var suggestions: [String] = []
    private var cancellables = Set<AnyCancellable>()
    private let placesClient = GMSPlacesClient()
    private let token = GMSAutocompleteSessionToken()

    init() {
        $query
            .debounce(for: .milliseconds(350), scheduler: DispatchQueue.main)
            .removeDuplicates()
            .filter { $0.count >= 3 }
            .flatMapLatest { [weak self] query -> AnyPublisher<[String], Never> in
                guard let self = self else { return Just([]).eraseToAnyPublisher() }
                return Future { promise in
                    let filter = GMSAutocompleteFilter()
                    filter.type = .address
                    filter.countries = ["UA"]
                    self.placesClient.findAutocompletePredictions(
                        fromQuery: query,
                        filter: filter,
                        sessionToken: self.token
                    ) { results, error in
                        guard let results = results, error == nil else {
                            promise(.success([]))
                            return
                        }
                        promise(.success(results.map { $0.attributedFullText.string }))
                    }
                }.eraseToAnyPublisher()
            }
            .receive(on: DispatchQueue.main)
            .assign(to: &$suggestions)
    }

    func selectAddress(_ placeID: String) {
        let token = GMSAutocompleteSessionToken()
        let fields: GMSPlaceField = [.coordinate, .formattedAddress]
        placesClient.fetchPlace(fromPlaceID: placeID, placeFields: fields, sessionToken: token) { place, error in
            guard let coordinate = place?.coordinate else { return }
            // зберігаємо координати
        }
    }
}

Як тестувати автокомпліт на граничних випадках?

Тестування автокомпліту виявляє помилки, які складно відловити в production. Ми використовуємо підхід mock-шар: підміняємо API-відповіді тестовими даними (порожня відповідь, затримки, помилки). Перевіряємо граничні рядки: порожній рядок, один символ, спецсимволи (!@#$), дуже довгі адреси (200+ символів), адреси з нестандартними літерами (умлаути, кирилиця). Також імітуємо збої мережі та тайм-аути — застосунок має коректно показувати fallback-повідомлення та не крашитися. У нас є чек-лист із 25+ сценаріїв для кожного проєкту.

Що входить у роботу?

• Вибір та інтеграція провайдера (DaData, Google, Yandex).
• Розробка UI-компонента з випадним списком (SwiftUI / Jetpack Compose).
• Реалізація дебаунса, відміни запитів, session token.
• Локальне кешування історії адрес.
• Обробка помилок: відсутність мережі, ліміти API, некоректне введення.
• Тестування на граничних рядках (порожнє введення, спецсимволи, дуже довгі адреси).
• Документація з інтеграції.

Ми реалізували пошук адрес у 30+ проєктах — від служб доставки до геоінформаційних систем. Гарантуємо стабільну роботу при високих навантаженнях. Оцініть свій проєкт — зв'яжіться з нами для консультації.

Термін реалізації: два–чотири дні — провайдер, UI, дебаунс, кеш історії, тестування. Вартість розраховується індивідуально під ваші завдання. Отримайте консультацію — дізнайтеся, скільки займе інтеграція вашого застосунку.

Карти та геолокація в мобільних додатках: 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 годин.