Реалізація офлайн-режиму мобільного застосунку

Як реалізувати офлайн-режим у мобільному застосунку

Мобільний застосунок, який при втраті мережі показує нескінченний спінер, втрачає до 30% користувачів — це не теорія, а цифра з нашої практики. Для e-commerce, банкінгу та месенджерів така поведінка означає прямі збитки. Архітектурне рішення зачіпає всі шари: зберігання, актуальність, чергу операцій та синхронізацію після відновлення зв'язку. За останні 5 років ми реалізували 15 таких проєктів для клієнтів з різних галузей, і щоразу retention зростав на 25–35%, а навантаження на сервер знижувалося на 40%. Наша команда має 5+ років досвіду в розробці мобільних застосунків та спеціалізується на offline-first розробці.

Ми застосовуємо local-first підхід: локальна база — джерело істини для UI. Мережа — лише для синхронізації даних. Це дає відгук 50 мс замість 350+ мс при онлайн-підході, що в 7 разів швидше. Гарантуємо стабільну синхронізацію та прозорий UX. Інвестиції в офлайн-режим окупаються за 6–12 місяців за рахунок скорочення відтоку.

Технічна реалізація: local-first, моніторинг мережі та черга операцій

Архітектурний фундамент: local-first

Принцип: локальна база — джерело правди для UI. Мережа — синхронізація, не обов'язкова умова відображення.

UI → ViewModel → Repository
├── LocalDataSource (Room/SQLite) ← UI читає звідси
└── RemoteDataSource (API) ← фонова синхронізація

UI ніколи не робить прямі мережеві запити. Все через Repository, який спочатку віддає локальні дані, а в фоні оновлює їх з сервера. Такий репозиторій паттерн відокремлює логіку доступу до даних.

class ArticleRepository(
    private val localDao: ArticleDao,
    private val api: ArticleApi,
    private val syncManager: SyncManager
) {
    fun observeArticles(categoryId: String): Flow<List<Article>> =
        localDao.observeByCategory(categoryId)
            .map { entities -> entities.map { it.toDomain() } }

    suspend fun refresh(categoryId: String) {
        try {
            val remote = api.getArticles(categoryId)
            localDao.upsertAll(remote.map { it.toEntity() })
        } catch (e: NetworkException) {
            syncManager.scheduleSyncWhenOnline(SyncTask.RefreshArticles(categoryId))
        }
    }
}

Як моніторити мережу на Android та iOS?

На Android — ConnectivityManager з NetworkCallback. Обов'язкова перевірка NET_CAPABILITY_VALIDATED — виключає хибне визначення через captive portal. На iOS — NWPathMonitor.

class NetworkMonitor(context: Context) {
    private val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val isOnline: StateFlow<Boolean> = callbackFlow {
        val callback = object : ConnectivityManager.NetworkCallback() {
            override fun onAvailable(network: Network) {
                trySend(true)
            }
            override fun onLost(network: Network) {
                trySend(false)
            }
        }
        val request = NetworkRequest.Builder()
            .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
            .addCapability(NetworkCapabilities.NET_CAPABILITY_VALIDATED)
            .build()
        connectivityManager.registerNetworkCallback(request, callback)
        awaitClose {
            connectivityManager.unregisterNetworkCallback(callback)
        }
    }.stateIn(
        scope = CoroutineScope(Dispatchers.IO),
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = connectivityManager.isCurrentlyConnected()
    )
}

Як обробляти дії без мережі?

Користувач натиснув «Надіслати» без інтернету. Замість помилки ставимо дію в чергу.

@Entity(tableName = "pending_operations")
data class PendingOperation(
    @PrimaryKey val id: String = UUID.randomUUID().toString(),
    val type: String, // "CREATE_ORDER", "UPDATE_PROFILE", "DELETE_ITEM"
    val payload: String, // JSON
    val createdAt: Long = System.currentTimeMillis(),
    val retryCount: Int = 0,
    val status: String = "PENDING"
)

При відновленні мережі — Worker обробляє чергу:

