Hi, I'm building a compose app using a nested `Sca...

# compose

[Junsu Park]

Hi, I'm building a compose app using a nested Scaffold pattern, similar to a primary/secondary structure I used in Flutter.
• primary (root): root layout (coordinator), contains main BottomNavBar.
• secondary (child): inside the primary scaffold.
in Flutter, setting primary: true on an AppBar or Scaffold seems to do much more than just manage padding. In Compose, it feels like I have to do all of this manually. is there any way to achieve this primary/secondary problem easily? or am I missing some key idea of compose?

thank you!

[Filip Wiesner]

I don't think Material has a concept of a primary/secondary app bar. That must be some Flutter-specific thing. Scaffold is just Scaffold. There is no secondary Scaffold. What are you trying to do? How is the secondary Scaffold different from primary?

[Junsu Park]

hi, thanks for your response, i think the secondary scaffold in flutter has
• system paddings (system status bar and navigation bar)
• auto system UI color by app bars
• (maybe flutter specific) scroll detection - auto elevates app bar on scroll from primary = true scaffolds

[Filip Wiesner]

I see, then you are right to say, "_it feels like I have to do all of this manually_" I think, in general, Compose tries to do things more explicitly.
The padding, for example, should be out of the box if you use the material app bar and bottom navigation. Otherwise, you have to add them yourself, but it's as easy as applying the systemBarsPadding() modifier.
System UI colors are a bit tricky. There used to be a semi-official library for that, but that's deprecated now with no alternative, as far as I know.
The auto-elevating app bar is there, but you have to do the wiring yourself. However, it's pretty easy to do. Here is the documentation.

Overall, I am in favor of components working more on their own and developers having to connect them. It makes everything more flexible IMO. But I see how it can be annoying coming from a system where everything is opinionated and done automatically.

[Junsu Park]

I really appreciate Fillip. I should have been more specific, and I feel sorry that my casual question.

I strongly agree with your answer. Since I started studying mobile apps with Compose and then developed with Flutter for a while, I wanted to clearly understand the differences between the two and approach each one in its "correct" way.

The question I asked was quite confusing and difficult to understand, but I want to thank you again for taking an interest and giving such a sincere answer. I think I'll be able to think in a better way when I write code.

[Filip Wiesner]

Sometimes it's hard to ask the right questions without experience in the subject. I've never used Flutter, so I can't really explain the different mental models. But maybe a good example of how Compose was designed is the remember function. In the alpha versions of Compose, when you wanted a state value in composition, you could write var a by state { ... }. But later, it was deprecated in favor of mixing remember and mutableStateOf. It's now longer to write the same, but it should be clearer how it actually works. `remember`'s responsibility is to keep what's inside between compositions, and mutableStateOf is there to propagate the change where needed and trigger recompositions. Each thing has its own purpose, and you achieve what you want by combining them.