composable(): wat is het, NavHost en routering in Jetpack Compose

Wat is composable() in NavHost

composable() — is een extensiefunctie (extension function) van het NavHost-object. Kotlin DSL maakt het mogelijk om deze binnen een NavHost-blok aan te roepen voor het declaratief beschrijven van alle schermen van de applicatie. Elke aanroep creëert een entry in de navigatiegraaf, waarbij een tekstuele route aan een composable-functie wordt gekoppeld. Wanneer de gebruiker naar een bepaalde route navigeert, toont NavHost de bijbehorende composable als het huidige scherm, waarbij het vorige scherm wordt verborgen.

De Navigation Compose-bibliotheek werd in 2021 door Google geïntroduceerd als alternatief voor Fragment-gebaseerde navigatie voor Jetpack Compose. Het belangrijkste voordeel — volledige compatibiliteit met het Compose-paradigma: composable() werkt in dezelfde levenscyclus als andere Compose-componenten, zonder dat FragmentManager of transacties nodig zijn. Dit elimineert een klasse fouten die verband houden met het niet overeenkomen van de Fragment- en Compose-levenscyclus.

Elke composable() ontvangt een tekstuele route en een lambda-functie die een NavBackStackEntry-object krijgt en een Composable UI retourneert. Binnen de lambda kan NavController worden benaderd via de aanroep navController uit de scope, wat het mogelijk maakt om overgangen naar andere schermen te organiseren. Deze architectuur maakt navigatie expliciet en voorspelbaar.

@Composable
fun AppNavigation() {
    val navController = rememberNavController()
    
    NavHost(
        navController = navController,
        startDestination = "home"
    ) {
        composable("home") {
            HomeScreen(
                onNavigateToProfile = {
                    navController.navigate("profile")
                }
            )
        }
        composable("profile") {
            ProfileScreen(
                onBack = { navController.popBackStack() }
            )
        }
    }
}

Hoe werkt composable(): sleutels en parameters

Elke composable()-aanroep creëert in de interne graaf van NavHost een knooppunt met een unieke route-identificator. Wanneer NavController navigate() uitvoert, vergelijkt de bibliotheek de gevraagde route met alle geregistreerde composable-knooppunten en vindt de overeenkomende. Na een match wordt een NavBackStackEntry aangemaakt die op de navigatiestapel wordt geplaatst en de UI-compositie wordt gestart.

De interne implementatie van composable() maakt gebruik van het lazy-initialisatie-mechanisme: de compositie van het scherm vindt pas plaats op het moment van de eerste overgang naar deze route. Dit betekent dat schermen waar de gebruiker nooit naartoe is genavigeerd, geen geheugen innemen en geen code uitvoeren. Deze benadering verbetert de prestaties van applicaties met een groot aantal schermen aanzienlijk.

De parameter key in composable() maakt het mogelijk om het opnieuw aanmaken van het scherm te beheren. Standaard wordt composable niet opnieuw aangemaakt bij een herhaalde overgang naar dezelfde route — NavHost gebruikt de bestaande back stack entry. Als key echter wordt doorgegeven en verandert, maakt NavHost een nieuwe instantie van de composable-functie. Dit is nuttig voor schermen met dynamische gegevens waarbij de status bij heropenen geforceerd moet worden vernieuwd.

val NavGraphBuilder.Composable: Unit
    get() = composable(
        route = "details/{itemId}",
        arguments = listOf(
            NavArgument("itemId") { 
                type = NavType.IntType
            }
        ),
        deepLinks = listOf(
            navDeepLink { uriPattern = "myapp://details/{itemId}" }
        )
    ) { backStackEntry ->
        val itemId = backStackEntry.arguments?.getInt("itemId") ?: 0
        DetailsScreen(itemId = itemId)
    }

Argumenten doorgeven via composable()

composable() ondersteunt een flexibel argumentsysteem via de parameter arguments. Elk argument wordt beschreven door een NavArgument-object dat het type, de standaardwaarde en de verplichting definieert. Argumenten worden in de route doorgegeven als padparameters (via accolades) of queryparameters (via vraagteken).

Padparameters worden direct in het routesjabloon aangegeven: "profile/{userId}". Bij navigatie naar de route "profile/42" haalt NavHost automatisch de waarde 42 op en maakt deze beschikbaar via backStackEntry.arguments. Queryparameters worden na het vraagteken toegevoegd: "search?query={text}" en worden ook automatisch door de bibliotheek geparseerd.

Bij het ophalen van argumenten is het belangrijk om de verplichting van de parameter te controleren via NavType.isNullableAllowed en standaardwaarden te verstrekken via NavArgument defaultValue. Als een verplichte parameter ontbreekt, genereert Navigation Compose een IllegalArgumentException, wat onzichtbare bugs met onjuiste routes voorkomt.

Voor het doorgeven van complexe objecten wordt aanbevolen om NavType.ParcelableType of NavType.SerializableType te gebruiken. Google adviseert echter om de grootte van de doorgegeven gegevens te minimaliseren — het is beter om een identificatie door te geven en het object op ID binnen het scherm te laden. Dit voorkomt problemen met grote geserialiseerde gegevens en vereenvoudigt de verwerking van configuratiewijzigingen.

data class Profile(val id: Int, val name: String) : Parcelable

            // Navigeer met minimale gegevens
navController.navigate("profile/42")

            // Haal argumenten op het scherm op
