Open sourced a single `@Composable` function for C...

# feed

[Alex Styl]

Open sourced a single @Composable function for CMP

I needed a common way to access the window container size but it is not yet available on Android, so here is currentWindowContainerSize until it LocalWindowInfo.current.containerSize reaches common:

@Composable
fun App() {
    val containerSize = currentWindowContainerSize()

    if (containerSize.width >= 480.dp) {
        TabletLayout()
    } else {
        PhoneLayout()
    }
}

https://github.com/alexstyl/cmp-windowContainerSize

[Michael Paus]

I guess you mean TabletLayout and not TableLayout, right? 🧐😉

[Alex Styl]

good catch. fixed

[seb]

Why not using window size classes on Android? I'm fairly sure the logic in the snippet above is "wrong"

[seb]

https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes

[seb]

The breakpoint between phone (aka compact) and foldable inner screen/small tablet (aka medium) is 600 dp for the width

[Alex Styl]

Why not using window size classes on Android

You mean why use the function instead of window size classes? because I needed a way to be able to calculate my own window size classes / breakpoints, that is not tied to a specific framework

I'm fairly sure the logic in the snippet above is "wrong"

you are right. it's a random value i put for this example

[seb]

I meant why not using WSC in the Android impl, and/or an API in that style for other targets too

[seb]

WSCs are available in common code... https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/window/window[…]ommonMain/kotlin/androidx/window/core/layout/WindowSizeClass.kt

[Alex Styl]

Because in order to have the WSC style api, I wanted to have a common way to get the container size (hence the function)

[seb]

I see, got it 👍

[Alex Styl]

@seb WindowSizeClass is not customizable is it (as in i cant set my own breakpoints)? from what i see it is not, but maybe i am missing something

[seb]

I think there is a way, but I don't remember for sure. That's a Roberto question

[Alex Styl]

found something https://android-developers.googleblog.com/2025/03/jetpack-windowmanager-14-is-stable.html?ref=dailydev

[Alex Styl]

// new
val sizeClass = WindowSizeClass.BREAKPOINTS_V1
                               .computeWindowSizeClass(widthDp, heightDp)

when {
  sizeClass.isWidthAtLeastBreakpoint(WIDTH_DP_EXPANDED_LOWER_BOUND) -> {
    doExpanded()
  }
  sizeClass.isWidthAtLeastBreakpoint(WIDTH_DP_MEDIUM_LOWER_BOUND) -> {
    doMedium()
  }
  else -> {
    doCompact()
  }
}

I dont get what i am reading. looking into it

[Alex Styl]

ok it seems configurable. the API seems awkward but seems configurable. nice

[Alex Vanyo]

LocalWindowInfo.current.containerSize just became part of 1.8.0 on the Android side:
https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/WindowInfo#containerSize()

[Yang]

https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1696616182202429?thread_ts=1696442432.065739&channel=C0346LWVBJ4&message_ts=1696616182.202429

Is this still valid for android? There’s a new lint check in 1.8 that suggests migrating from LocalConfiguration.current.screen*Dp to this new API but the result is different.

[Alex Vanyo]

LocalWindowInfo.current.containerSize ’s implementation should match WindowMetricsCalculator.computeCurrentWindowMetrics - are you seeing a case where it doesn’t?

[Yang]

@Alex Vanyo No I’m getting a lint error on val screenWidth = LocalConfiguration.current.screenWidth.dp after upgrading to 1.8:

Using Configuration.screenWidthDp instead of LocalWindowInfo.current.containerSize

is this a false positive?

[Alex Vanyo]

That’s expected! That lines up with my comment you linked, to avoid LocalConfiguration.current.screenWidth.dp.
Now there’s a better built-in way with LocalWindowInfo.current.containerSize

[Yang]

ok so I’m seeing big differences in previews and paparazzi tests with this change, I’ll try to make a minimum repro

[Yang]

@Alex Vanyo sorry the issue was on my end, LocalWindowInfo.current.containerSize works as expected 👍

[Alex Vanyo]

Ah good to hear! Curious if that issue is something someone else would run into - I wasn't going to be entirely surprised if previews and Paparazzi tests interact somewhat strangely on some versions

[Yang]

So the issue was due to converting from screenWidthDp.dp directly to containerSize.width.dp, forgetting that the unit has changed so it should be with(LocalDensity.current) { LocalWindowInfo.current.containerSize.width.toDp() } instead 😅

[Yang]

guess this could be another lint check

[Alex Vanyo]

Ohhhh… that’d be a great lint check to add