Is there a sample that would show how handle actio...

# compose-android

[Matti MK]

Is there a sample that would show how handle actions in a TopAppBar in a full Compose app? I can see that Jetchat has top app bars, but it has different top app bar instances for different screens.

I'm looking for samples / information on how to handle actions from the top app bar in a "normal" situation where there's only one top app bar defined on the root of the app, and it's contents change based on the current screen.

So, for example, let's assume there's a TopAppBar on ScreenA and that enables a multiple selection mode on that screen. The TopAppBar has this action, but it's defined somewhere in my App.kt file, whereas ScreenA is in it's own module. How to go about propagating the actions from the TopAppBar to the ScreenA? Is it expected to pass a lambda all the way from the root of the app to the screen?

[Ian Lake]

In a world of shared elements (where an element can appear as if it is one top app bar defined at the root of the app even if it is declared at a much lower layer), I'd strongly suggest a Jetchat like approach as soon as your top bar isn't identical: https://kotlinlang.slack.com/archives/C06CS4UCQ10/p1719588491485179?thread_ts=1719554859.324029&cid=C06CS4UCQ10

[Matti MK]

Thanks for the response. Let's see if I got this correct:

NIA also has a TopAppBar, but it's identical (same search and settings everywhere) -> use a root level TopAppBar

Jetsnack has screen context based functionality in the TopAppBar -> use screen/lower level defined TopAppBar

[Ian Lake]

I think that's a good way to think about it

[Matti MK]

Thanks for all the responses.

Curiously, a week later I'm still on this. Mainly, because the screen(s) affected by the TopAppBar are actually in an AdaptiveLayout that contains about 15 screens.

Well, nonetheless, I'm now in the middle of refactoring, giving each one their own TopAppBar and as suggested in the thread you linked, using sharedElement maybe also.

Well, now I have a new spec for this: when the device is offline the TopAppBar should show this offline state. This leads the TopAppBar to have:

1. Screen specific functionality
2. No functionality (the majority of the screens)
3. Somewhat complex functionality to show network state, requiring a VM (all screens)
2 & 3 would be easy with a shared TopAppBar: one VM and one "instance" of the Composable living at the root of the project. But Now after the refactoring I will have N TopAppBar, each one requiring their own VM instance to provide them with offline information.

Does this change the way I should think about the TopAppBars?

[Alex Vanyo]

Linking to other thread for vis: https://kotlinlang.slack.com/archives/C04TPPEQKEJ/p1734109297071029

[Alex Vanyo]

I’m in disagreement with Ian on this, about broadly recommending the shared element approach because of a case like this where a TopAppBar lives outside of any particular pane. I think that’s a very reasonable design, and there’s a need to have some UI that knows about the overall navigation state, but doesn’t live within any particular destination

[Ian Lake]

I think that is probably discounting how many apps actually have the exact same top app bar on every screen (i.e., almost none, particularly when you take top app bar actions into account).

If you want your transition to look nice going into and out of those one off cases, you're going to have to use the shared element approach at some point just because shared elements actually play nicely with animations

[Alex Vanyo]

Agreed, but as soon as you want to have a top app bar that is not visually contained within any particular single destination, that UI component has to live somewhere outside of a specific destination, at least conditionally in some parts of the app.