Replies: 4 comments
-
There is also |
Beta Was this translation helpful? Give feedback.
-
We had it as an enum before, but they changed it so it would be easier to extend. xamarin/Xamarin.Forms#658 |
Beta Was this translation helpful? Give feedback.
-
The On platform list is actually something that indeed should stay... the On device type thing is not what I would keep, as long as it makes false promises in certain scenario's. |
Beta Was this translation helpful? Give feedback.
-
I agree, there are not really any reasons to keep it, as you said there are better solutions to use. |
Beta Was this translation helpful? Give feedback.
-
Summary
Currently the OnIdiom feature in Xamarin Forms will offer a false promise in some scenario's.
On UWP you will get Tablet if the user interaction is set to Touch otherwise it will be Desktop.
maui/System.Maui.Platform.UAP/Forms.cs
Line 60 in 95bef27
On Android you sometimes get Phone for Tablet devices.
I as a dev would rather rely on screen measurements and use Visual State Manager to change the layout of my app to enable a better experience on a small ( mobile ) screen versus a large ( TV ) screen.
Also I would rather know if phone capabilities were available than rely on the Phone OnIdiom. Could be a Tablet has a sim to make Phone calls and if I would have a device capability API, I could query that and add extra features in my UI that would only be lighted up if these capabilities are available.
UWP had a great way of handling this when Windows Phone merged from WP to UWP development and one framework to target multi devices.
Beta Was this translation helpful? Give feedback.
All reactions