Hi all, I am hoping to advocate for allowing deep links as start destinations within compose navigation. I saw this thread that discussed this a several months ago, but it doesn't seem to have reached the outcome I expected. I've raised a ticket to introduce this behaviour (https://issuetracker.google.com/issues/214733434), but it was marked as a duplicate of an issue with a similar explanation. I don't suppose anyone else would be interested in discussing this?

@Ian Lake as fyi

I believe in this situation my usecase is valid. I am working on a project where I use two NavHosts for tablets/foldables. When a user clicks something on the right panel (for example an email), I want to be able to open a second NavHost and immediately set the start destination to this email. Without being able to support a deep link as a start destination, the only way I have managed to get this to work is to create an 'empty' composable, wait for the NavGraph to be ready, then trigger navigation to the deep link

I was the one who closed out the original issue and marked this one as an exact duplicate - that's not what a

startDestination

is or what it is used for

any suggestions for my usecase? I'm hoping to create a library to make navigation for foldables more seamless for developers. i.e. if they are on a phone the deep link would open in the same NavHost, and if they are on a foldable a new NavHost is opened in the right pane and it starts on the correct page

That's not how you do two pane layouts. Did you get a chance to read the documentation on adaptive UIs and Navigation? https://developer.android.com/jetpack/compose/nav-adaptive

yes, I've read through the documentation. I'm hoping to provide a device agnostic approach that could make it appealing to developers to support tablets and foldables without explicitly coding for it

Explicitly choosing the most appropriate method (be it changing the presentation, amount of data shown, or doing something more extreme like having that specific destination implement a two pane layout) for making each destination responsive is a key part of the thought process; bypassing that is not the road you should consider long term viable

ah, but in my API I will be making it explicit.

Then the documentation is indeed the correct approach - the routes in your graph should cover the full area of the NavHost, even if an individual route is implemented differently (side by side vs overlapping) based on the device type

i.e. the user will explicitly say whether or not it should be shown in the left or right pane, and depending on the form factor it will either open a second pane, or open it in the first pane. Then if the user unfolds their foldable, the second pane appears as expected. i.e.

navigate(SECOND_PANE, "route")

So sure, having a

NavGraphBuilder.twoPaneComposable

helper method that sets up that one pane vs two pane approach is valid and useful

yeah. I'm really keen to see how useful it might be

but having a global idea of a left pane vs right pane is specifically not a pattern that we recommend - that's exactly what the Routes vs screens section is trying to get at - it is a per destination choice: https://developer.android.com/jetpack/compose/nav-adaptive#routes-vs-screens

The way that I am building this library would allow you to only have one pane on a foldable or tablet. It would be up to the developer how they want to use it

For the case of nested `NavHost`s, would splitting up the deep link be a solution? In other words, the outer

NavHost

picks up the first “half” of the deep link, and then defers the second “half” to the inner

NavHost

We actually specifically talk about deep linking over in the non-compose world for two pane layouts: https://developer.android.com/guide/topics/ui/layout/twopane?hl=en#navigation

The destinations in the detail pane's navigation graph should not be present in any outer, app-wide navigation graph. However, any deep links within the detail pane's navigation graph should be attached to the destination that hosts the 

SlidingPaneLayout

. This ensures that external deep links first navigate to the 

SlidingPaneLayout

 destination and then navigate to the correct detail pane destination.

Perhaps in this case I might be misusing the term deep link. In this case it's not a deep link from outside of the app, i just need to be able to support a dynamic route, and at the moment deep links are the only way to support that

That's not true at all

Perhaps poor wording on my part? I was replying to @Alex Vanyo

I think you have all the tools you need right now between setting the

startDestination

to the route of your choice and using a

defaultValue

on an argument for that start destination, to have any kind of 'dynamic route' you think you need

Can the default argument be dynamic? I.e. if someone clicks an email, can my start destination be email/1 or email/2?

your

defaultValue

for the

emailId

can certainly change to whatever you want, whenever you want

I think code might be easier?

val startIndex = 1

NavHost(
    navController = navController,
    startDestination = "deeplink/record/{index}",
  ) {
    composable(
      route = "deeplink/record/{index}",
      arguments = listOf(navArgument("index") {
          type = NavType.IntType,
          defaultValue = startIndex
      }),
      content = { backStackEntry ->
        ...
      }
    )
}

Ah... I think I get it now. I just need to make sure that when I create the graph I set the default value dynamically. I suppose then this is not an issue for my library, but a documentation detail I will need to ensure others how attempt this follow