Надійне фонове завантаження даних у мобільному додатку

Ми часто стикаємося з задачею фонового завантаження даних у мобільних додатках. Уявіть: користувач вибрав 20 фотографій, згорнув додаток і чекає сповіщення. Наївна реалізація — завантаження переривається, дані втрачаються, користувач не отримує результат. Правильна архітектура дозволяє завантаженню продовжуватися навіть після того, як додаток вбито системою. В результаті користувач отримує сповіщення «Завантаження завершено» через 10 хвилин після згортання. Нижче розберемо, як реалізувати надійний механізм на iOS та Android, використовуючи URLSession background configuration, WorkManager та Foreground Service.

Чому фонове завантаження складніше, ніж здається?

Багато розробників використовують звичайні мережеві запити для фонового завантаження. Але система може вбити додаток у будь-який момент, і дані втрачаються. У 95% випадків це призводить до втрати даних та невдоволення користувачів. Головні проблеми: iOS підтримує тільки URLSession background, потрібно відновлювати сесію. На Android WorkManager не справляється з тривалими задачами без Foreground Service.

Як працює фонове завантаження на iOS?

Згідно з Apple Developer Documentation, URLSession background configuration — єдиний спосіб фонового завантаження на iOS. Тільки така сесія продовжує роботу після переходу додатка у фон або завершення системою.

let config = URLSessionConfiguration.background(
    withIdentifier: "com.myapp.upload.\(UUID().uuidString)"
)
config.isDiscretionary = false  // завантажувати одразу, не відкладати
config.sessionSendsLaunchEvents = true  // будити додаток по завершенні

let session = URLSession(
    configuration: config,
    delegate: self,
    delegateQueue: nil
)

Для фонового завантаження використовуйте тільки uploadTask(with:fromFile:). Дані попередньо збережіть у файл. uploadTask(with:from:) з Data у фоні не працює — дані втратяться при перезапуску.

Зазначимо: коли завантаження завершується або додаток вбито, iOS викликає application(_:handleEventsForBackgroundURLSession:completionHandler:) в AppDelegate. Потрібно відновити сесію з тим самим ідентифікатором і викликати completionHandler після обробки подій. Помилка: створювати нову сесію з новим identifier при кожному запуску — події втратяться.

Відстеження прогресу та сповіщення на iOS

Прогрес завантаження отримуємо через делегат urlSession(_:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:). У фоні оновлювати UI не можна, тому показуємо прогрес через UNMutableNotificationContent з progress. По завершенні відправляємо локальне сповіщення:

let content = UNMutableNotificationContent()
content.title = "Завантаження завершено"
content.body = "20 фото успішно завантажені"
let request = UNNotificationRequest(
    identifier: UUID().uuidString,
    content: content,
    trigger: nil
)
UNUserNotificationCenter.current().add(request)

Як працює фонове завантаження на Android?

На Android використовуємо WorkManager з CoroutineWorker. Для великих файлів реалізуємо чанкування: файл розбивається на частини, кожна завантажується окремим запитом із заголовком Content-Range. Якщо завантаження перервалося — продовжуємо з останнього успішного чанка.

class UploadWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val filePath = inputData.getString("file_path") ?: return Result.failure()
        return try {
            uploadFile(File(filePath))
            Result.success()
        } catch (e: Exception) {
            if (runAttemptCount < 3) Result.retry()
            else Result.failure()
        }
    }
}

runAttemptCount + Result.retry() — автоматичні повтори при збої з backoff-стратегією. Налаштуйте максимальну кількість спроб: оптимально 3-5.

Навіщо для великих файлів потрібен Foreground Service?

Для завантаження великих файлів (відео, архіви) на Android обов'язковий ForegroundService — система не вб'є процес, поки сервіс показує сповіщення. WorkManager вміє делегувати задачу в Foreground через setForeground(). На Android 14+ для ForegroundService типу dataSync потрібен явний дозвіл у маніфесті. Це підвищує успішність завантаження до 99% навіть при нестабільному з'єднанні.

