So far what's the general approach to placing a `T...

# compose

[Zhelyazko Atanasov]

So far what's the general approach to placing a TopAppBar in a general case where every screen of an app has one. Do we create a single TopAppBar and mutate the title and menus via events or we'd rather have a TopAppBar defined in each screen? What bothers me in the second option is that if you animate the transition between screens, the TopAppBar will also be animated (I haven't looked into transition animations yet) unless we do something more custom for the app bar itself. And there are cases where the TopAppBar shouldn't be animated and only its title and/or menus should be updated when changing screens.

[Adam Powell]

This one's a matter of UX design intent and you can do either one as far as compose is concerned

[nitrog42]

I also had the same concern about how to do it (right now mostly the second way), but I have to add a con to the first option, when you have only one topappbar, with views I don't think there was a way to propagate scroll from a fragment in the current screen, for things like collapsing/expanding the toolbar.
But it might be something that is a lot easier with compose now

[Colton Idle]

Faced this when my team went to a single activity with multiple fragments. We decided to have the bottom navigation bar live in the activity because we basically could just show/hide it, but our top app bars (even though they seemed like they would be consistent) were not. Examples: Some screens needed a large top app bar that collapsed with a hero image into a top app bar. Other screens had a top app bar with a completely different color. Some top app bars had a requirement to be transparent to show content beneath. So yeah. Agree with Adam that this could almost be thought of as an issue for your design team.

One thing I thought I would hate was having identical top app bars across screens would make animations look dumb going from one screen to another, but it looked fine and there's ways to actually (in fragments at least) to opt your top app bar out of an animation that would likely take up the full screen.

You can see in this gif that my toolbar is actually in each fragment, but it doesn't look like the toolbar is being replaced at all. Looks pretty slick for being two separate fragments with two separate toolbars.

[Colton Idle]

https://user-images.githubusercontent.com/31751141/82252069-50aefa00-991c-11ea-857a-3a7a15261aff.gif▾

[Colton Idle]

You can follow this github issue/thread where I got a ton of help from the material team on getting this animation looking as perfect as we could. Ended up being fairly easy, but you just have to tweak the right thing.

https://github.com/material-components/material-components-android/issues/1224

Here was the exact piece of advice I got "@ColtonIdle np! You might be able to remove the bar from the animation by adding an id to your LinearLayout and using transform.addTarget(<id>)."

Again, I'm sure this will be different in compose, but I think the same applies. Anyway. Hope some of this helped!

[Zhelyazko Atanasov]

Yep, I know it's a matter of UX design and the use case of each screen. I was just wondering what are people doing.

@Colton Idle thanks for the links! My team is also going to a single Activity with Fragments approach in another app and the same question is on the table 😊 🙂 So the linked thread and experience was very useful 🙏