composable(
    route = "profile/{userId}",
    arguments = listOf(
        NavArgument("userId") { type = NavType.IntType }
    )
) { backStackEntry ->
    val userId = backStackEntry.arguments?.getInt("userId") ?: 0
    ProfileDetailScreen(userId = userId)
}

Geneste navigatie met composable()

In echte applicaties is het vaak nodig om geneste navigatiegrafen te organiseren — bijvoorbeeld een aparte stapel schermen binnen een tabblad van BottomNavigation. composable() ondersteunt nesting via het mechanisme van geneste NavHosts: binnen een composable-scherm kan een eigen NavHost met een onafhankelijke routestapel worden gedeclareerd.

Elke geneste NavHost heeft zijn eigen NavController en back stack. Dit betekent dat navigatie binnen een tabblad geen invloed heeft op navigatie in andere tabbladen — de gebruiker kan vrij schakelen tussen tabbladen zonder de navigatiegeschiedenis binnen elk ervan te verliezen. Deze architectuur wordt Scoped Navigation genoemd en wordt door Google aanbevolen voor applicaties met complexe meerlaagse navigatie.

Bij het implementeren van geneste navigatie is het belangrijk om de status van NavController correct te beheren: elke geneste NavHost moet zijn eigen rememberNavController binnen de scope van de composable-functie bewaren. Volgens gegevens van Android Developer Summit 2024 gebruikt meer dan 40% van de Jetpack Compose-applicaties met drie of meer tabbladen de architectuur van geneste NavHosts voor isolatie van navigatie tussen modules.

// Hoofd-NavHost met tabbladen
composable("tabs") {
    MainTabsScreen { tab ->
        when (tab) {
            Tab.Home -> HomeNavGraph()
            Tab.Search -> SearchNavGraph()
        }
    }
}

// Geneste graaf in Home-tabblad
@Composable
fun HomeNavGraph() {
    val navController = rememberNavController()
    NavHost(
        navController = navController,
        startDestination = "home_feed"
    ) {
        composable("home_feed") { FeedScreen() }
        composable("home_detail/{postId}") { PostDetailScreen() }
    }
}

Vergelijking van composable() met Intent-navigatie

Vóór Jetpack Compose gebruikte de standaard navigatiemethode in Android Intent en FragmentManager. Intent — is een systeembericht dat een nieuwe Activity start, wat het opnieuw aanmaken van de hele View-boom inhoudt. In tegenstelling hiermee werkt composable() binnen één Activity en vervangt het eenvoudig een deel van de Compose-boom, wat aanzienlijk sneller en geheugenefficiënter is.

Belangrijkste verschillen tussen composable() en Intent-gebaseerde navigatie:

• Snelheid — composable() wisselt schermen in milliseconden zonder Activity opnieuw aan te maken, Intent vereist het opnieuw starten van de Activity.
• Animaties — in Navigation Compose worden overgangsanimaties declaratief ingesteld via AnimatedNavHost, zonder dat overridePendingTransition nodig is.
• Gedeelde status — composable() werkt in een gedeelde ViewModel-scope, wat het doorgeven van gegevens tussen schermen vereenvoudigt zonder Intent extras.

De overgang van Intent naar composable() — is niet alleen een API-wijziging, maar een verandering van architectuurparadigma. In plaats van expliciet aan te geven welke Activity moet worden geopend, beschrijft de ontwikkelaar declaratief alle mogelijke routes op één plek, wat de leesbaarheid van de code verbetert en het testen van navigatie vereenvoudigt. Volgens gegevens van Google I/O 2024 vermindert Jetpack Compose met Navigation Compose de hoeveelheid navigatiecode met 40–60% in vergelijking met FragmentManager.

Veelvoorkomende fouten met composable()

Een van de meest voorkomende fouten — het opnieuw aanmaken van NavController bij recompositie. Als NavController wordt gemaakt via rememberNavController() op het niveau van de bovenliggende composable die kan worden herbouwd bij statuswijziging, raakt de navigatie beschadigd — de navigatiegeschiedenis gaat verloren. De juiste oplossing is om NavController naar een stabiel composable-niveau te tillen, bijvoorbeeld naar het niveau van Activity of de root-composable van de applicatie.

Het tweede veelvoorkomende probleem — oneindige recompositie tijdens navigatie. Dit gebeurt wanneer de aanroep navController.navigate() direct in het lichaam van de composable-functie is geplaatst. Omdat navigatie de status van NavHost verandert, veroorzaakt dit een recompositie die opnieuw navigate() aanroept, waardoor een cyclus ontstaat. Alle navigatie-aanroepen moeten worden ingepakt in lambda-handlers (onClick, onButtonPressed) en niet worden uitgevoerd in de compositie.

De derde fout — onjuist beheer van de back stack bij gebruik van BottomNavigation. Eenvoudige navigatie via navigate() bij elke tabbladwisseling voegt een nieuwe entry toe aan de stapel, in plaats van terug te keren naar de bestaande. Voor BottomNavigation moet navController.navigate() met restoreState = true en launchSingleTop = true worden gebruikt, wat zorgt voor correct herstel van de status bij het schakelen tussen tabbladen.

fun NavController.navigateToTab(route: String) {
    navigate(route) {
        popUpTo(navController.graph.findStartDestination().id) {
            saveState = true
        }
        launchSingleTop = true
        restoreState = true
    }
}