I’m also interested in this, and wondered if there...

# compose-android

[Mark]

I’m also interested in this, and wondered if there are any developments since 2021. Perhaps Material 3 has something?

[Stylianos Gakis]

What is ActionMode?

[Chrimaeon]

Action Mode was an API for the deprecated ActionBar. The successor never had that functionality. So I guess also the compose version will not have it.

[Chrimaeon]

@Stylianos Gakis

> In some cases, the action bar may be overlayed by another bar that enables contextual actions, using an ActionMode. For example, when the user selects one or more items in your activity, you can enable an action mode that offers actions specific to the selected items, with a UI that temporarily replaces the action bar. Although the UI may occupy the same space, the ActionMode APIs are distinct and independent from those for ActionBar.

https://developer.android.com/reference/android/app/ActionBar

[Stylianos Gakis]

Interesting, so basically the top app bar look and functionality changes depending on which action mode it is in. Perhaps in a multi-select scenario it gets an X button to cancel the selection and so on?

[Chrimaeon]

You can see the functionality in GMail for example if you long press an email in the list.

[Chrimaeon]

In compose you‘d just have a state and depending on it change the actions in the top bar.

[Stylianos Gakis]

So nowadays sounds like a job for an own wrapper around the existing top app bar which conditionally sets the action buttons and the title and so on to whatever it needs to be for that use case then.
The existing API is just slots for everything as far as I remember, so I can’t imagine it being too hard to build yourself

[eygraber]

Yeah I've found it pretty easy to implement this myself in compose. Much easier than it was ActionBar

[Mark]

Are there any styling guidelines for this in M3?

[Mark]

Also, would you navigate to it so that it’s on the backstack?

[Stylianos Gakis]

All the design guidelines are in here https://m3.material.io/components/top-app-bar/guidelines and I don’t see a reference to this.

[Stylianos Gakis]

Isn’t it usually that if you are in some kind of such “mode”, the back button (or gesture) just exits from that mode instead? Like gmail does.

[Mark]

Yes, and you’d get that for free if it’s on the backstack.

[eygraber]

It's not really a screen though, so it wouldn't go on the backstack. It's a UI treatment

[Mark]

In my app, I have an always-visible top app bar. Only one of the screens has an action mode. So really, it feels like top app bar shouldn’t know about any of this. But rather the action UI should be overlayed.

[Stylianos Gakis]

If you want me to be honest, it sounds like you need to split up those top app bars to not be the same one for all screens 😅
If you can’t do that, yeah maybe you need to take such a workaround for this case

[Mark]

So each screen would be responsible for including the TopAppBar? Hmm, transitions would look terrible no?

[Mark]

I appreciate the feedback. I’ll go with custom solution as suggested. Will be nice to get rid of a bunch of vector drawable resources finally!

[Stylianos Gakis]

So each screen would be responsible for including the TopAppBar? Hmm, transitions would look terrible no?

It depends, but if you want it to be persistent then yeah there is no way to do it without using alpha dependencies.

If you are down to use the alphas for animation and want to play with shared element transitions then you can have each screen have their own top app bar and make it look “persistent” by making it a shared element.
Video for reference: https://x.com/GakisStylianos/status/1776910738616959118

[eygraber]

If you're able to draw over the TopAppBar you could overlay a new one on top of it.

You could also define a "service" for mutating actions and reacting to them, but what @Stylianos Gakis is saying is better.

[Mark]

How about using a CompositionLocalProvider so that both the top app bar and screen to communicate through that.

[eygraber]

That could work