IssueTracker

Hey, thanks for the feedback! There's a couple of things we're working on at the moment to try and help this out, both to reduce the amount of code required to implement common designs, and to provide a better Kotlin API.

We've recently released the first alpha of glance-wear-tiles, which allows you to build Wear Tiles in a Jetpack Compose-like API (as you alluded to in your message :) ). We're still in the early days, but it'd be great to get some initial feedback there.

We're also building up a Material component library for Tiles (androidx.wear.tiles:tiles-material), and just released the first alpha version yesterday. It's still using Builders throughout, but it aims to provide consistent Wear Material components for Tiles, so should also reduce some of the code needed to build up Tiles.

It's still very early days on both projects, but it'd be great to get initial feedback on these projects too!

Awesome! I'm excited to try it out :) thanks for your work!

So Glance will also work for normal appwidgets? That's even more awesome!

In general, yes. That said there's a few caveats:

• Using any of the target-specific Composables (e.g. androidx.glance.wear.tiles.curved.CurvedRow) will not work on other targets (your app will compile still, but it won't render).
• If you're just using the base set (e.g. the ones in androidx.glance), then the same code will work on both Tiles and Appwidgets, but you'll still need to test on both and tweak the layout so it renders well on both targets.

Thanks for the feedback, Jolan! Please try out Tiles Material (there's a new codelab out, you'll have to use the 1.1.0 rc) and open a new ticket to give us feedback about the API.

The underlying structure is the same as the OG Jetpack Tiles API, but it should be a lot easier to build Material-friendly layouts with the new one, and hopefully a lot less boilerplate.

(Glance: Tiles is still in development but it's still in alpha.)

Will close this ticket off. (I chose "fixed (verified)" as it's a feedback issue and the other statuses apply less.)

+1 for the DropdownMenu/DropdownMenuContent fork. It looks like the primary limiter to this is .width(IntrinsicSize.Max) on the Column in DropdownMenuContent. Removing the intrinsic max size and then using heightIn/widthIn modifier params on the LazyColumn seems to be working pretty well with some light testing right now.

Hi, any updates on this?

https://stackoverflow.com/a/77472088/4931857

Until this is properly supported, hard code the lazy column's height and width. If filteration is to be done then make the height dynamic based on single item's height and size of the list.

val sizeOfOneItem by remember {
        mutableStateOf(50.dp) //assuming height of one menu item 50dp
    }
    val configuration = LocalConfiguration.current
    val screenHeight50 by remember {
        val screenHeight = configuration.screenHeightDp.dp
        mutableStateOf(screenHeight / 2) //assuming the drop down menu anchor is in middle of the screen. This is the maximum height that popup menu can take.
    }
    val height by remember(options.size) {
        val itemsSize = sizeOfOneItem * options.size
        mutableStateOf(minOf(itemsSize, screenHeight50))
    }
    ExposedDropdownMenu(
        expanded = expanded,
        onDismissRequest = {
            expanded = false
        }
    ) {
        LazyColumn(
            modifier = Modifier
                .width(500.dp)
                .height(height)
        ) {
            items(options) { option ->
                DropdownMenuItem(
                    onClick = {},
                    text = {
                        Text(text = option.label)
                    }
                )
            }
        }