```navController.navigate("${ROUTE}?arg=${true}")`...

# compose

[mgrazianodecastro]

navController.navigate("${ROUTE}?arg=${true}")

is raising:

Wrong argument type for 'arg' in argument bundle. boolean expected.

what is the proper way of passing a boolean than?

[Stylianos Gakis]

Isn’t the string supposed to actually have the “{}” inside it? By adding the dollar sign here, you’re basically making the string be
“someroute?arg=true”
instead of
“someroute?arg={true}”

[mgrazianodecastro]

it doesn't work either, same error

[Stylianos Gakis]

How are you specifying your composable() in your nav graph?

[mgrazianodecastro]

composable(route = ROUTE,
    arguments = listOf(
        navArgument("arg"){
            type = NavType.BoolType
            defaultValue = false
        }
    )
){...}

[mgrazianodecastro]

and ROUTE = someRoute?arg={arg}

[yschimke]

You are appending arg twice then?

[mgrazianodecastro]

am I that tired? Lol, lemme check it

[yschimke]

ROUTE already includes it with {arg} then appending with true

[mgrazianodecastro]

yep, you're right. I'm gonna deconstruct the object so I can reference it better latter on

[mgrazianodecastro]

thanks

[mgrazianodecastro]

maybe I need some coffee too

[Stylianos Gakis]

Or some sleep 😅

[jw]

Or a type safe navigation framework

[Stylianos Gakis]

Which one would you suggest, especially with an equivalent amount of documentation + codelabs + examples etc which aids people to get onboarded into it as the androidx version does?

[jw]

Well that'd be none, or course, since those requirements are ridiculously high.

Don't you think a navigation framework which eliminated the entire class or problem above would require slightly less documentation? And that each class of problem eliminated by a better design would compound on that fact?

[jw]

Which needs more documentation, a bowling alley with gutters or a bowling alley with bumpers?

[jw]

Which is easier to onboard new users/players?

[Stylianos Gakis]

Yes, if there is one which is simple enough that it doesn’t need all this support around it I would say it’d count for these requirements. My point is that people (and especially newer in Android development) will naturally opt in to use the one which they can get the more information about it when they meet any issues, which evidently, they unfortunately do quite often with the androidx version.

[jw]

And that's a huge problem with AndroidX in general. It's a collection of libraries that's basically shipping their org chart

[jw]

They don't tell you this, but your MAD score is like golf. The lower the better.

[Stylianos Gakis]

Yeah, I am not pretending there isn’t such a problem. But such comments in my opinion bring more confusion rather than helping people who are in this channel to more often than not solve their issues and move forward with their projects.
If this comment said “Or a type safe navigation framework, try [X], I use it too and I enjoy it” I would 100% be behind it. In its current form, it bring this feeling of “Am I doing the wrong thing in the first place? But I don’t even know how I could do what this person suggests to me” which is a very bad state to be in while coming in this slack channel to get the help you need. Don’t you think?

[jw]

Well we have our own so I haven't used any of the open source ones therefore I can't make a concrete recommendation. However, the Jetpack one is a low bar to clear so I'm sure nearly any will be a step up.

[Stylianos Gakis]

Well on the other hand I wouldn’t be so sure without trying them out myself.
I’m certain not the same quality is to be expected from whatever random one someone may pick up from GitHub.
Especially when not having the prior knowledge or experience to know how to differentiate one that fits your needs from one that doesn’t.
Before you write enough code with it, only to realize, “oh I also need [X] support which this one does not offer me, what should I do now?” where X can be animation support, deep link handling, saving state on process death or you name it.

[jw]

Animation between screens

[jw]

Did they add that to the Jetpack one yet? Not sure how many people need that small feature

[Jorge Cordero Camarena]

Still part of Accompanist

[Stylianos Gakis]

It exists in Accompanist, which from the POV of someone using it doesn’t really matter. The point is that one can simply add the accompanist dependency and use it.

[jw]

Also true of every other navigation library though

[Stylianos Gakis]

Then we go back to my previous comments that it has to be easy to onboard (whether that is due to its good design or good docs coverage, support the use cases one might need and so on.

[jw]

If everyone fairly evaluated Google's libraries against open source ones on equal footing like that then I would be perfectly happy. But they don't.

[Stylianos Gakis]

It’s fine if not everyone does. All it takes is some good testimonies from people who have tried it and a naturally growing number of people spreading the word purely out of how happy they’ve been with using it. That alone would push me to try it out myself as well in order to form my own opinions about it too.
So far I haven’t seen any such initiative from any group of people using the alternatives. I of course may have not been listening/looking for it enough, but as it stands right now, I simply don’t have any such alternative libraries on my mind.

[jw]

Sorry but ten years of people continuing to use fragments disagrees with you. No matter how bad something from Google is it's near impossible to compete.

[Stylianos Gakis]

I think you are again missing my point on this one. Let’s take this scenario.

I am dev #1, started in this field 1 year ago, have joined a project using all the androidx solutions, our project is fragment based and I’ve dabbled into androidx navigation. At this point, I can’t even comprehend how an alternative to this world would look like.

I am dev #2, also 1y of experience, but I started my career in Square/Block, working on the same code base as you are (where you you are using your own solution as you said above). I haven’t worked with androidx navigation and I can see how it is inferior to what we’re using. And I have seen how a world without fragments looks like too.

As person #2, I can read this thread, agree with you and go on with my day.

As the person #1 I then read your comment here. I understand that Fragments may not be optimal, and androidx navigation leaves a lot to be desired. What are my steps forward? What do I do? Nothing is what I do, I take the L and continue with what knowledge I have right now and try to continue doing the best work with the tools that I’ve been served with.

I believe that this is the reality for the vast majority of the devs out there, and I think this is both normal and to be expected. Don’t you think this is the real reason why maybe for 10 years people have been using fragments?

[jw]

You are describing sunk cost fallacy. And yes, I do believe that is why people continue with these libraries.

[Stylianos Gakis]

I am also describing lack of a clear alternative though. Which is a very important part of this, along with sunk cost fallacy, which is definitely also there.

[Jan Skrasek]

https://github.com/kiwicom/navigation-compose-typed at you service

[Stylianos Gakis]

Hey this looks interesting Jan. I’ve also taken a look at this https://github.com/raamcosta/compose-destinations which feels like it does the same, patch some type-safe destinations on top of androidx. Have you checked that one out? Is yours different/better in some way in your opinion, or was it that those two were developed in parallel?

[mgrazianodecastro]

Im having so much trouble trying to debug navigation, that im gonna take a look at the alternatives

[Jan Skrasek]

it was developed later. since we don't want to use KSP almost everywhere... as navigation and UI is almost everywhere in our app. (build perf reasons). also the libs size and approach is different: it is an optional addon, no need to rewrite whole nav stack at once. you may adopt screen by screen.