Отпада — шта је то, типични узроци и методе решавања

Шта значи „отпада” у мобилним апликацијама?

Отпада — кориснички термин који описује ситуацију када апликација изгуби везу са сервером, престане да реагује на радње или се заврши грешком. У техничком смислу то може бити: мрежна грешка (timeout, DNS failure), ANR (блокирање UI нити), crash (необрађени изузетак) или race condition (трка услова).

За корисника сви ови сценарији изгледају исто: апликација престаје да ради. Разлика за програмера је у приступу дијагностици и поправци. Мрежне грешке се рјешавају retry механизмима, ANR — измјештањем операција из UI нити, crash — обрадом изузетака.

Према Crittercism (сада Apteligent), просјечна мобилна апликација губи 1-2% корисника при сваком паду. За апликацију са 1 милионом корисника то је 10-20 хиљада изгубљених инсталација по једној грешци. Посебно је критично за апликације у финансијском и медицинском сектору.

Главни узроци губитка везе

Нестабилна мрежа — мобилни уређаји стално прелазе између Wi-Fi и мобилне мреже, улазе у зоне без покривености (метро, лифт, подрум). Сваки прелазак изазива привремени губитак везе који апликација мора правилно да обради.

Тајмаути — ако сервер не одговори у одређеном времену (обично 10-30 секунди), клијент баца SocketTimeoutException. Дуги тајмаути без повратне информације доживљавају се као замрзавање. Препоручује се постављање тајмаута не дужег од 15 секунди.

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

Трка услова (race condition) — настаје када више нити истовремено чита и уписује исте податке без синхронизације. На примјер, учитавање података из кеша у UI нити паралелно са ажурирањем кеша из мреже може довести до приказа застарјелих или нетачних података.

• Необрађени изузеци у callback или coroutine доводе до пада апликације
• Притисак меморије — систем убија апликацију при недостатку меморије за апликацију у предњем плану
• Lifecycle race — async операција се завршава након што је Activity/Fragment уништен
• Блокирање UI — извршавање мреже или базе података на главној нити изазива ANR након 5 секунди

Архитектура за отпорне апликације

Offline-first — архитектонски образац у којем је локално складиште (Room, CoreData) једини извор истине. Мрежа се користи за синхронизацију података у позадини. Корисник увијек види ажурне податке из локалног кеша, чак и када нема мреже.

Repository pattern — јединствена улазна тачка за податке која одлучује да ли ће узети податке из мреже или из кеша. Репозиторијум апстрахује извор података од ViewModel-а и UI-ја. При мрежној грешци, репозиторијум аутоматски прелази на локални извор.

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) // врати кеш при мрежној грешци
            } else {
                Result.failure(e)
            }
        }
    }
}

Circuit Breaker — образац заштите сервера од поплаве захтјева када је недоступан. Након N узастопних грешака, прекидач се отвара и сви захтјеви одмах враћају грешку без покушаја повезивања. Након одређеног тајмаута, прекидач прелази у полуотворено стање за пробни захтјев.

Како обрађивати мрежне грешке?

Exponential backoff — стандардни механизам retry. Након првог неуспјеха сачекајте 1 секунду, након другог — 2 секунде, затим 4, 8, 16. Ограничите максималан број покушаја (обично 3-5) да не бисте преоптеретили сервер и батерију.

Повратна информација кориснику — при мрежној грешци прикажите разумљиву поруку: „Нема везе”, „Сервер је привремено недоступан”, „Провјерите интернет”. Користите Snackbar или Inline State View. Никада не приказујте кориснику техничке грешке (HTTP 500, SocketException).

ConnectivityManager — Android API за праћење мреже. Омогућите апликацији да реагује на промјене: при губитку мреже прикажите placeholder, при успостављању — аутоматски ажурирајте податке. У iOS-у користите NWPathMonitor из 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)
    }
}

Алати за праћење и евиденцију

Crashlytics (Firebase) — стандардни алат за извјештавање о падовима за мобилне апликације. Прикупља stacktrace свих необрађених изузетака, верзију ОС-а, модел уређаја и вријеме пада. Омогућава груписање грешака и додјељивање одговорних за поправке.

Sentry — алтернатива Crashlytics-у са подршком за праћење перформанси. Омогућава праћење одређених трансакција (нпр. „аутентификација корисника”) и увид у кораку на којем је дошло до грешке. Performance tracing помаже да се разликују мрежни тајмаути од грешака у логици апликације.

Timber — библиотека за евиденцију за Android са аутоматским додавањем ознака према класи. У debug верзији евидентирајте све мрежне захтјеве и одговоре. У release верзији — само грешке и упозорења путем Crashlytics.setCustomLog.

Према Firebase Summit 2023, апликације које су увеле Crashlytics + Performance Monitoring смањују просјечно вријеме откривања и поправљања критичних грешака са 3 дана на 4 сата. Препоручује се подешавање упозорења за сваки пад са учесталошћу већом од 0.1% активних корисника.