Not having the answer to this question has bugged me for a while. In the app I'm working on, we have...

# compose-android

[bryankeltonadams]

Not having the answer to this question has bugged me for a while. In the app I'm working on, we have our main NavHost which is inside of a Scaffold(this scaffold also contains a TopAppBar and SnackBarHost and then the content is the NavHost). We have some Screen composables which are the root of some navigation destination routes that we navigate to, and those screen composables have a ModalBottomSheet which we use for applying filters. Anyways, the ModalBottomSheet content is another NavHost with it's own navController, because inside of our BottomSheets we have to do "navigation" such as clicking a Location selector and navigating to a location picker. I've seen mixed things about "Nested NavControllers" and it being a mess to manage multiple navControllers etc. I've wondered if it would make more sense to do what we're doing with a Pager, even though not one page leads directly to another, as in if it were a Pager, Page 1(the main selector page) would have to navigate to Page 2 and Page 3, but Page 2 can't navigate directly to Page 3 and Page 3 can't navigate directly to Page 2 etc. Screenshots attached of the current screens I'm working with.

[bryankeltonadams]

First "Screen" or the startDestination of the nested navHost.

[bryankeltonadams]

the locationPicker screen on the locationPickerRoute of the nested navHost

[bryankeltonadams]

This is a screen we use Pager for instead of nested navigation. Where it seems a lot more clear that Pager makes sense, we have the Main Pager with two pages and the shared header selector outside of the two pages for switching pages.

[bryankeltonadams]

I guess I'm wondering if it makes sense to convert this over to a Pager, leave it as a nested NavHost, or if there's a better solution for navigation that happens in these bottom sheets.

[bryankeltonadams]

Seems related to android:theme in AndroidManifest as well as using android:windowSoftInputMode="adjustResize"

Not sure what to use instead.

[bryankeltonadams]

the white is coming from the default "android:theme="@android:style/Theme.Material.Light.NoActionBar""

and the reason it's showing the white in the first place is

android:windowSoftInputMode="adjustResize"

[ascii]

nit: location text field in the first screen indicates that it user can type something into it, but apparently it just opens another UI, with everything different? Is the first screen just a fake out? User needs to type in the second screen instead? Even placeholder text is not the same (select vs search); feels so disconnected.

[ascii]

Semantically I've always found NavHost suits best when screens are distinct and self-contained. There shouldn't be any dependency between them. Even if some screens can be opened from another — e.g. from a list of items (screen 1) user can click on something to see more details (screen 2) — they're still their own thing; screen 2 can exist & be opened without screen 1 (deep links).

In your case it seems that the location picker can only be opened from the first screen, and nowhere else. It is not its own thing.

[ascii]

Pagers may suit your use-case better, but imo it's unnecessary.

Why not go with the design of an autocomplete popup instead? User types something, results show up and are filtered real-time. That fits in better with text fields.

Or if that seems wrong to you, you can flatten these 2 distinct screens into just one: initially only text field is visible, and when the user starts typing the other UI with sort buttons & results expand out below the text field; in-place. All of this can be controlled by a single state variable.

[ascii]

(sorry for the classic "you asked me this but I'll tell you do to something else")

[bryankeltonadams]

@ascii just following the designs on Figma, I didn't create the designs, but we're not wanting to change the flow at all, it is a distinct screen. I think the reason for being a TextField that actually isn't enterable is because eventually we want to be able to use a Camera scanner to scan a barcode that maps to a specific location, thus not requiring that a user navigates away to make the input selection. Nothing is typeable on the first screen so yeah it is a fake out currently I suppose. There are going to be other situations where this location picker is going to be shown from other parts in the app unrelated to the Filter selection, basically anytime we want to show a location picker we're planning on using this Composable. Hope that gives enough clarity for you to potential confirm your existing suggestion or change it.

[ascii]

I see. Even then, don't you think either nav or pager is overkill? It would be simpler to have it in 1 "screen", and have the active UI swapped between two states (assuming all use-cases have the same logic: main driver UI -> location UI and back; nothing more).

[bryankeltonadams]

ah, so a single navigation point, but then a click would trigger a state and then the condition would change and it would render a different "screen" entirely?

[bryankeltonadams]

Hey Adhiraj, what if I was wanting to handle animations or something when this happens though? With navigation I can animate between screen a to screen B. Although I still don't like having nested navigation I would think just updating the composable on state change would be more like a flicker or screen replace and I wouldn't be able to animate a push or a slide up, would I?

[ascii]

There are several compose animation APIs, e.g. AnimatedContent, movableContentOf, etc. Check docs.