I guess this is more of a question for @simonbs but if anyone else knows the answer, please let me know.
Is it possible to determine what size the widget is? Say for example I use the same widget script in the 3 different sizes, is there some way I can find out if it is 1x1 size, 2x1 size or 2x2 size for example? This way my script could show/hide information based on that and essentially be “responsive” to use a web term.
You can get the size of a widget using
Thanks guys, I must have missed that one.
Just piggybacking off this. @simonbs any chance that the ListWidget might gain width/height values that we can query?
I’ll consider it. This one’s tricky though. I only know the exact size of the widget when it’s running in the widget. When you’re previewing in the app, I already use hardcoded values and I’d prefer not to rely too heavily on those. If I start exposing them as an API, there’s no going back
+1 for some kind of mechanism to get the size (height/width) of a widget.
There’s quite a range of size possibilities, as documented by Apple here: https://developer.apple.com/design/human-interface-guidelines/ios/system-capabilities/widgets/#adapting-to-different-screen-sizes. And I doubt that covers all of the possibilities, either.
Here’s an example where having size details would make a difference. The weather widget that a lot of folks have been sharing around and customizing uses hard-coded size values. It also doesn’t calculate an even distribution of data points for the graph, if you change the number of points. Because, once you’re hard-coding the width of the widget, why not hard-code the spacing between them, too. Which is a shame, because once you have width and number of points, that’s pretty simple math. Even I can do it.
Maybe we can’t have exact pixels directly, but surely there’s an heuristic that could be calculated based on screen size, zoom settings, and other factors that influence the size a widget is ultimately rendered at? Even a “predicted size” would be more useful than needing to hard-code widths into the widget code itself. It might not cover every case, but it would cover more cases than are covered today.
I pulled together this, which is far from perfect, but it gave me pretty good results. I figure I know the icon size (60 px), and I can find the screen width. Using this I can compute the padding between icons.
Small = 120 + padding, 120+ padding
Medium = 240 + padding * 3, 120 + padding
Large = 240 + padding * 3, 240 + padding * 3
I’ve only tested this on my iPhone X, so I’m sure there are other cases where this will fail.
deviceScreen = Device.screenSize()
let padding = ((deviceScreen.width - 240) /5)
let widgetSize = new Size(padding + 120, padding + 120)
In creating my transparent widget code, I needed to know the exact sizes of widgets at every possible iPhone screen size.
If you follow that link, the
phones array at the bottom of the script tells you all of the sizes (and positions) of widgets on every iPhone. You can programmatically determine the pixel height of the phone screen – which is a unique value for every distinct iPhone screen size/type!
Once you do, you can use the height as an object key (
phones[height]). Then, the
small value is the width and height of small widgets;
medium is the width of medium widgets, and
large is the height of large widgets.
So on an iPhone 11 Pro Max (screen height = 2688) the medium widget is 1080 by 507.
Related to this @simonbs maybe you might want to consider allowing the developer to restrict the size of the widget? If my widget is only meant for small, maybe it doesn’t appear in the dropdown for medium/large widgets?