<@U031981JNPK> I am working on creating widgets fo...

# glance

[Rohan Gupta Kandikonda]

@Marcel Pinto I am working on creating widgets for 2x1, 3x2, 4x2 and 5x2 sizes. Could you throw some light on how these map to the Dp sizes in the devices. Since every device has a different size and grid layout, how does Glance handle it ? What are the developers supposed to do to map them correctly ? (Sample code has hardcoded values)

[Marcel Pinto]

This might help https://developer.android.com/develop/ui/views/appwidgets/layouts#anatomy_determining_size

[tony-choi]

As far as I know, there is no way to obtain information about the grid size because each appwidget host has a different grid size....

[Summers Pittman]

Just repeating Marcel's point, feel free to reach out to me.

Two quick parts: First, you probably shouldn't be thinking in terms of grid snaps, this is an implementation detail of the launcher. It is possible for a user to set their launcher to a 2x2 homescreen grid size, and this would cause a 1x1 widget to be the same screen size as a 2x2 widget on a 5x4 home screen.

Take a look at sizemode.exact (https://developer.android.com/jetpack/compose/glance/build-ui#sizemode.exact). This exposes the actual dp rendering size your widget is rendering to.

You may also get some developer joy from https://developer.android.com/jetpack/compose/glance/build-ui#sizemode-responsive, but that is usually more complicated to implement and less flexible than size mode exact.

Second, I'll run your comment by the glance eng teams to see if I said something insane/wrong.

[bbade_]

Different launchers will have different grid sizes. There's also no concept of grid at the OS level, the most basic information needed to lay out an appwidget is a rectangle of arbitrary size.

I'd recommend approximating common grid sizes using dp, then build your code to be responsive

When writing widgets that need to respond to a variety of sizes I sometimes will get designs that have several breakpoints based on height or width. In these cases, it can be helpful to create a composition local that provides an enum representing what sort of width bucket you're rending. In this case i set size mode to be exact, then write something the following.

enum class WidthBucket(max: Dp) {S(50.dp), M150.pd, L(300.dp)}

@Composable fun determineWidthBucket(): WidthBucket { /* calculation based on LocalSize */ }

val LocalWidthBucket = /* composition local*/

Then in my ui code, i can have arbitrary elements check the size bucket and render appropriately.

[bbade_]

We're aware that designing for a lot of different possible grid and widget sizes can be a challenge, and improving developer experience in that area is something we'd like to do

[Rohan Gupta Kandikonda]

Thanks for your suggestions !

[pavi2410]

SizeMode.Exact has worked better for my use case

[Rohan Gupta Kandikonda]

But, isn't size mode exact more resource consuming, since in the documentation it is mentioned that it will reload the UI again and again unlike the responsive one where UI is loaded once and then rendered always.

[bbade_]

It will reload the UI when the user resizes the widget, but unless you expect the user to resize the widget many times a day, you're not going to have any issue. Iirc, responsive needs to store more sizes in memory, so it also comes with a cost

[Rohan Gupta Kandikonda]

I have used common DP sizes for 2x1, 3x2, 4x2 and 5x2. But in one device, I can see all sizes but in the other, I am unable to view that, I could view only 3 sizes.