I (admittedly) haven't done too many screen size d...

# compose-android

[Colton Idle]

I (admittedly) haven't done too many screen size dependent layouts etc so I'm out of the loop on what the modern way to do that in compose.

One thing I need to do now (as per my designer) is "If the screen is small, please use 12.sp for this. In all other cases use 16.sp"

How would I do that in a composable? I've let my designer know that auto size text exists, but in this case they want this conditional.

[Chrimaeon]

Depending on what small means for your designers, this might or might not help: https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes

[Jonathan]

Is this the right way to do this? I thought using .sp would take care of appropriately scaling text and you'd use WindowSize classes to adjust layouts not dimensions.

[Chrimaeon]

How would `sp`‘s change for different screen sizes? They relate to screen density and the user’s preferred text size.

[Chrimaeon]

When defining text sizes, you can instead use scalable pixels (sp) as your units. The sp unit is the same size as a dp, by default, but it resizes based on the user's preferred text size. Never use sp for layout sizes.

https://developer.android.com/training/multiscreen/screendensities#:~:text=When%20defining%20text%20sizes%2C%20you,use%20sp%20for%20layout%20sizes.

[Jonathan]

Theoretically would the designer choose an appropriate text size and the different phones would scale it appropriately to look roughly the same?

[Chrimaeon]

I guess the designers intention is to get more content on the screen where 16.sp text would take too much space on small screens but look good on bigger ones.

[Csaba Szugyiczki]

@Jonathan The point here is to make it look different for small screens. Reason might be, preventing the text from breaking into multiple lines without ellipsizing them.

Colton is right that Autosize text with a minimum of 12.sp would be a better fit here.

I think you could get away with introducing a new CompositionLocal that you set somewhere top level, around Activity, based on the width of the screen. Then you could access it wherever you need, and not need to compute it every time.

If you need it at only one screen a very few places then it might be okay to compute it every time at screen level. Something like this

val windowInfo = LocalWindowInfo.current
val screenWidthDp = windowInfo.containerSize.width

[Stylianos Gakis]

I know this might spook your designers, but do let them know that people will still exist who use small devices but have their font size bigger than the default value.
Just make sure they understand that doing this workaround is nothing more than a workaround, and that they still need to make sure that their design looks and works well even if the texts wrap over to a second (or more) line(s).

[Jonathan]

Not sure if considered, but fonts would also change when entering/exiting split screen node (as well as adjusting the screen divide ie 1/2, 1/3 etc). Might be jarring to see the text of screen grow/shrink; especially when other apps don’t behave this way… Since there is a separate WindowSize for portrait and landscape, depending on how you’re using WindowSizes, I think rotating from landscape to portrait could cause you text to scale as well.

[Jonathan]

Not saying this approach is wrong but want to at least point out “side effects” that might not be obvious.

[Alex Vanyo]

There are also "display size" settings on most devices, that effectively change the density being used.
So it could also be strange if increasing the display size, which causes the effective window size to shrink, causes text to become smaller rather than bigger if it crosses the threshold.

Also there's the distinction of "screen size" vs "window size", I think it's a good habit to get into to talk about window size rather screen size - actually changing things based on the physical screen size is almost never the right thing to do

[Csaba Szugyiczki]

@Alex Vanyo The thing you say about effective window size is a great take. It makes me wonder. Doesn’t it make Autosize text also counter productive? That will also have the effect of shrinking text size while the surrounding component sizes grow. 🤔