Is there a

calculateWindowSizeClass

equivalent for non-activities? We’re using a fair bit of

AbstractComposeViews

, leveraging interop capabilities and so activity instance isn’t available without casting the

Context

👀 Is this not enough? Or does rememberWidthSizeClass provide something else that this doesn’t?

@Composable
fun getWidthSizeClass(): WidthSizeClass {
    val configuration = LocalConfiguration.current
    val windowDpSize = configuration.screenWidthDp.dp
    return when {
        windowDpSize < 600.dp -> WidthSizeClass.COMPACT
        windowDpSize < 840.dp -> WidthSizeClass.MEDIUM
        else -> WidthSizeClass.EXPANDED
    }
}

Is there a

calculateWindowSizeClass

equivalent for non-activities?

A window exists at the root of the activity (and is tied to the activity), so you should calculate the size class at the activity level and provide the information down - it’s somewhat of an anti-pattern to try and figure out what the window size is from an arbitrary view, since the size of the window doesn’t mean that this

AbstractComposeView

has the same size, or any other guarantees. If you are using Views at the top level of your app, you can instead follow the View-based guidance for window size classes here: https://developer.android.com/guide/topics/large-screens/support-different-screen-sizes#kotlin Define your own comparable size class, and use this at the top level, and then pass down some information to your Compose views.

Is this not enough? Or does rememberWidthSizeClass provide something else that this doesn’t?

screenWidthDp

ignores system decorations (such as status / nav bars), so it isn’t really as accurate / consistent when we are specifically talking about window size classes, when it comes to things like going edge to edge

Thank you for answering that! So for an

AbstractComposeView

that’s a few levels away from the

Activity

(like inside a

View

within a

Fragment

), would you say it’s okay to maybe hold the state somewhere globally? Would it be okay to hold a Compose

MutableState

in a Kotlin

object

or equivalent and expose that to `Composable`s via

LocalComposition

? Or would you recommend using a

ViewModel

instead? Or is there a better way to put a

MutableState

in the global snapshot?

It seems wrong for you to hold this globally, it is very brittle if you change anything about where the view is placed. What's your use case here?

Ah my bad, let me clarify. I’m talking about holding the the computed

WindowSizeClass

(in the guide you linked) globally. The use case is to access the

WindowSizeClass

in

AbstractComposeView

as well as pure

Composable

screens without passing them from the Activity directly (or a few

Fragments

down).

Right, my question is more what are you going to do with the size class from within the view :) The guidance is to convert the size class into something more semantically meaningful, such as whether to have a nav bar or nav rail, and pass this information down at the top level instead of passing down the window size class

Oh, we’re going to use the size class to set different horizontal paddings.

there is no guarantee that the sub section (view in this case) has the same size as the window

Right but in this case, I’m trying to match horizontal paddings of existing Android Views that specify it for

w1024dp-land

and

w1280dp

. I could just use

dimenResource

but at the same time, I wanted to see if there was a Compose-only solution.

Well if you wanted to match behaviour the compose only solution would probably be providing a padding object that contains the different paddings in a composition local, and you could calculate and provide this at the activity level where you calculate size class