https://kotlinlang.org logo
Join Slack
Powered by
Anyone know why JetSnack has 2 NavHosts and 2 Jets...
# compose-android
a
Anyone know why JetSnack has 2 NavHosts and 2 JetsnackNavControllers - is this doing something simply impossible with single Navhost etc
m
Conditional navigation, that's the topic i think you're searching
a
I looked up “Conditional Navigation” in the docs https://developer.android.com/guide/navigation/use-graph/conditional but I did not see any mention of the double navhosts / navcontrollers.
Actually, I can’t find nested NavHosts anywhere in the navigation docs - although there are some oblique references to them in the release notes here and there
m
Mmm, nested navigation Is a thing that helps with complex navigation and the modularization ... With compose there isn't much detailed, check medium or dev.to for dome contenta about it
a
I have not checked 
JetSnack
but the project I work on also uses 2 NavHosts and 2 Controllers. I am going to assume that they have used it for similar purpose as well. Our usecase required us to open full screen content (not limited to opening a screen within navigation content). You can think of this as navigating to a Screen or Content that has no link with a top level destination. e.g Auth Flows, Payment Flows, Chat Screen etc.
is this doing something simply impossible with single Navhost etc
It is not really impossible. We also experimented with a single nav host + hiding the bottom navbar. The cons of this approach were: • Janky appearance even with animation. • Overhead of handling when to hide/show the navbar • A really unintuitive and a tightly coupled nav graph
a
Ok Thanks Ahmed & Marlon. I am not sure how to adopt the dual-NavHost approach to a multi module project that (typically) will encapsulate a feature’s destinations within a subgraph. Now somehow it (or the :app) module would have to know about how to partition the screens / destinations between 2 NavHosts / NavControllers: FeatureX screens that appear with Bottom Nav, and those that do not
m
@alexhelder i think a very common example is related to the following user flow:
🧑🏼‍🦲 - | entering app first time | -> [ onboarding ] -> [ main ]
Where onboarding and the main features contain its navigation host and internal contents and/or viewmodel and/or state holders
a
@alexhelder an approach that’s not so much tacky is that you can use a container for both navcontrollers. The navgraphbuilder in feature modules can accept the container and decide where to show which content.
j
@marlonlom Even with the flow you described it's still recommended to unconditionally navigate to your main route/destination (set as start destination on the graph) and have logic in your main route to navigate to the appropriate startup or onboarding screen. You can programmatically hold your Splash screen on display until you've properly loaded enough state to determine which route destination you need to display. From my understanding this is necessary because your app could have multiple entry points (think deep-links).

This ▾

video by @Ian Lake on Navigation, addresses using a "non-main" route as the start destination for you app and how it's can have undesirable side-effects.
☝️ 1
☝🏼 1
m
@Jonathan mm, i think one way to handle multiple navhost is related to the multimodule feature... an example for conditional navigation is handled via splashscreen api, when, combining with a stateflow via viewmodel, it can control the ui state for the splash -> main screen transition.
j
I still don’t see why you’d need multiple `NavHost`… To me, I would think you’r main module would contain the NavHost and it would have dependencies on your “feature modules” that contain your other screens. Your feature modules can/should dedicated graphs (
navigation<RouteType> {}
) but not their on 
NavHost
m
cc @alexhelder
65 Views
Open in Slack
PreviousNext
Powered by