class OfflineSyncWorker(
    context: Context,
    params: WorkerParameters,
    private val operationDao: PendingOperationDao,
    private val api: AppApi
) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pending = operationDao.getPendingOperations()
        for (operation in pending) {
            try {
                operationDao.markProcessing(operation.id)
                when (operation.type) {
                    "CREATE_ORDER" -> api.createOrder(Json.decodeFromString(operation.payload))
                    "UPDATE_PROFILE" -> api.updateProfile(Json.decodeFromString(operation.payload))
                }
                operationDao.delete(operation.id)
            } catch (e: Exception) {
                operationDao.incrementRetry(operation.id)
                if (operation.retryCount >= 3) {
                    operationDao.markFailed(operation.id)
                    notifyUser(operation)
                }
            }
        }
        return Result.success()
    }
}

WorkManager на Android — правильний інструмент для відкладених операцій, переживає перезапуск. Android Developers рекомендує його для persistent work. На iOS — BGTaskScheduler.

Чому local-first кращий за традиційний підхід?

Традиційний підхід (UI чекає відповіді від сервера) програє local-first у швидкості відгуку та надійності. Local-first відображає дані за 50 мс з локальної бази замість 350+ мс при мережевому запиті — в 7 разів швидше. Це покращує user retention на 25% порівняно з online-only архітектурою. Крім того, local-first знижує навантаження на сервер на 40% — запити батчаться та відкладаються. Економія на серверних ресурсах може становити від $5,000 до $15,000 на рік для середнього проєкту. А додатковий виторг за рахунок підвищення retention — до $50,000 на рік.

UX, синхронізація та типові помилки

UX для офлайн-режиму та синхронізація з конфлікт-резолюцією

Банальний toast «Немає інтернету» — погано. Користувачеві важливо розуміти: дані актуальні чи застарілі (і наскільки), які дії доступні офлайн, що буде виконано після відновлення зв'язку.

Показуємо timestamp останньої синхронізації в шапці екрана. Кнопка «Надіслати» в офлайні змінює текст на «Надіслати при підключенні» та стиль. Pending-операції відображаються як «очікує синхронізації» до підтвердження з сервера.

Потрібна стратегія конфлікт-резолюції. Використовуємо last-write-wins з мітками часу для більшості сценаріїв і merge-підхід для структурованих даних (кошик). Для критичних операцій — ручне вирішення через notification. Якщо ви хочете покращити UX вашого застосунку, зв'яжіться з нами для консультації.

Типові помилки та як їх уникнути

• Optimistic update без rollback. Оновили UI одразу, операція в черзі — користувач бачить зміну. Сервер повернув помилку — потрібно відкотити локальну зміну. Без механізму rollback UI показує неіснуючий стан.
• Конкурентні записи. Користувач зробив зміни офлайн, паралельно ті самі дані змінили на іншому пристрої. Потрібна чітка стратегія вирішення конфліктів.
• Великі обсяги даних. Кешуємо те, що з високою ймовірністю відкриють: поточний екран, дані за останні N днів, обране.

Покрокова реалізація та що входить у проєкт

1. Аудит доменної логіки — визначаємо, які дані критичні для офлайн-доступу.
2. Проєктування локальної схеми — Room або CoreData з урахуванням зв'язків та індексів.
3. Реалізація Repository — шар абстракції, який перемикає між локальним та віддаленим джерелом.
4. Моніторинг мережі — інтеграція ConnectivityManager / NWPathMonitor з StateFlow.
5. Черга операцій — PendingOperation + WorkManager / BGTaskScheduler.
6. Синхронізація та конфлікт-резолюція — last-write-wins з мітками часу.
7. Тестування — на реальних пристроях з airplane mode та slow network.
8. Документація — опис архітектури, FLow-діаграми, інструкції для підтримки.

Що входить у реалізацію:

• Архітектурна документація (схеми, опис flow).
• Вихідний код: репозиторії, моніторинг мережі, черга операцій, sync worker.
• Тестування на реальних пристроях в умовах поганої мережі.
• Документація для розробників з підтримки та доробок.
• Код-рев'ю та навчання команди.

Реалізація офлайн-режиму з чергою операцій, WorkManager та UX для двох платформ: 3–5 тижнів залежно від складності доменної логіки. Вартість проєкту — від $10,000 до $25,000. Оцініть проєкт — напишіть нам, і ми спроєктуємо офлайн-режим під вашу специфіку. Для ознайомлення з концепцією дивіться offline-first, а для деталей WorkManager.

Зв'яжіться з нами, щоб обговорити ваш проєкт. Замовте аудит поточного застосунку — ми запропонуємо оптимальне рішення. Це і є offline-first розробка.