android - Navigation in multi-module Compose project - Stack Overflow

admin管理员组

文章数量:1300189

I have a multi-module compose project where I am still trying to define how the navigation should be done. As far as I know, the following key concepts need to be taken into account (correct me if I am wrong):

• Navigation between top-level destinations must be managed in the MainNavGraph.

• Navigation between screens within a feature (module) should be
  managed by the feature itself.

• As described in android developers site and NowInAndroid code,
  whenever a screen needs to navigate to another, instead of using
  navController inside the Screen itself and calling navigate(...)
  method, it is better to use callbacks in order to delegate the
  navigation to the MainNavGraph. From my point of view, instead of
  using basic callbacks we can use sealed class/interface in order to
  avoid having hundreds of callbacks, as I show you in the picture.

The problem is that I feel that then every Screen is accessible from everywhere, and that's against modularising approach. In consequence, I don't know how to do/solve the inner feature navigation.

My theoretical idea is: MainApp/MainAppGraph needs to have an AppNavigator. Each feature should have an FeatureXNavigator. AppNavigator must be able to delegate the features internal navigation to each own feature navigator, which would be hiden from other features. A problem I see is that each feature navigator must have an instance of a navController, to do navigation, but then, we have to pass it from the MainNavGraph/AppNavigator, what I think is not a good approach because then we are binding the module to use NavController and would be harder to reuse the module in other projects like multiplatform, etc.

Any advice/example on how to solve it?

In my current code, I think only navigateToSettings should be accessible for everyone, the others (to map, to detail, etc) should be managed and visible only within the feature...

HomeNavigation.kt:

fun NavController.navigateToMap() {
    navigate(route = NavigationRoute.Map)
}

fun NavController.navigateToItemDetail(id: Int = Int.negative()) {
    navigate(NavigationRoute.ItemDetail(id))
}
fun NavGraphBuilder.homeNavGraph(
    onAction: (HomeNavActions) -> Unit
) {
    navigation<NavigationGraphs.HomeGraph>(startDestination = NavigationRoute.Home) {
        composable<NavigationRoute.Home> {
            HomeSection(
                onItemClick = { id ->
                    onAction(HomeNavActions.ItemDetail(id))
                }
            )
        }
        ....
    }
}

MainNavGraph.kt:

@Composable
fun MainNavGraph(
    navController: NavHostController = rememberNavController()
) {
    Box(
        modifier = Modifier.fillMaxSize()
    ) {
        NavHost(navController = navController, startDestination = NavigationGraphs.HomeGraph) {
            homeNavGraph { action -> navController.navigateTo(action) }
            settingsGraph()
        }
    }
}
private fun NavHostController.navigateTo(action: HomeNavActions) {
    when (action) {
        HomeNavActions.Back -> popBackStack()
        HomeNavActions.Map -> navigateToMap()        
        HomeNavActions.Settings -> navigateToSettings()
        is HomeNavActions.ToItemDetail -> navigateToItemDetail(action.id)
    }
}

I have a multi-module compose project where I am still trying to define how the navigation should be done. As far as I know, the following key concepts need to be taken into account (correct me if I am wrong):

• Navigation between top-level destinations must be managed in the MainNavGraph.

• Navigation between screens within a feature (module) should be
  managed by the feature itself.

• As described in android developers site and NowInAndroid code,
  whenever a screen needs to navigate to another, instead of using
  navController inside the Screen itself and calling navigate(...)
  method, it is better to use callbacks in order to delegate the
  navigation to the MainNavGraph. From my point of view, instead of
  using basic callbacks we can use sealed class/interface in order to
  avoid having hundreds of callbacks, as I show you in the picture.

The problem is that I feel that then every Screen is accessible from everywhere, and that's against modularising approach. In consequence, I don't know how to do/solve the inner feature navigation.

My theoretical idea is: MainApp/MainAppGraph needs to have an AppNavigator. Each feature should have an FeatureXNavigator. AppNavigator must be able to delegate the features internal navigation to each own feature navigator, which would be hiden from other features. A problem I see is that each feature navigator must have an instance of a navController, to do navigation, but then, we have to pass it from the MainNavGraph/AppNavigator, what I think is not a good approach because then we are binding the module to use NavController and would be harder to reuse the module in other projects like multiplatform, etc.

Any advice/example on how to solve it?

In my current code, I think only navigateToSettings should be accessible for everyone, the others (to map, to detail, etc) should be managed and visible only within the feature...

HomeNavigation.kt:

fun NavController.navigateToMap() {
    navigate(route = NavigationRoute.Map)
}

fun NavController.navigateToItemDetail(id: Int = Int.negative()) {
    navigate(NavigationRoute.ItemDetail(id))
}
fun NavGraphBuilder.homeNavGraph(
    onAction: (HomeNavActions) -> Unit
) {
    navigation<NavigationGraphs.HomeGraph>(startDestination = NavigationRoute.Home) {
        composable<NavigationRoute.Home> {
            HomeSection(
                onItemClick = { id ->
                    onAction(HomeNavActions.ItemDetail(id))
                }
            )
        }
        ....
    }
}

MainNavGraph.kt:

@Composable
fun MainNavGraph(
    navController: NavHostController = rememberNavController()
) {
    Box(
        modifier = Modifier.fillMaxSize()
    ) {
        NavHost(navController = navController, startDestination = NavigationGraphs.HomeGraph) {
            homeNavGraph { action -> navController.navigateTo(action) }
            settingsGraph()
        }
    }
}
private fun NavHostController.navigateTo(action: HomeNavActions) {
    when (action) {
        HomeNavActions.Back -> popBackStack()
        HomeNavActions.Map -> navigateToMap()        
        HomeNavActions.Settings -> navigateToSettings()
        is HomeNavActions.ToItemDetail -> navigateToItemDetail(action.id)
    }
}

• android
• android-jetpack-compose
• android-jetpack-navigation
• multi-module
• android-multi-module

Share Follow asked Feb 12 at 8:37 alGhul7alGhul7 13311 silver badge1212 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

Wow that was a lot! :D

OK, let's get this over with. Firstly, as you can put composables inside Navigation, you can also put navigations nested inside navigations (navHosts).

So you would have a top-level navigation, and each nested navigation objects would have their own navigation along with their own respective navControllers.

Take a look in the code below:

NavHost(
  navController = topLevelNavController, 
  startDestination = NavTarget.SplashScreen.label
) {

    composable("HomeScreen") {
        HomeScreen()
    }

    composable("FillUserDataScreen") {
        FillUserDataScreen()
    }

    navigation(
            startDestination = "feature1",
            route = "product"
        ) {
            navigation(
                startDestination = "main",
                route = "feature1"
            ) {
                composable(route = "main") {
                    MainScreen()
                }
            }
        }

I also highly recommend using CompositionLocalProvider. Using this feature, you can elevate your navController (or variable etc.) which makes it accessible like a variable call throughout that specific module.

In order to avoid navigating to another module's composable (or navigation), create directories for each feature and use access modifiers (like private, protected, etc.)

本文标签： androidNavigation in multimodule Compose projectStack Overflow