display_length size constants don't reflect actual screens

[alice-mkh]

* xsmall - Very small screens, as used in watches, wearables and other small-display devices (about <= 360px).
* small - Small screens often used in handheld devices, such as phone screens, small phablets (about < 768px).
* medium - Screens in laptops, tablets (about >= 768px)
* large - Bigger computer monitors (about >= 1024px)
* xlarge - Television screens, large projected images (about >= 3840px)

There are a few problems here:

• The small size is meant to be used on phones, yet all the available phones have 360px and so fall into xsmall
• Meanwhile, xsmall doesn't constrain the minimum screen size
• Together this means there's no constant that can work for devices like L5 or PinePhone - small means the app cannot run on it, xsmall means the app can run on even smaller screens which is not really the case
• medium is means for laptops while large for bigger computer monitors - the most common laptop resolutions are 1366x768 (mostly low-end), 1920x1080, and there's also 2160x1440@2 which means 1280x720. So laptop sizes can be 720px, 1080px - the former falls into small, the latter falls into large - so the medium description is misleading
• All values correspond to the smallest screen sides, but xlarge corresponds to the largest screen side. 4K screens are 3840x2160 - the value there is 2160px so they are still considered large, so xlarge only corresponds to 8K screens.

CC @bertob

[bertob]

FWIW this is why I always thought the named values were a bad idea. At the end of the day what matters are the actual logical pixel values apps can scale to. This just obscures that, making it easier to get it wrong.

Even if we e.g. change the small constant to mean "360 or more" now it may become a problem again in the future when new devices come out that don't neatly fit into these categories...

[bertob]

On a practical level, what are our options here?

Can we deprecate/remove the named values altogether? If so, that'd be the best path forward IMO.

If that's not an option, can we add/remove/change the meaning of the various values? If so, to what degree?

[ximion]

We can't remove the named values, but we can always change what they mean, as that is exactly their intended purpose (for apps which are fully adaptive and really don't care all that much about explicit sizes, because specifying an absolute size means the app will not show up on a phone that is just a bit too small or a bit too large).
xsmall doesn't have a minimum size the same way that xlarge doesn't have a maximum size, simply because it basically means "smallest/largest screens we know of".
I'd happily accept a patch for better descriptions and/or rough size recommendations.

[alice-mkh]

apps which are fully adaptive and really don't care all that much about explicit sizes

That doesn't exist, sorry. Apps are optimized for a very specific minimum width. If you give them smaller width, they will break. Or rather, they won't fit into the screen.

[ximion]

This markup mimics prior art from Android, which also allows both: https://developer.android.com/guide/topics/manifest/supports-screens-element (Android also scales apps up if they don't fit into large screens, which is of course not desirable for most).
Most normal desktop apps don't really care about the screen size they run on, as long as it's not as small as a phone (the line gets blurred with tablets that have sufficient screen sizes, but to get sorted out from software centers there, we have the controls property where apps can indicate touch support).
As said, if you think the text mnemonics should be defined better or even precisely mean one specific value, I welcome a patch.

[alice-mkh]

Except a few releases later they found out that this system doesn't work, because large was phones, xlarge was 10" tablets and they wanted to do a 7" tablet (Nexus 7). So they started using dp values instead (sw600dp for 7", sw720dp for 10"). Namely, the android:requiresSmallestWidthDp right under, as well as for resources.

As said, if you think the text mnemonics should be defined better or even precisely mean one specific value, I welcome a patch.

I think they should be deprecated to be completely honest. Or rather that they shouldn't have existed in the first place but that ship has sailed.

[ximion]

Yeah, after giving this some more thought, I think deprecating the text representations for now is the most straightforward, simplest way that won't cause too many issues in the long run (as long as app developers update their metadata, which I assume they do).
It may be worth to include some minimal logical pixel sizes for common phones / tablets in the specification for reference, but trying to keep up with what is a "small" screen will likely not work well in the long run and cause more edge-case conflicts than what it's worth.

[JakobDev]

Just my 2 cents: I would like to have a Way to say that a App needs a screen class without using a fixed size. e.g. you have a IDE that have sidebars, terminal, editor etc. on the screen. It would be good to just say, this App recommend large screen. On the other Hand, it's good to say that a App which has not many Things that are on the Screeen at the same time, work on every Laptop/PC screen size (not on mobile) without figuring out the exact resolution.