NetworkCallback: wat is het, toepassing en netwerkbeheer in Android

Wat is NetworkCallback?

NetworkCallback — is een abstracte klasse uit het android.net-pakket, dat deel uitmaakt van de Android SDK. Het is bedoeld voor het ontvangen van meldingen over wijzigingen in de netwerkverbindingsstatus via de systeemservice ConnectivityManager.

Vóór de komst van NetworkCallback gebruikten ontwikkelaars BroadcastReceiver-uitzendontvangers voor netwerkmonitoring. Deze aanpak vereiste constante registratie in het manifest, werkte met vertraging en gaf geen gedetailleerde informatie over verbindingseigenschappen. Android 5.0 (API 21) introduceerde NetworkCallback als een flexibeler en efficiënter alternatief.

De callback werkt asynchroon: de app abonneert zich op gebeurtenissen via ConnectivityManager en het systeem roept callback-methoden aan bij wijziging van de netwerkstatus. Dit elimineert de noodzaak van periodieke polling van de netwerkstatus, wat batterij- en processorresources bespaart.

Hoe callback werkt in Android

ConnectivityManager beheert alle netwerkinterfaces van het apparaat — Wi-Fi, mobiele data, Ethernet, VPN. Bij wijziging van een van deze interfaces maakt het systeem een Network-object aan en geeft dit door aan de juiste methode van de geregistreerde callback. Elk Network heeft een unieke identificatie die verandert bij herverbinding.

De callback is niet gebonden aan een specifiek netwerktype — het kan alle beschikbare interfaces tegelijk volgen. Voor het filteren van verbindingstypen wordt de klasse NetworkRequest gebruikt, waarin de vereiste transportprotocollen (Wi-Fi, mobiele data, Ethernet) en netwerkmogelijkheden worden gespecificeerd.

Hoe NetworkCallback registreren in de app

Registratie van NetworkCallback gebeurt via de methode ConnectivityManager.registerNetworkCallback. De eerste parameter is NetworkRequest.Builder die de netwerkvereisten beschrijft, de tweede — een instantie van de callback. Voor werking is de machtiging ACCESS_NETWORK_STATE in het manifest vereist.

class NetworkMonitor(private val context: Context) {

    private val connectivityManager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE)
            as ConnectivityManager

    private val callback =
        object : ConnectivityManager.NetworkCallback() {

        override fun onAvailable(network: Network) {
            Log.d("Network", "Beschikbaar: ${network}")
        }

        override fun onLost(network: Network) {
            Log.d("Network", "Verloren: ${network}")
        }
    }

    fun register() {
        connectivityManager.registerNetworkCallback(
            NetworkRequest.Builder().build(), callback
        )
    }

    fun unregister() {
        connectivityManager.unregisterNetworkCallback(callback)
    }
}

Registratie in Activity en Fragment

Het wordt aanbevolen om NetworkCallback te registreren wanneer de app op de voorgrond is en te annuleren bij overgang naar de achtergrond. In Activity is het handig om onStart en onStop te gebruiken voor het beheren van de callback lifecycle. In Fragment — onResume en onPause.

Voor vereenvoudiging van registratiebeheer kunnen Lifecycle-aware componenten worden gebruikt. De bibliotheek AndroidX Lifecycle maakt het mogelijk om een eigen LifecycleObserver te maken die automatisch de callback registreert en annuleert bij wijziging van de levenscyclusstatus.

Registratie in een service

Voor achtergrondtaken vindt registratie plaats in Service of WorkManager. Het is belangrijk rekening te houden dat in Android 8+ achtergrondservices beperkingen hebben voor het opstarten. WorkManager met NetworkType — een betrouwbaardere manier om taken uit te voeren bij een bepaalde netwerkstatus, omdat het geïntegreerd is met de compatibiliteits-API en de Doze-modus in acht neemt.

Belangrijkste methoden van NetworkCallback

NetworkCallback biedt een reeks methoden die worden aangeroepen bij wijziging van de netwerkstatus. Niet alle methoden hoeven te worden overschreven — het is voldoende om alleen die te implementeren die nodig zijn voor de specifieke taak van de app. onAvailable en onLost zijn minimaal vereist voor basismonitoring van de verbinding.

Methode onCapabilitiesChanged

Deze methode is de sleutel tot het verkrijgen van gedetailleerde netwerkinformatie. De parameter NetworkCapabilities bevat vlaggen: NET_CAPABILITY_INTERNET — toegang tot internet, NET_CAPABILITY_NOT_METERED — onbeperkte verbinding, NET_CAPABILITY_NOT_ROAMING — geen roaming. Ook kunnen signaalvertraging en bandbreedte worden achterhaald.

Captive portals — een apart geval: bij verbinding met een openbaar Wi-Fi-netwerk via een portal geeft de methode onCapabilitiesChanged niet meteen INTERNET aan. Eerst is het netwerk beschikbaar, maar zonder internet — autorisatie via de browser is vereist. De ontwikkelaar moet deze vertraging meenemen in de app-logica.

