Why is a control called a "View"?
USMember ✭
I'm a Xamarin newbie. I am trying to understand the nomenclature.
In GUI toolkits, a visual element (AKA "widget") is called a "control". A button, textbox, label, etc. In Xamarin.Forms, such a thing is called a View.
Why? Why not call it a Control? It violates the "Principle of Least Surprise". When I read about a View I automatically think of the page/screen/whatever, and it takes a while to realise I'm actually dealing with a control.
This creates inconsistencies. When talking of a "view", most think of an MVC/MVVM/etc. View - i.e. the collection of ALL visual elements for that page. There is also a thing called a "ViewModel". And so on. This poor naming choice totally confuses things.
Is there a reason for this which I haven't understood?
(My recommendation, if API writers are reading this, and if I did not misunderstand any of it (because I'm still a Xamarin newbie), is to add an alias class called Control which is equivalent to View, i.e. an empty subclass: public class Control : View { }, and so on public class FooControl : FooView { }, etc.)
Best Answer
-
RobertDurfee
USMember ✭✭
It's probably because in iOS all of the UI elements are derived from UIView.
1
Answers
It's probably because in iOS all of the UI elements are derived from UIView.
Like @RobertDurfee said, in iOS the base class is UIView, and in Android the base class is View, so calling them View in XF is consistent with native conventions.
If it makes you feel better, they do call the native view a Control in renderers.
Interesting... So it's a legacy problem!
Still, XF could have made a clean break, as it has in other areas.
Hopefully they'll do something about it at some point.
I doubt it. You're the first person to say anything about it, so it doesn't seem to be a widespread complaint.
Well, changing course starts with one man. Speaking of which, you should watch yourself there's a ship coming your way...