https://kotlinlang.org logo
#compose
Title
# compose
d

Daniele B

11/03/2020, 1:53 AM
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.
Copy code
NavHost(navController, startDestination = "master") {
    .....
    composable("detail/{item}") { backStackEntry ->
        val detailName = backStackEntry.arguments?.getString("item")!!
        DetailView(appState = appState, detailName = detailName)
    }
}
i

Ian Lake

11/03/2020, 3:56 AM
What would you want to see?
d

Daniele B

11/03/2020, 3:57 AM
as a starting point, a way not to repeat the parameter name
i

Ian Lake

11/03/2020, 3:59 AM
What would your ideal API do this same thing look like?
d

Daniele B

11/03/2020, 4:02 AM
On the fly, I haven’t thought much, but this could be an improvement already:
Copy code
composable("detail/{item}") { backStackEntry ->
        val detailName = backStackEntry.lastArg
        DetailView(appState = appState, detailName = detailName)
    }
i

Ian Lake

11/03/2020, 4:11 AM
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
d

Daniele B

11/03/2020, 4:19 AM
I don’t fully understand the use cases when arguments would be non-String, as the
route
parameter is defined as a String.
i

Ian Lake

11/03/2020, 4:29 AM
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
So while you pass a string in, you are getting parsed typed arguments out in the
arguments
Bundle
d

Daniele B

11/03/2020, 4:39 AM
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.
i

Ian Lake

11/03/2020, 4:48 AM
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?)?
d

Daniele B

11/03/2020, 4:54 AM
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.
i

Ian Lake

11/03/2020, 5:19 AM
Thanks, that's really helpful context
👍 1
s

Stefano Rodriguez

11/03/2020, 9:31 AM
@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.