composable(): шта је то, NavHost и рутирање у Jetpack Compose-у

Шта је composable() у NavHost-у

composable() — је функција-проширење (extension function) објекта NavHost. Kotlin DSL омогућава да се позива унутар NavHost блока за декларативно описивање свих екрана апликације. Сваки позив ствара унос у навигационом графу, повезујући текстуалну путању са composable функцијом. Када корисник пређе на одређену путању, NavHost приказује одговарајући composable као тренутни екран, сакривајући претходни.

Библиотека Navigation Compose представљена је од стране Google-а 2021. године као алтернатива Fragment-базираној навигацији за Jetpack Compose. Главна предност — потпуна компатибилност са Compose парадигмом: composable() ради у истом животном циклусу као и остале Compose компоненте, без потребе за FragmentManager-ом или трансакцијама. Ово елиминише класу грешака повезаних са неусаглашеношћу животног циклуса Fragment-а и Compose-а.

Сваки composable() прима текстуалну путању (route) и ламбда функцију која добија NavBackStackEntry објекат и враћа Composable UI. Унутар ламбде може се приступити NavController-у кроз poziv navController из опсега, што омогућава организовање прелазака на друге екране. Оваква архитектура чини навигацију експлицитном и предвидивом.

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

Како ради composable(): кључеви и параметри

Сваки позив composable() ствара у унутрашњем графу NavHost-а чвор са јединственим идентификатором путање. Када NavController изврши navigate(), библиотека упоређује захтевану путању са свим регистрованим composable чворовима и проналази одговарајући. Након поклапања, ствара се NavBackStackEntry који се поставља на стек навигације и покреће се композиција UI-ја.

Унутрашња имплементација composable() користи механизам лење иницијализације: композиција екрана се дешава тек у тренутку првог преласка на ову путању. То значи да екрани на које корисник никада није прешао не заузимају меморију и не извршавају никакав код. Овакав приступ значајно побољшава перформансе апликација са великим бројем екрана.

Параметар key у composable() омогућава управљање поновним стварањем екрана. Подразумевано, composable се не ствара поново при поновном преласку на исту путању — NavHost користи постојећи унос на стеку. Међутим, ако се key проследи и промени, NavHost ствара нову инстанцу composable функције. Ово је корисно за екране са динамичким подацима где је потребно присилно ажурирање стања при поновном отварању.

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

Прослеђивање аргумената кроз composable()

composable() подржава флексибилан систем аргумената кроз параметар arguments. Сваки аргумент се описује NavArgument објектом који дефинише тип, подразумевану вредност и обавезност. Аргументи се прослеђују у путањи као path параметри (кроз витичасте заграде) или query параметри (кроз упитник).

Path параметри се наводе директно у шаблону путање: "profile/{userId}". При преласку на путању "profile/42", NavHost аутоматски издваја вредност 42 и чини је доступном кроз backStackEntry.arguments. Query параметри се додају након упитника: "search?query={text}" и такође се аутоматски парсирају од стране библиотеке.

При издвајању аргумената важно је проверити обавезност параметра кроз NavType.isNullableAllowed и обезбедити подразумеване вредности кроз NavArgument defaultValue. Ако обавезни параметар недостаје, Navigation Compose генерише IllegalArgumentException изузетак, што спречава неприметне грешке са нетачним путањама.

За прослеђивање сложених објеката препоручује се коришћење NavType.ParcelableType или NavType.SerializableType. Ипак, Google саветује да се минимизира величина прослеђених података — боље је проследити идентификатор и учитати објекат по идентификатору унутар екрана. Ово спречава проблеме са великим серијализованим подацима и поједностављује обраду промена конфигурације.

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

            // Крећи се са минималним подацима
navController.navigate("profile/42")

            // Преузми аргументе на екрану
composable(
    route = "profile/{userId}",
    arguments = listOf(
        NavArgument("userId") { type = NavType.IntType }
    )
) { backStackEntry ->
    val userId = backStackEntry.arguments?.getInt("userId") ?: 0
    ProfileDetailScreen(userId = userId)
}