Methode onBlockedStatusChanged

Wordt aangeroepen wanneer het systeem netwerkverkeer blokkeert voor de app — bijvoorbeeld bij inschakelen van de gegevensbesparingsmodus of beperking van achtergrondgegevens. onBlockedStatusChanged stelt de app in staat te weten dat zijn netwerkverzoeken tijdelijk verboden zijn en over te schakelen naar lokale verwerking.

Voorbeelden van NetworkCallback implementatie

Laten we de praktische implementatie van NetworkCallback bekijken voor het volgen van internettoegang en het afhandelen van captive portals. In het onderstaande voorbeeld wordt controle van NET_CAPABILITY_INTERNET en validatie van de verbinding via een HTTP-verzoek naar de Google-server getoond.

val networkCallback = object : ConnectivityManager.NetworkCallback() {

    override fun onCapabilitiesChanged(
        network: Network,
        caps: NetworkCapabilities
    ) {
        val hasInternet = caps.hasCapability(
            NetworkCapabilities.NET_CAPABILITY_INTERNET
        )
        val isMetered = caps.hasCapability(
            NetworkCapabilities.NET_CAPABILITY_NOT_METERED
        ).not()

        when {
            hasInternet && isMetered ->
                Log.d("Network", "Mobiele data verbonden")
            hasInternet ->
                Log.d("Network", "Wi-Fi verbonden")
            else ->
                Log.d("Network", "Geen internettoegang")
        }
    }

    override fun onLost(network: Network) {
        Log.d("Network", "Verbinding verloren: ${network}")
        // Stop netwerkverzoeken
    }
}

Afhandeling van captive portals

Bij verbinding met een openbaar netwerk met autorisatie (café, luchthaven) meldt het systeem eerst onAvailable, maar onCapabilitiesChanged toont mogelijk geen INTERNET. In dergelijke gevallen is extra controle via een HTTP-verzoek naar een stabiel endpoint, bijvoorbeeld https://www.google.com/generate_204, vereist.

Als het verzoek code 204 retourneert — is er internet. Als doorverwijzing (301, 302, 307) — is autorisatie via browser vereist. In dit geval kan WebView of Intent naar de doorverwijs-URL worden geopend voor authenticatie op de portal.

fun Context.validateInternet(network: Network) {
    CoroutineScope(Dispatchers.IO).launch {
        try {
            val url = URL("https://www.google.com/generate_204")
            val connection =
                network.openConnection(url) as HttpURLConnection
            connection.instanceFollowRedirects = false
            connection.connect()
            when (connection.responseCode) {
                HttpURLConnection.HTTP_NO_CONTENT ->
                    Log.d("Network", "Internet is beschikbaar")
                in HttpURLConnection.HTTP_MOVED_PERM
                        ..HttpURLConnection.HTTP_TEMP_REDIRECT ->
                    Log.d("Network", "Captive portal gedetecteerd")
            }
            connection.disconnect()
        } catch (e: Exception) {
            Log.e("Network", "Validatie mislukt: ${e.message}")
        }
    }
}

Verschillen met andere netwerkmonitoring methoden

Vóór NetworkCallback was de belangrijkste methode voor netwerkmonitoring BroadcastReceiver met het filter android.net.conn.CONNECTIVITY_CHANGE. Deze aanpak had aanzienlijke nadelen: vertraging van enkele seconden, gebrek aan informatie over het interfacetype, verhoogd energieverbruik door constant ontwaken van het apparaat.

Modern alternatief — LiveData of StateFlow in combinatie met NetworkCallback. Het patroon bestaat uit het inpakken van de callback in een reactieve stroom die automatisch de UI op de hoogte stelt van statuswijzigingen. Bijvoorbeeld MutableStateFlow met type NetworkStatus wordt bijgewerkt binnen de callback-methoden en ViewCollector abonneert zich op wijzigingen.

Werken met de achtergrondmodus

Vanaf Android 10 is het niveau van achtergrondbeperkingen aangescherpt en kan NetworkCallback mogelijk niet worden aangeroepen wanneer de app op de achtergrond is. Voor kritisch belangrijke taken — bijvoorbeeld gegevens laden bij verschijnen van netwerk — gebruik WorkManager met beperking NetworkType.CONNECTED. WorkManager garandeert uitvoering van de taak bij vervulling van netwerkvoorwaarden.

In Android 12+ is er een beperking gekomen voor manifestregistratie van BroadcastReceiver voor CONNECTIVITY_ACTION. Ontwikkelaars zijn verplicht te migreren naar NetworkCallback of WorkManager te gebruiken. Google Play-beleid vereist sinds augustus 2022 verwijdering van manifestregistratie voor deze actie.