Valt weg — wat is het, typische oorzaken en oplossingsmethoden

Wat betekent „valt weg” in mobiele apps?

Valt weg — een gebruikersterm die de situatie beschrijft waarin een app de verbinding met de server verliest, niet meer reageert op acties of met een fout eindigt. In technische zin kan dit zijn: netwerkfout (timeout, DNS failure), ANR (blokkering van de UI-thread), crash (onverwerkte uitzondering) of race condition (race-omstandigheid).

Voor de gebruiker zien al deze scenario's er hetzelfde uit: de app stopt met werken. Het verschil voor de ontwikkelaar zit in de benadering van diagnose en reparatie. Netwerkfouten worden opgelost met retry-mechanismen, ANR door operaties buiten de UI-thread uit te voeren, crash door exception handling.

Volgens Crittercism (nu Apteligent) verliest een gemiddelde mobiele app 1-2% van zijn gebruikers bij elke crash. Voor een app met 1 miljoen gebruikers betekent dit 10-20 duizend verloren installaties per bug. Dit is vooral kritiek voor apps in de financiële en medische sector.

Belangrijkste oorzaken van verbindingsverlies

Onstabiel netwerk — mobiele apparaten schakelen constant tussen Wi-Fi en mobiel netwerk, komen in gebieden zonder dekking (metro, lift, kelder). Elke schakeling veroorzaakt tijdelijk verbindingsverlies dat de app correct moet afhandelen.

Time-outs — als de server niet reageert binnen de ingestelde tijd (meestal 10-30 seconden), gooit de client een SocketTimeoutException. Lange time-outs zonder terugkoppeling worden door de gebruiker als vastlopen ervaren. Het wordt aanbevolen om de time-out op maximaal 15 seconden in te stellen.

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

Race condition — ontstaat wanneer meerdere threads tegelijkertijd dezelfde gegevens lezen en schrijven zonder synchronisatie. Bijvoorbeeld het laden van gegevens uit de cache in de UI-thread parallel met het bijwerken van de cache vanuit het netwerk kan leiden tot het tonen van verouderde of onjuiste gegevens.

• Onverwerkte uitzonderingen in callback of coroutine leiden tot een crash van de app
• Memory pressure — het systeem doodt de app bij gebrek aan geheugen voor de voorgrond-app
• Lifecycle race — async operatie wordt voltooid nadat Activity/Fragment is vernietigd
• UI-blokkering — uitvoeren van netwerk of database op de hoofdthread veroorzaakt ANR na 5 seconden

Architectuur voor fouttolerante apps

Offline-first — architectuurpatroon waarbij lokale opslag (Room, CoreData) de enige bron van waarheid is. Het netwerk wordt gebruikt voor het synchroniseren van gegevens op de achtergrond. De gebruiker ziet altijd actuele gegevens uit de lokale cache, zelfs zonder netwerk.

Repository pattern — enkel toegangspunt voor gegevens dat beslist of gegevens uit het netwerk of de cache worden gehaald. De repository abstraheert de gegevensbron van de ViewModel en UI. Bij een netwerkfout schakelt de repository automatisch over naar de lokale bron.

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) // geef cache terug bij netwerkfout
            } else {
                Result.failure(e)
            }
        }
    }
}

Circuit Breaker — patroon ter bescherming van de server tegen een lawine van verzoeken bij onbeschikbaarheid. Na N opeenvolgende fouten opent de schakelaar en alle verzoeken retourneren onmiddellijk een fout zonder verbindingspoging. Na een bepaalde time-out gaat de schakelaar naar halfopen toestand voor een proefverzoek.

Hoe netwerkfouten te behandelen?

Exponential backoff — standaard retry-mechanisme. Wacht na de eerste mislukking 1 seconde, na de tweede 2 seconden, daarna 4, 8, 16. Beperk het maximale aantal pogingen (meestal 3-5) om de server en batterij niet te overbelasten.

Gebruikersfeedback — toon bij een netwerkfout een begrijpelijk bericht: „Geen verbinding”, „Server tijdelijk niet beschikbaar”, „Controleer internet”. Gebruik Snackbar of Inline State View. Nooit technische fouten (HTTP 500, SocketException) aan de gebruiker tonen.

ConnectivityManager — Android API voor netwerkbewaking. Laat de app reageren op wijzigingen: bij verlies van netwerk een placeholder tonen, bij herstel automatisch gegevens bijwerken. Gebruik in iOS NWPathMonitor uit het Network framework.

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)
    }
}

Monitoring- en loggingtools

Crashlytics (Firebase) — standaard crash-rapportagetool voor mobiele apps. Verzamelt stacktraces van alle onverwerkte uitzonderingen, OS-versie, apparaatmodel en crashtijd. Maakt het groeperen van fouten en toewijzen van verantwoordelijken voor fixes mogelijk.

Sentry — alternatief voor Crashlytics met ondersteuning voor performance monitoring. Maakt het traceren van specifieke transacties (bijv. „gebruikersauthenticatie”) mogelijk en inzicht in welke stap de fout optrad. Performance tracing helpt netwerk time-outs te onderscheiden van bugs in de app-logica.

Timber — loggingbibliotheek voor Android met automatische toevoeging van tags per klasse. Log in debug-builds alle netwerkverzoeken en -antwoorden. In release-builds alleen fouten en waarschuwingen via Crashlytics.setCustomLog.

Volgens Firebase Summit 2023 verkorten apps die Crashlytics + Performance Monitoring hebben geïmplementeerd de gemiddelde tijd voor detectie en reparatie van kritieke bugs van 3 dagen naar 4 uur. Het wordt aanbevolen om alert in te stellen op elke crash met een frequentie van meer dan 0,1% van de actieve gebruikers.