I started to use the new `navigation` . Congratula...

# compose

[Daniele B]

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

[Ian Lake]

What would you want to see?

[Daniele B]

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

[Ian Lake]

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

[Daniele B]

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

[Ian Lake]

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

[Daniele B]

I don’t fully understand the use cases when arguments would be non-String, as the route parameter is defined as a String.

[Ian Lake]

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

[Ian Lake]

So while you pass a string in, you are getting parsed typed arguments out in the arguments Bundle

[Daniele B]

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.

[Ian Lake]

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

[Daniele B]

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.

[Ian Lake]

Thanks, that's really helpful context

[Stefano Rodriguez]

@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.