d

    Daniele B

    1 year ago
    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)
        }
    }
    i

    Ian Lake

    1 year ago
    What would you want to see?
    d

    Daniele B

    1 year ago
    as a starting point, a way not to repeat the parameter name
    i

    Ian Lake

    1 year ago
    What would your ideal API do this same thing look like?
    d

    Daniele B

    1 year ago
    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)
        }
    i

    Ian Lake

    1 year ago
    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

    1 year ago
    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

    1 year ago
    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

    1 year ago
    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

    1 year ago
    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

    1 year ago
    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

    1 year ago
    Thanks, that's really helpful context
    Stefano Rodriguez

    Stefano Rodriguez

    1 year ago
    @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.