Угнежђена навигација са composable()

У стварним апликацијама често је потребно организовати угнежђене графове навигације — на пример, одвојени стек екрана унутар картице BottomNavigation. composable() подржава угнежђеност кроз механизам угнежђених NavHost-ова: унутар composable екрана може се декларисати сопствени NavHost са независним стеком путања.

Сваки угнежђени NavHost има сопствени NavController и back stack. То значи да навигација унутар картице не утиче на навигацију у другим картицама — корисник може слободно да се пребацује између картица без губљења историје прелазака унутар сваке од њих. Оваква архитектура се назива Scoped Navigation и препоручује је Google за апликације са сложеном вишеслојном навигацијом.

При имплементацији угнежђене навигације важно је правилно управљати стањем NavController-а: сваки угнежђени NavHost треба да чува свој rememberNavController унутар опсега composable функције. Према подацима Android Developer Summit 2024, више од 40% апликација на Jetpack Compose-у са три и више картица користи архитектуру угнежђених NavHost-ова за изолацију навигације између модула.

// Главни NavHost са картицама
composable("tabs") {
    MainTabsScreen { tab ->
        when (tab) {
            Tab.Home -> HomeNavGraph()
            Tab.Search -> SearchNavGraph()
        }
    }
}

// Угнежђени граф у Home картици
@Composable
fun HomeNavGraph() {
    val navController = rememberNavController()
    NavHost(
        navController = navController,
        startDestination = "home_feed"
    ) {
        composable("home_feed") { FeedScreen() }
        composable("home_detail/{postId}") { PostDetailScreen() }
    }
}

Поређење composable() са Intent навигацијом

Пре Jetpack Compose-а стандардни начин навигације у Android-у користио је Intent и FragmentManager. Intent — системска порука која покреће нову Activity, што подразумева поновно стварање целог View стабла. За разлику од овога, composable() ради унутар једне Activity и једноставно замењује део Compose стабла, што је значајно брже и ефикасније по меморији.

Главне разлике између composable() и Intent-базиране навигације:

• Брзина — composable() пребацује екране за милисекунде без поновног стварања Activity, Intent захтева поновно покретање Activity.
• Анимације — у Navigation Compose-у анимације прелазака се задају декларативно кроз AnimatedNavHost, без потребе за overridePendingTransition.
• Заједничко стање — composable() ради у заједничком ViewModel опсегу, што поједностављује пренос података између екрана без Intent extras-а.

Прелазак са Intent на composable() — није само промена API-ја, већ промена архитектонске парадигме. Уместо експлицитног навођења која Activity треба да се отвори, програмер декларативно описује све могуће путање на једном месту, што побољшава читљивост кода и поједностављује тестирање навигације. Према подацима Google I/O 2024, Jetpack Compose са Navigation Compose-ом смањује количину кода за навигацију за 40–60% у поређењу са FragmentManager-ом.

Типичне грешке са composable()

Једна од најчешћих грешака — поновно стварање NavController-а при рекомпозицији. Ако се NavController креира кроз rememberNavController() на нивоу родитељског composable-а који се може поново створити при промени стања, навигација се ломи — историја прелазака се губи. Правилно решење је подизање NavController-а на ниво стабилног composable-а, на пример, на ниво Activity или коренског composable-а апликације.

Други чест проблем — бесконачна рекомпозиција при навигацији. Ово се дешава када се poziv navController.navigate() налази директно у телу composable функције. Пошто навигација мења стање NavHost-а, ово покреће рекомпозицију која поново позива navigate(), стварајући циклус. Сви позиви навигације морају бити умотани у ламбда-руковаоце (onClick, onButtonPressed), а не извршавани у композицији.

Трећа грешка — неправилно управљање back stack-ом при коришћењу BottomNavigation. Једноставна навигација кроз navigate() при сваком пребацивању картице додаје нови унос у стек, уместо да се враћа постојећем. За BottomNavigation треба користити navController.navigate() са restoreState = true и launchSingleTop = true, што обезбеђује правилно враћање стања при пребацивању картица.

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