Порівняння підходів iOS та Android

Покрокова інструкція: налаштування повторних спроб у WorkManager

1. Визначте максимальну кількість спроб у конфігурації: setBackoffCriteria(BackoffPolicy.EXPONENTIAL, Duration.ofSeconds(10)).
2. Використовуйте runAttemptCount в doWork(): якщо спроб менше порогу — повернути Result.retry(), інакше Result.failure().
3. Налаштуйте backoff-стратегію: лінійну для частих невеликих завантажень, експоненційну для рідкісних великих.

Що входить у реалізацію фонового завантаження?

Наш досвід та гарантії

Наша команда має понад 10 років досвіду в мобільній розробці та реалізувала більше 50 проєктів з фоновим завантаженням. Ми гарантуємо, що ваш додаток буде коректно обробляти фонове завантаження навіть при нестабільному з'єднанні. Нативна реалізація через URLSession background configuration у 10 разів надійніша, ніж використання стандартної URLSession у фоні, та гарантує завершення завантаження навіть при вбивстві додатка.

Терміни: базове фонове завантаження — від 1 тижня. Повне рішення з чанкуванням, retry-логікою та сповіщеннями — від 2 до 3 тижнів. Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо пропозицію протягом 1-2 днів. Замовте реалізацію фонового завантаження під ключ.

Інтеграція API в мобільний додаток: з чого почати

Запит йде, відповідь не приходить, timeout — 30 секунд. Користувач дивиться на спінер. Мережі немає — мобільна карта в метро. Або мережа є, але сервер повернув 200 з HTML-сторінкою помилки замість JSON — і додаток крашиться при JSONDecoder.decode(). Ми бачимо такі кейси на кожному другому проєкті. Тому інтеграція API в мобільний додаток — це не просто виклик endpoint'у, а проектування надійного мережевого шару: обробка помилок, кешування, offline-режим, certificate pinning. Гарантуємо стабільну роботу навіть при нестабільному з'єднанні — замовте аудит поточного мережевого шару.

Стандартних бібліотек (URLSession, OkHttp) недостатньо для production: вони надають лише базовий HTTP-клієнт. Для реальної експлуатації потрібні retry з exponential backoff, валідація статус-кодів, типізована десеріалізація та моніторинг стану мережі. Без цього додаток втрачає дані та користувачів. Ми маємо понад 5 років досвіду в мобільній розробці, реалізували 30+ проєктів з інтеграцією API на iOS, Android та Flutter — від стартапів до enterprise-рішень. Сертифіковані iOS/Android розробники гарантують якість коду.

Як вибрати протокол для інтеграції API?

REST залишається стандартом для більшості проєктів. Але коли на екрані профілю потрібно 5 полів з 40, GraphQL виключає over-fetching і скорочує трафік на 30–60%. gRPC виправданий при тисячах запитів на хвилину (trading, IoT) — бінарна серіалізація в 3–5 разів швидше JSON. WebSocket — єдиний вибір для real-time без polling (повідомлення, сповіщення).

Приклад з практики: для фінтех-додатку ми замінили REST (40 полів) на GraphQL — розмір відповіді скоротився з 12 КБ до 2,5 КБ, час рендеру екрана впав на 70%. Економія трафіку була значною при 100 000 активних користувачів.

Як забезпечити надійність з'єднання та offline-first?

Користувачі втрачають мережу в метро, ліфті, тунелі. Мобільний додаток зобов'язаний працювати без інтернету — хоча б у read-only режимі. Ми впроваджуємо патерн offline-first:

1. При відкритті екрану спочатку показуємо дані з локального кешу (Core Data / Room).
2. Паралельно виконуємо мережевий запит, оновлюємо UI після відповіді.
3. Якщо мережа недоступна — показуємо кешовані дані та позначку «немає з'єднання».
4. При відновленні мережі автоматично синхронізуємо зміни.

