I started to use the new

navigation

. Congratulations, it’s great! It’s much neater than the one in SwiftUI. I also like the fact that it uses URIs, which makes it very adaptable to the Web too. But maybe there is still some room for improvement. For example, I find rather verbose the way to collect string arguments. Having to repeat the parameter name twice doesn’t feel optimum.

NavHost(navController, startDestination = "master") {
    .....
    composable("detail/{item}") { backStackEntry ->
        val detailName = backStackEntry.arguments?.getString("item")!!
        DetailView(appState = appState, detailName = detailName)
    }
}

What would you want to see?

as a starting point, a way not to repeat the parameter name

What would your ideal API do this same thing look like?

On the fly, I haven’t thought much, but this could be an improvement already:

composable("detail/{item}") { backStackEntry ->
        val detailName = backStackEntry.lastArg
        DetailView(appState = appState, detailName = detailName)
    }

So how you handle different types of arguments? They aren't all strings so the type of

lastArg

would not be the same from composable to composable. I'm not sure if trading actual names for positional requirements actually works well when you allow multiple arguments and optional arguments

I don’t fully understand the use cases when arguments would be non-String, as the

route

parameter is defined as a String.

We talk about this in the docs (https://developer.android.com/jetpack/compose/navigation#nav-with-args), but you can use ints, enums, etc. that offer more restrictions than any string

OK, I see. So, in such case,

lastArg

could be casted to a type with

as

(e.g.

as String

). Considering that most use cases would take into consideration just the last argument, it would be useful not having to repeat the parameter name twice, it would also prevent mistyping bugs.

So for your use cases, you'd prefer heavily focusing on the single argument code path? What would you do with multiple arguments (do the non-last parameters use the current syntax, completely different from the last arg)? What about optional arguments, which must be after required arguments (would they be considered the last arg?)?

I would consider the

lastArg

as a simplified API, which would be used in common use cases, where you typically have a master/detail architecture, and the detail has an argument associated with it. For more complex situations, there would still be the freedom to use named arguments.

Thanks, that's really helpful context

@Ian Lake did you have the chance to take a look at the new evolution of Flutter’s Navigation component? I think that the new declarative

Page

-based approach is way better and more coherent with a component-based framework like Flutter or Jetpack Compose and they made a huge effort to make both approaches interoperable.