Odpadává — co to je, typické příčiny a metody řešení

Co znamená „odpadává” v mobilních aplikacích?

Odpadává — uživatelský termín popisující situaci, kdy aplikace ztrácí spojení se serverem, přestává reagovat na akce nebo končí chybou. V technickém smyslu to může být: síťová chyba (timeout, DNS failure), ANR (blokování vlákna UI), crash (neošetřená výjimka) nebo race condition (soutěžní stav).

Pro uživatele všechny tyto scénáře vypadají stejně: aplikace přestane fungovat. Rozdíl pro vývojáře spočívá v přístupu k diagnostice a opravě. Síťové chyby se řeší mechanismy retry, ANR — přenesením operací mimo vlákno UI, crash — ošetřením výjimek.

Podle Crittercism (nyní Apteligent) průměrná mobilní aplikace ztrácí 1-2% uživatelů při každém pádu. Pro aplikaci s 1 milionem uživatelů to znamená 10-20 tisíc ztracených instalací na jednu chybu. Zvláště kritické je to pro aplikace ve finančním a lékařském sektoru.

Hlavní příčiny ztráty spojení

Nestabilní síť — mobilní zařízení neustále přepínají mezi Wi-Fi a mobilní sítí, vstupují do zón bez pokrytí (metro, výtah, sklep). Každé přepnutí způsobuje dočasnou ztrátu spojení, kterou musí aplikace správně zpracovat.

Časové limity — pokud server neodpoví ve stanoveném čase (obvykle 10-30 sekund), klient vyvolá SocketTimeoutException. Dlouhé časové limity bez zpětné vazby jsou uživatelem vnímány jako zamrznutí. Doporučuje se nastavit časový limit maximálně 15 sekund.

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

Soutěžní stav (race condition) — vzniká, když několik vláken současně čte a zapisuje stejná data bez synchronizace. Například načítání dat z mezipaměti ve vlákně UI paralelně s aktualizací mezipaměti ze sítě může vést k zobrazení zastaralých nebo nesprávných dat.

• Neošetřené výjimky v callback nebo coroutine vedou k pádu aplikace
• Tlak na paměť — systém zabíjí aplikaci při nedostatku paměti pro aplikaci v popředí
• Lifecycle race — async operace se dokončí po zničení Activity/Fragment
• Blokování UI — provádění sítě nebo databáze v hlavním vlákně způsobí ANR po 5 sekundách

Architektura pro odolné aplikace

Offline-first — architektonický vzor, kde lokální úložiště (Room, CoreData) je jediným zdrojem pravdy. Síť se používá pro synchronizaci dat na pozadí. Uživatel vždy vidí aktuální data z lokální mezipaměti, i při absenci sítě.

Repository pattern — jednotný vstupní bod pro data, který rozhoduje, zda data vzít ze sítě nebo z mezipaměti. Repozitář abstrahuje zdroj dat od ViewModel a UI. Při síťové chybě repozitář automaticky přepne na lokální zdroj.

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // vrátit mezipaměť při síťové chybě
            } else {
                Result.failure(e)
            }
        }
    }
}

Circuit Breaker — vzor ochrany serveru před lavinou požadavků při nedostupnosti. Po N po sobě jdoucích chybách se vypínač otevře a všechny požadavky okamžitě vracejí chybu bez pokusu o připojení. Po stanoveném časovém limitu přejde vypínač do polootevřeného stavu pro zkušební požadavek.

Jak zpracovávat síťové chyby?

Exponential backoff — standardní mechanismus retry. Po prvním neúspěchu počkejte 1 sekundu, po druhém — 2 sekundy, poté 4, 8, 16. Omezte maximální počet pokusů (obvykle 3-5), abyste nepřetěžovali server a baterii.

Zpětná vazba uživateli — při síťové chybě zobrazte srozumitelnou zprávu: „Žádné připojení”, „Server je dočasně nedostupný”, „Zkontrolujte internet”. Použijte Snackbar nebo Inline State View. Nikdy neukazujte uživateli technické chyby (HTTP 500, SocketException).

ConnectivityManager — Android API pro monitorování sítě. Umožněte aplikaci reagovat na změny: při ztrátě sítě zobrazte placeholder, při obnovení — automaticky aktualizujte data. V iOS použijte NWPathMonitor z frameworku Network.

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

Nástroje monitorování a logování

Crashlytics (Firebase) — standardní nástroj pro hlášení pádů pro mobilní aplikace. Sbírá stacktrace všech neošetřených výjimek, verzi OS, model zařízení a čas pádu. Umožňuje seskupovat chyby a přiřazovat odpovědné osoby za opravy.

Sentry — alternativa k Crashlytics s podporou monitorování výkonu. Umožňuje trasovat konkrétní transakce (např. „autorizace uživatele”) a vidět, ve kterém kroku došlo k chybě. Performance tracing pomáhá odlišit síťové časové limity od chyb v logice aplikace.

Timber — knihovna pro logování pro Android s automatickým přidáváním značek podle třídy. V debug sestavení logujte všechny síťové požadavky a odpovědi. V release sestavení — pouze chyby a varování přes Crashlytics.setCustomLog.

Podle Firebase Summit 2023 aplikace, které zavedly Crashlytics + Performance Monitoring, zkracují průměrnou dobu detekce a opravy kritických chyb ze 3 dnů na 4 hodiny. Doporučuje se nastavit výstrahy na každý pád s frekvencí vyšší než 0.1% aktivních uživatelů.