Why won't the boxes in my project occupy the whole...

# compose-android

[Uberunix]

Why won't the boxes in my project occupy the whole row, evenly split? I think I've tried every combination of modifiers I can think of, and I can never get the quadrants to expand to fill the space except for when they fill the whole width of the screen each.

On that note, my understanding was that if siblings in a row or column are each to told to fill their maximum width or height respectively, then that space would be evenly divided between them. From my attempts here that seems not to be the case. Am I incorrect? Is the statement above ever true?

[Stylianos Gakis]

modifier: Modifier = Modifier is unused in your Quadrant composable

[Uberunix]

Do you mean that I've referenced it incorrectly? Or that it must be used further?

[Stylianos Gakis]

You're just not using the modifier that you're trying to pass in there. The .weight modifier you pass is simply never used anywhere.

The IDE is also trying to help you by showing you that it's grey, aka not used

[zsmb]

To be more specific, you should apply it to the root composable that you call into in the implementation of Quadrant. So with the code in the screenshot, where you have

Box(modifier = Modifier.something())

That should be

Box(modifier = modifier.something())

... so that the externally passed in modifiers like the weight here are applied to the component.

[Stylianos Gakis]

And some more reading on this if you're curious https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-api-guidelines.md#elements-accep[…]ifier-parameter

[Uberunix]

Would either of you have further suggested materials for understanding the mechanics of Modifier and, more generally, properly transmitting parameters like it to children? Thanks to your help, I solved the problem above and successfully created a scalable grid, but I then ran into continued issues as I attempted to align the children within those quadrants.

Gemini explained that my problem was now the inverse. I was referencing modifier when I should have called Modifier. I began reading at Compose modifiers | Jetpack Compose | Android Developers, but I think I need a better grasp of the fundamentals first.

[zsmb]

I think that Jetpack Compose docs page and the guidelines already linked above are probably the best written materials

[zsmb]

I have a tangentially related blog post which also explains how and why you need to apply the passed in modifier https://zsmb.co/remembering-modifier-order/

[zsmb]

There's also video content from the Android team about modifiers, like

https://youtu.be/xc8nAcVvpxY▾

[Uberunix]

Thank you! reading through your article is already helpful.

To begin with, I think I dismissed the importance of the language describing how Modifier is meant to be transmitted only to the root element of a composable. My conception was that, in essence, it can be passed down to children infinitely as a blank canvas, and for each child it only does whatever you specify in that scope.

However, if this is incorrect, I don't yet understand the purpose of passing it as an argument to the root element. If it's not meant to drill down into the composable indefinitely, why doesn't every block reference the Modifier object directly, just as the children are supposed to?

Perhaps this video has the answer. If so, please excuse me clarifying my thoughts here!

[Uberunix]

Or maybe my concept is entirely wrong! Maybe both approaches are valid and useful?

Is it more accurate to see it as a choice for convenience's sake? Where children can EITHER A. Inherit a modifier and its effects to reduce redundancy where appropriate, OR B. call up a fresh one for when inheritance is NOT desired?

All this as opposed to my original concept that the modifier object always exists in its scope as a fresh slate with no relation to its parent?

That would explain why the children of my boxes weren't laying out properly - because they were inheriting layout styles from the parents that were in conflict with my intentions.

Or perhaps its for purposes I haven't yet been exposed to. My assumption was that the modifier parameter at the top of the composable was just for the purpose of giving it access to a Modifier object - the default one being blank as it is. But maybe more advanced users are inserting their own Modifier constructs in, and this would allow for greater reusability in scenarios that I'll eventually understand.

So in that scenario, the passed in modifier is for external concerns that could be shaped by the code that calls it, whereas direct calls to Modifier are reserved for interior concerns that don't need external exposure?

[Stylianos Gakis]

Maybe this https://chrisbanes.me/posts/always-provide-a-modifier/ can also help answer some of your questions here?