Trying out compose-navigation dialogs. What would ...

# compose

[allan.conda]

Trying out compose-navigation dialogs. What would be the correct way to navigate from the dialog?
Currently navigating from it dismisses the dialog and I can’t go back, unless it navigates to another dialog.

I’m using these dialog destinations as Full-screen dialogs, and some screens can be navigated to from this dialog
and also from other composable destinations.

I think the compose navigation behavior makes sense. I’m not sure what’s the right way to achieve the requirement, or whether I’m going against the navigation principles.

[allan.conda]

code illustrating my points

Untitled.kt

[Ian Lake]

Correct, dialog destinations cannot be underneath non dialog destinations, as per the documentation: https://developer.android.com/guide/navigation/navigation-navigate#back-stack

[allan.conda]

Ah, I didn’t know the navigation docs got updated with dialog stuff, I’ll check it out, thanks!

[Ian Lake]

There are a lot of Navigation Component docs that apply to every Navigation integration, including the Compose one. This is one of those cases

[allan.conda]

👋
Is there a plan to support destinations nested within a dialog?

[Ian Lake]

As per those docs, you can already launch one dialog destination from another, that's fine. Putting complicated logic in a dialog is generally a bad idea from a UX perspective and made near impossible by Android since dialogs intercept the system back button so early on in the dispatch that none of the normal logic you can write (i.e., BackHandler) actually works at all, which pretty much rules out having more than one screen within a dialog (as you could never hit back to go back through the previous screen)

[allan.conda]

Yes, I tried to replace all dialogs and its destination into dialogs for now and it works fine. I want to avoid having to put a NavHost inside a dialog, and it seems that wouldn’t work anyway because the BackHandler wouldn’t work like you said. Also because of other complications such as deep linking.

I got curious because I checked our iOS counterpart and they were able to have both showing modals on top of one another, and navigate within the dialog as well, from the same dialog. Actually they call them modals, it may be conceptually different. So I need to prepare an explanation why the latter is not possible/preferable on Android. I could also make a case that it’s a bad UX 😄.

I would note that I’m trying to show full-screen dialogs which override usePlatformDefaultWidth=false. I just noticed it says in the Material doc that it’s the only type of dialog which can show other dialogs on top of it, and I think compose dialogs currently allow any kind of dialog on top of each other, so that’s a bit weird.

And actually, I remember your other suggestion, before dialog composables were available, to simply hide the bottom bar for some screens, in order to achieve a full-screen composable, and effectively hiding the bottom bar. And then to just seamlessly transition between the screens when transition animations are availalble. It was complicated to achieve this without hardcoding before, but now there is a NavDestination.hierarchy which I can use. And I think I can keep the backstack with this approach.

So I figured I can consider all these options when showing a full-screen composable, and choose based on the requirement:
• Full-screen dialogs which can navigate to other dialogs, or no nested navigation: use Dialog
• Full-screens with nested navigation: use composable defined in the graph outside the Bottom destinations
• Screens that need to be navigated to from both a dialog, or a non-dialog: declare two destinations in the graph, a prefixed dialog version and a composable version in which both invoke the same @Composable Screen function
I’m not sure about all the implications and differences between the Dialog approach and the Bottom-bar hiding approach for full-screen cases. It seems it would work nicely with deeplinks, maybe dialogs would transition more nicely with actually appear on top of the bottom bars.

I ended up writing too long about this, and I don’t expect you to read it fully, but in case you did, what do you think? 🙂 I wanted to write my thoughts here as I would need to propose this to the team, and also wanted to help others in Slack regarding this topic.

[Ian Lake]

I think your thinking is in the right place overall

[Ian Lake]

A NavHost is a box in your UI that your screens go in. A FloatingWindow destination, such as a dialog, purposefully breaks out of that box (and on Android, actually breaks out of your whole Activity's window bounds as a dialog is a separate window entirely). If that's not what you want, then a dialog wasn't the right choice to begin with

[Ian Lake]

Their examples of a "full screen dialog" don't act or look like an actual dialog at all; you couldn't implement that design with an Android dialog anyways

[Ian Lake]

So I wouldn't take dialog literally

[Ian Lake]

You mentioned using the hierarchy to determine what is full screen or not - the other option is to use arguments with default values: https://developer.android.com/guide/navigation/navigation-ui#argument

[Ian Lake]

(that same technique applies to Navigation Compose)

[allan.conda]

the other option is to use arguments with default values:

Right! That sounds useful. I’ll keep that in mind.

Thank you for your help!