We have 4 bottom tabs. Lets call it A, B, C, D. A...

# compose-android

[raghunandan]

We have 4 bottom tabs. Lets call it A, B, C, D. A is home tab for most users and its the start destination. Based on on user type we have B also as the start destination when we also have A in the first place( A is not the start destination when B is). The order of the tabs don't change. My argument with product owners is that If we can A as home and its the start destination why not deliver content in A based on user type. I want know your opinions on this. Do you have similar navigation requirement from product?

[Pablichjenkov]

You can have a destination named EntryPoint or StartDestination, then based on the user data you will navigate to A or B or C or whatever you want.
This starting destination is usually empty and won't have any visual or performance impact. If you need to get remote data to determine whether to go to A or B. You can have a simple loader animation for this Starting Destination

[Ian Lake]

You should not do this, it will break every deeplink in your app: https://kotlinlang.slack.com/archives/C04TPPEQKEJ/p1741571998688609?thread_ts=1741569280.360829&cid=C04TPPEQKEJ

[Ian Lake]

The start destination is used as the synthetic back stack when you deep link to a destination, meaning you'll have EntryPoint in your back stack when you hit back, which is not what you want

[Ian Lake]

Instead, you should be doing that kind of logic outside of your NavHost entirely, finding the correct start destination, and only then adding your NavHost to composition with the correct start destination

[raghunandan]

Thank you!. I just want to convince the product people. They just don't listen to me. I knew this. Now its from the expert i can hopefully convince them

[Ian Lake]

We have docs around this kind of thing (instead based on a user preference for the starting tab) in the docs: https://developer.android.com/guide/navigation/use-graph/programmatic#modify_inflated

While the examples are for Navigation with Fragments (where you inflate a graph from XML), the same text and concepts apply to Navigation Compose (the "setting the graph" just happens when you add the NavHost to composition, not when you specifically call setGraph)

[Ian Lake]

Also, I would separate what behavior the user sees (which should be a product decision) vs the implementation it takes to create that behavior (which you, as a developer, should be responsible for).

I'd try to make sure you are talking in terms of user requirements and the user's experience vs implementation details.

[Pablichjenkov]

Would creating an entry point destination have any issues if I make sure my deep links only go to these entry points in each graph/subgraph? Like I want to only expose this entry point and have the other graph destinations private of deep linking, even private to other modules of the App

[Ian Lake]

You would be breaking every external deep link used in every destination in your app, every use of deep links in notifications, etc., and every use of navigateUp()

[Pablichjenkov]

I see, sounds like I have some tech debt to work on.

[Jonathan]

@Ian Lake

Instead, you should be doing that kind of logic outside of your NavHost entirely, finding the correct start destination, and only then adding your NavHost to composition with the correct start destination

Where should this functionality be happening before the NavHost enters composition? I thought NavHost start destinations should be unconditional?

[raghunandan]

Before nav host you decide whats your start destination. Code in the docs link shows for xml and fragments same should apply for compose as well