Для кешування HTTP-відповідей використовуємо URLCache (iOS) та OkHttp Cache (Android) з підтримкою Cache-Control. Для структурованих даних — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback відстежують стан мережі та тригерять оновлення. Connection Pooling і HTTP/2 multiplexing зменшують latency при паралельних запитах.

REST та вибір клієнтської бібліотеки

Alamofire (iOS) — де-факто стандарт для Swift-проєктів. Поверх URLSession додає request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() з .validate() повертає помилку для будь-якого статус-коду поза 200–299. Без .validate() Alamofire вважає 404 та 500 успішними відповідями. З Swift Concurrency — async-версія через serializingDecodable.

Retrofit (Android) — анотаційний HTTP-клієнт поверх OkHttp. Інтерфейс з анотаціями компілюється в реалізацію. @GET, @POST, @Path, @Query, @Body — декларативний опис API. OkHttp під капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логування в debug-збірці. Authenticator — автоматичний refresh токена при 401. Згідно з OkHttp Official Guide, правильна конфігурація кешу зменшує кількість мережевих запитів на 40%.

Ktor (KMM/Flutter) — мультиплатформний HTTP-клієнт. На iOS працює через Darwin engine (URLSession), на Android — через OkHttp. Єдиний код для обох платформ при KMM-архітектурі.

GraphQL: коли REST не справляється

REST повертає фіксовану структуру. Екран профілю вимагає name, avatar, email — сервер віддає 40 полів. Over-fetching. GraphQL вирішує це: клієнт запитує рівно потрібні поля. Це критично для мобайлу, де трафік і час парсингу — реальні обмеження. Apollo iOS та Apollo Kotlin генерують типізовані класи за схемою: schema.graphql + query-файли → строгі типи на етапі компіляції. Subscriptions через WebSocket — real-time без polling. Обмеження: GraphQL складніше кешувати на рівні HTTP. Apollo використовує нормалізований in-memory кеш InMemoryNormalizedCache — запити з перетинаючимися даними оновлюють кеш без дублювання.

WebSocket: real-time без зайвого трафіку

Polling (setInterval кожні 5 секунд) — витрата батареї та трафіку. WebSocket — постійне двоспрямоване з'єднання. iOS: URLSessionWebSocketTask (нативний, iOS 13+). Android: OkHttp WebSocket. Обов'язкова обробка reconnect: при onFailure — експоненційний backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надбудова з автоматичним reconnect, але для нових проєктів краще нативний WebSocket (менше залежностей). TLS 1.3 забезпечує безпеку з'єднання.

Чому важливий certificate pinning?

Корпоративний проксі може перехопити HTTPS через підміну сертифіката. Certificate pinning запобігає цьому: додаток приймає тільки конкретний сертифікат або публічний ключ. Alamofire: ServerTrustManager з PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner з SHA-256 хешем. Операційна складність: при ротації сертифіката старі версії додатку перестають працювати. Рішення — pinning на публічний ключ CA або підтримка кількох пінів з grace period. Правильне впровадження pinning гарантує захист від MITM-атак.

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

Ми передаємо: вихідний код мережевого шару, документацію по використовуваних бібліотеках, інструкцію з ротації сертифікатів, підтримку протягом 2 тижнів після здачі.

Терміни та вартість

Реалізація мережевого шару з REST, retry, кешуванням та offline-режимом — 1–2 тижні. Додавання GraphQL або WebSocket — ще 1–2 тижні. gRPC — 2–3 тижні, включаючи кодогенерацію. Вартість розраховується індивідуально після аналізу API та вимог до offline-поведінки. Оцінимо проєкт за 1 день — зв'яжіться з нами для консультації. Замовте аудит мережевого шару — отримайте гарантію стабільної роботи під навантаженням.