Got a question regarding using `calculateWindowSiz...
# compose
Got a question regarding using
I find myself often passing the WindowSizeClass calculated in the Activity inside my composable, and then figuring out what to do with it inside there. For example, in a case where I got a column of items, where if the screen is very wide, I simply want to make it look more centered, by adding a bigger padding around, so that on thin screens the entire wifth is utilized, while on wide screens I can do with just 80% of it for example. So I start by creating a modifier like this:
Copy code
val sideSpacingModifier = if (windowSizeClass.widthSizeClass == WindowWidthSizeClass.Expanded) {
} else {
  Modifier.padding(horizontal = 16.dp)
And then in my column of items I do something like this
Copy code
Column {
  Composable1(..., sideSpacingModifier)
Do you find yourself doing something like this too? I haven’t seen a lot of code which handles wider screens, aside from those sample apps which change the entire layout completely, like showing more columns instead of just 1, but it isn’t always appropriate for what I may be doing.
It's tricky, since "properly" is really more of a question about the design of the layout over anything technical. How I think about it is to use the
to make decisions based on the overall app layout. From a design perspective, that'd be the overall layout of a screen based on a certain amount of available size. For simper screens, you might only need to change the spacing or alignment, like in your case. At the same time, individual components should also be responsive and not care too much about how much screen space is available, it should be more about the "local" space available.
It's easier to point out cases that I'd be suspicious of, then to highlight a "perfect" approach. Like if I was looking at a general purpose
, and it internally was making some decision based on the window size class, that'd be a bit suspicious to me. Why is a specific reusable button changing completely based on the overall screen size? It might be that the design calls for a different arrangement at some screen size, in which case it might make sense to "hoist" that logic outside of a reusable button to keep it closer together with that other logic.
Or put another way: the further the
gets passed down the composable tree, the more suspicious I'd become. At some point, it'd probably be better to "manifest" a specific, named decision based upon the
(use this alignment, or this padding) then to keep passing it down further and further
Yes, I think I do get suspicious as you say the further down this class is passed. I’d imagine if a supposedly reusable component accessed it, it’d be very bad, since even though the screen may be in an Expanded width state, that specific component may actually be part of a not so wide column, so the fact that the entire screen is in this state really shouldn’t affect how that is laid out. In general I think it is easier to use this class when making high-level decisions, like if we’re in the Expanded state, show a navigation rail and two columns of content instead, where from that point on all these child components don’t need to know anything about this windowSizeClass. I think for my case, where I do not have a proper design for wide screens in this scenario, yet I do not want it to look like a stretched out mess, doing what I am doing to make it take only a more central position to the screen (kinda like how web devs do in a lot of websites) is good enough. And I am making this decision only 1 level deeper than the activity, on the entire screen composable, and not passing it further down. Thanks a lot for the response btw! Handling bigger screens is for me a very new concept so I am sure I gotta make a lot of mistakes first before properly understanding how to use the tools available to me to do this.