Has anyone faced any issue with destinations v2 I ...

# compose-destinations

[Suhaib Kazi]

Has anyone faced any issue with destinations v2
I have multiple NavHostGraph (previously was using single default RootGraph
And now i get this issue.
java.lang.RuntimeException: Context was requested, but it is not present

[Rafael Costa]

Hi!
Do you also have multiple DestinationsNavHost calls?

[Suhaib Kazi]

Not in the same composable or screen if thats what you mean.

P.S I love your work Rafael.

[Rafael Costa]

(Thanks!)
I don’t mean in the same screen, I mean generally.

[Suhaib Kazi]

Yes
I do
I have deconstructed my Application into multiple flows and was thinking for each flow ill use its own NavHostGraph without a parent and connect these separate graphs using normal activity calls.

Am i doing anything wrong here?

[Suhaib Kazi]

Each flow is contained in a separate activity. which helps me in killing everything related to that flow

[Rafael Costa]

It’s hard to know.
Generally speaking, I believe having a single top level NavHost call is better.
If you have multiple, you have to understand the each has its own NavController, and each NavController can only navigate within its own destinations / graphs

[Rafael Costa]

If you use multiple Activities, it should be easier to manage multiple NavHosts.
But again, you won’t be able to navigate from feature A to a inner screen of feature B. Only to feature B activity

[Suhaib Kazi]

That is understood, that's why i implemented in such a structure so that i can have separation of concerns between different graphs.

I'm trying to have as flat a hierarchy possible of navs

[Suhaib Kazi]

Yes, i understand i wont be able to and that is how i want to keep things as well.

[Rafael Costa]

Ok sounds good then 👌

[Rafael Costa]

Im not sure what could be causing the missing nav argument then (I assume from the log you posted that’s what it is)

[Suhaib Kazi]

Oh wait, is it absolutely required to pass the destinationNavigator?

[Suhaib Kazi]

in the composable?

[Rafael Costa]

No.

[Rafael Costa]

Can you post the stack trace of the crash?

[Rafael Costa]

It would seem that one of your destinations is receiving a “Context”. Can you identity this parameter? Is it not a nav argument?

[Rafael Costa]

Is it Android context?

[Suhaib Kazi]

Rookie mistake, i've figured it out rafael.
Sorry to waste your time.
I'm still getting my head around the entire compose navigation structure.

I basically refactored my code into separate files and there was a top level context that was being passed and when i refactored i didn't check properly the parameters of each composable and there was a parameter of context.

Which obviously i hadn't and shouldn't provide in the dependencyContainerBuilder

[Suhaib Kazi]

That's what was breaking.

[Rafael Costa]

Perfect 👍 glad I helped in some way

[Suhaib Kazi]

the moment you mentioned navargs it clicked
Thankss

[Rafael Costa]

I could make the exception message a bit more helpful 😛

[Rafael Costa]

just by saying "not present in dependency container" or similar, it could have saved you some time

[Suhaib Kazi]

Just to get ahead
What do you think of the nav structure i mentioned?
Will it hold?

[Rafael Costa]

The only concern that comes to mind is with deep links.

[Rafael Costa]

I'm not sure how the app will behave to those. Maybe you'd have to redirect them to specific activities manually? 🤔

[Rafael Costa]

not sure...

[Suhaib Kazi]

Better messaging always helps. I'm very impressed by the quality of library and the support.
Phillip also did a great job in explaining. But otherwise the documentation is well written too
Let me know if i can help in any way. Would love to be involved.
I was a opponent of navigation itself before compose, i only moved to navigation because of destinations in both compose and xml

[Suhaib Kazi]

I don't have many use cases for deep links but will look into it wherever it comes into place, Maybe the activity will have to handle the deeplink and then forward it to screens, i'll have to look into it.

[Rafael Costa]

Everything should be doable 👍

[Suhaib Kazi]

Just a thought, What if to control the activities as mentioned will be my entry points for each graph is annotated with activitydestinations?

Then the deeplink issue shouldnt come too right?

[Suhaib Kazi]

The idea of going with multiple activities was to have them self contained

[Rafael Costa]

Hmm, then I don’t know tbh. Since you still have another NavHost in the middle. Not sure if it will be smart enough

[Rafael Costa]

What about it makes it more self contained in your view?
The alternative being that each feature would expose a NavGraph that gets included in a main graph in the main DestinationsNavHost?

[Suhaib Kazi]

Thats the idea, that each feature would be exposed to the mainappnavgraph
Each features' entry point would be an activity

[Rafael Costa]

Yes, but then each activity has its own NavHost, right? That’s what I’m saying. If you forget the activities and the additional NavHosts, each module provides a nested NavGraph and there’s a single main NavHost graph that contains all features’ graphs.

[Rafael Costa]

Why is that less “self contained”?

[Rafael Costa]

Im not suggesting it’s a wrong idea btw, im just trying to understand it 🙂

[Suhaib Kazi]

You are right, its back to the same idea of single activity arch, without the NavHost graph actually being a single activity.

[Rafael Costa]

Once you go single activity, you can’t go back 😜 I just find it way easier to manage

[Suhaib Kazi]

I'm trying so hard to not go single activity. But also i'm not finding many cases that cant be done in single activty arch 💀💀💀
It's like im gatekeeping myself lmao

[Suhaib Kazi]

I guess it's just a behaviour that is set in.
I always think of activities as a hard death of anything connected to it and helps me think that everything related to it as cleared off and died

Rest screens in this case feel very soft deaths, and doesnt give me assurance that everything has been cleaned

[Suhaib Kazi]

Maybe i have to look deeper into creation and death of screens and how can it be still done in singleActivityArch

[Suhaib Kazi]

Also what helps me is that the Viewmodels that i attach to an activity which is held in reference for all its subsequent screens in the same flow

i know it can be done similarly for the single acitivity arch too but like in acitivty i know that the activity will clear everything and the viewmodel will do its job too

[Rafael Costa]

You can tie VMs to nested graphs to achieve the same behaviour. If you want to clear everything from a “feature” you can pop the nested graph entry from the back stack.
As long as you don’t tie things specific to features to the Activity (I never had such need) then it’s easy and you still know that everything is cleared.
That said, I am not against what you’re suggesting either, I just personally like it better this way 🙂

[Suhaib Kazi]

i understand rafael. Thanks a lot for your input.

[Rafael Costa]

Sorry I made a mistake, let me fix it 😅

[Suhaib Kazi]

But still i understood what you are trying to put forward

[Rafael Costa]

Done