I was wondering one thing regarding this PR https://github.com/joreilly/Confetti/pull/557/files Now that a “splash screen” destination is used as the start destination, doesn’t this mean that if there’s a deep link, it’s going to add that destination on the top of the backstack by default as this doc explains

When a user opens your app via an explicit deep link, the task back stack is cleared and replaced with the deep link destination. When nesting graphs, the start destination from each level of nesting—that is, the start destination from each <navigation> element in the hierarchy—is also added to the stack. This means that when a user presses the Back button from a deep link destination, they navigate back up the navigation stack just as though they entered your app from its entry point.

So if we deep link into say the schedule screen, the backstack would be [StartupDestination, ScheduleScreen], then pressing back would be for a brief moment [StartupDestination] and since that on launch navigates away and leaves the backstack it’d then be [WhateverItNavigatedTo], which if it’s the same as the previous deep link, it’d in the end end up making the back press feel like nothing happened, and you’d need to press back again. Am I tripping here? That’s how androidx.navigation handles start destinations right? With this in mind, shouldn’t the start destination in reality be the schedule screen, but with a default value of no conference selected. And then that can figure out if there’s a conference selected to show that one, or if the destination URL contained a conference so that it uses that one (and saves it in preferences too potentially), or if none of the previous two alternatives are true, to automatically navigate to the conference picking destination?

When nesting graphs, the start destination from each level of nesting—that is, the start destination from each <navigation> element in the hierarchy—is also added to the stack.

My understanding was that we don't have 'nested' graphs only one flat navhost. But maybe I'm misreading things there

I share your concern. I was re-reading Ian's advice to Martin yesterday. I don't think it's 100% right after this PR, but at least it's consistent with mobile now.

My current mental model is : •

session/$conferenceId/$sessionId

opens the specific session of the specific conference •

conferences

opens the list of conferences •

initialLoading

opens a progress view that loads from shared preferences and then redirects to

sessions/$conferenceId

Yep, the startDestination is always at the top for a deeplink.

Gotcha :til:

For a pending intent you can create a particular stack, so I can probably try that for the wear complications.

Hey I don't have access to https://kotlinlang.slack.com/archives/C051P2HUVKP/p1681030969644759?thread_ts=1680994152.780399&amp;cid=C051P2HUVKP If there some way I can read this? I don't think I've seen this discussion with Ian actually, but if loved to do so, is it the link you've shared here? I was trying yesterday too make this work this way too, and I found a bunch of issues too, like the inconsistency between if you deep link to/kotlinconf2023 for example but your old settings still have some other conf saved (you'd have to update it in this case it seems). Also struggled a bit with figuring out when exactly you'd open the conferences screen, since on app start, for a brief moment, if you've not deep linked you're in this loading state where the app needs to figure out if there was an old conf selected from preferences (read from suspending function so you don't have access to it on frame #1). Maybe this startDestination trick with reading the bundle can do it. I'll try and see what your PR does as well to get some inspiration.

It's in pieces at the moment. I'll take a look tonight or tomorrow to try getting it working.

That’s an interesting approach yeah! I have been trying to get something working too and I never really managed to get it working as I wanted it to. Maybe I can try and get some more inspiration from what you did with this extra home destination to fill this gap. Speaking about this btw https://kotlinlang.slack.com/archives/C051P2HUVKP/p1681030984833839?thread_ts=1680994152.780399&amp;cid=C051P2HUVKP I was trying to see if we have a deep link for example like

"<confetti://confetti/sessions/{conference}>"

and we start the app using a string like

<confetti://confetti/sessions/kotlinconf2023>

, I did not find a way to extract this “kotlinconf2023" outside of the NavHost so that I can pass it in the

defaultParameter

. I see in your PR you’ve also left it as a //todo Doing

intent.getStringExtra("conference")

seems to be null. In fact the entire intent.extras seems to be null (at least inside the onCreate where I was trying to read it) I feel like there’s something I am missing here, haven’t really worked with deep links before. Instead doing

intent.data

gives me back “confetti://confetti/sessions/kotlinconf2023" but aside from doing

intent.data?.pathSegments

on it, and trying to figure out what the result was by taking the last one, I don’t know how else I’d get it. It seems like you can’t get it by the id it had, since it’s already decoded to “kotlinconf2023” in this case. Quite confusing overall tbh 😅 I agree that having a home destination which also expects a variable is quite confusing. If the home destination was something more “static” the nav library handles it in such an easier way

I think it requires parsing the uri

Right, but typically, if you are trying to get a link working, let’s say when clicking a link from a website you aren’t able to build such a pending intent right? Isn’t that more for clicking notifications and so on?

I think it requires parsing the uri

So that’d mean literally doing this yourself then right? I guess if we know the url and that it’s always the last path segment it’s simple enough. As long as that’s a normal thing to do.

I'm not sure what's normal.

Yes, for notification and tiles that makes sense. Deep links would be from other apps, but wouldn’t they also be when potentially clicking a link on a website that your app has said that they know how to handle? Think like reddit links, that when you click on your device it actually opens the app instead. I suppose those are also cases where you can’t get a pending intent.

Yep, so confetti:// and say https:// if we took over serving of those urls on mobile? https://kotlinconf.com/speakers/0392772c-28d4-47f6-bd39-47d743fb4a81

Yeah exactly, so optimally we’d be able to handle both, so our nav setup should be able to handle both.