Even if it's possible, is it best practice? Or should I always use ViewGroup (or one of its subclasses) as the base class for custom components that will contain other ui components?
Possible to nest Android views?
Not really.
Or should I always use ViewGroup (or one of its subclasses) as the base class for custom components that will contain other ui components?
By definition, a ViewGroup is the type of View you use to hold other Views.
In theory, you could completely rewrite ViewGroup yourself, if you really wanted.
Related
With android, is there a performance difference with having lots of views vs having viewgroups with childen?
From what I've read it seems that lots of views is bad for performance in general, and I was wondering if Viewgroups were a way around that
Short answer, no. A ViewGroup is a View and is the parent class to Android's various Layout type views. http://developer.android.com/reference/android/view/ViewGroup.html
So, a ViewGroup is not a way around having a lot of views.
In general, you want to make your layouts as clean & efficient as possible using the fewest amount of view you need to implement your UI.
It may benefit you to read the Android documentation about optimizing layout hierarchies:
http://developer.android.com/training/improving-layouts/optimizing-layout.html
If I am not wrong, View is the superclass for all widgets, but how do I differentiate between a View and a widget? For example, a button or a text box, what should I call them (a View or a widget)?
Calling them either is fine.
I tend to use the term "widget" for subclasses of View that have a visual representation to the user by default -- things like TextView, Button, ListView, etc.
I tend to use the term "view" for something that could be any subclass of View, including pure containers like LinearLayout.
But, again, there is no particular harm in referring to them by either term.
A view is the basic building block for UI components. Think of a View as a rectangle on the screen that can draw itself and handle events.(1)
So, there is no implicit "semantic" associated with a View. You can essentially implement anything that appears on the screen and interacts with the user.
Now, a widget is what you typically think about as a "control" through which the user interacts with your application. A button, a spinner and a checkbox are all good examples of "widgets". However, this is not a "hard" definition and there is no such thing as a Widget class on Android. The fact that something is a "widget" merely means the class is in the android.widgets package for organizational purposes, but it is, in fact, a View.
For example, a Button's base class is View, not something like android.widgets.Widget (which does not exist).
(1) http://developer.android.com/reference/android/view/View.html
See also:
http://developer.android.com/reference/android/view/package-summary.html
http://developer.android.com/reference/android/widget/package-summary.html
As is elegantly stated in the View class docs:
This class represents the basic building block for user interface
components. A View occupies a rectangular area on the screen and is
responsible for drawing and event handling. View is the base class for
widgets, which are used to create interactive UI components (buttons,
text fields, etc.). The ViewGroup subclass is the base class for
layouts, which are invisible containers that hold other Views (or
other ViewGroups) and define their layout properties.
Therefore a View is a base class for IU elements and a Widget is loosely defined as any ready to use View. In particular though:
View:
A View is a base class for all UI elements. It therefore covers many different classes and concepts, including Widgets, ViewGroups and Layouts. There is a root View attached to a Window instance which forms the basis of the View hierarchy. In general, the word View is usually used to describe UI elements in general, or to refer to abstract or base UI classes such as ViewGroups.
Widget:
There are various definitions for this term, but most refer to a 'ready to use' UI element, be it a Button, ImageView, EditText, etc. Note that some people consider Widgets to be UI elements that are complete (not abstract) and are not containers (such as ViewGroups (Layouts/ListViews). It's also worth noting that Widget is a package name (android.widget) where the docs mention the following:
The widget package contains (mostly visual) UI elements to use on your
Application screen.
Therefore it is reasonable to consider non visual UI elements to also be Widgets, as well as any class defined under the widget package. See here for a full list of classes in the widget package: http://developer.android.com/reference/android/widget/package-summary.html
App Widget:
Not to be confused with a UI element widget, an App Widget is a remote View hierarchy which is most commonly displayed on the user's home screen. As defined by the docs:
App Widgets are miniature application views that can be embedded in
other applications (such as the Home screen) and receive periodic
updates. These views are referred to as Widgets in the user interface,
and you can publish one with an App Widget provider. An application
component that is able to hold other App Widgets is called an App
Widget host.
ViewGroup:
A ViewGroup is a subclass of View and provides the ability to parent and position child Views such as in the case of Layouts.
Layout/View Containers:
Much as with Widgets, there is no Layout base class and it is therefore could be loosely defined as any class which extends ViewGroup and provides the ability to define the positioning of child Views within it. Usually only ViewGroup subclasses which are appended with the world Layout (as in LinearLayout, RelativeLayout) are referred to as Layouts, other classes extending ViewGroup are usually just referred to as View Containers.
Finally, I'd like to suggest that whenever you mention Views, Widgets or any other important term, to make clear your intended definition so that people can better understand what you're referring to.
For further reading:
what is the difference between views and widgets
difference between view and widget
Think of view as something like a huge container that contains anything which occupies a rectangular area on screen and handles drawing and event handling.
While widgets are a set of Pre-built views that can be used to construct a user interface ,e.g buttons,Checkbox,EditText. Widgets are a subset of views.
widgets are the views which resides (shown to user) outside the app, to perform the specific functions (launching the main app itself or providing a feature of the app itself) without needing to launch the app instead.e.g a clock widget shows you the time without launching the Alarm or Time application.
A more precise definition can be found at :Definition of widgets
In Android ViewGroup inherits from View. A ViewGroup is a container which holds Views.
ViewGroup (LinearLayout)
View (TextView)
Why did folks at Android defined this relationship as Inheritance instead of composition. As the ViewGroup contains Views shouldn't it be composition ?
I think you're getting too hung up on the wording.
A "ViewGroup" has every bit as much reason to inherit from a "View" as a "TextView", and "ImageView" or ... more to the point ... a "ScrollView" or a "SurfaceView" (the latter two both "contain things").
Perhaps "View" wasn't necessarily the best choice of terms ... but the class heirarchy makes complete sense. Regardless of what it's subclasses are named :)
IMHO ...
I think this is a great example of the Composite design pattern:
http://en.wikipedia.org/wiki/Composite_pattern
Even though the naming might not be the best...
Reading the official doc is the golden rule.
A ViewGroup is a special view that can contain other views (called children.) The view group is the base class for layouts and views containers. This class also defines the ViewGroup.LayoutParams class which serves as the base class for layouts parameters.
If you still do not find out what it is, search with Google image:
A ViewGroup is a (subclass of) View because it can serve as a view in important ways:
It can be an element in a layout XML file
It can be displayed on the screen (by displaying its child views, its own background color, etc.)
It gets inflated along with the rest of the view hierarchy
It can serve as an activity's content view (via setContentView())
So it really is a View.
I agree that the classname ViewGroup is a bit confusing, because it sounds like it's a group, not a view. Calling it ViewGroupView might have been more logical, if unwieldy.
Why did folks at Android define this relationship as Inheritance instead of composition? As the ViewGroup contains Views shouldn't it be composition?
In a case like this, inheritance and composition are not mutually exclusive. A ViewGroup is a View (inheritance) and a ViewGroup can contain Views (composition).
Viewgroup inherits properties of views and does more with other views and viewgroup
A ViewGroup is a special view that can contain other views.
- The view group is the base class for layouts and views containers
- For example, RelativeLayout is the ViewGroup that contains TextView(View), and other Layouts also.
refer link for info:
https://developer.android.com/reference/android/view/ViewGroup.html
A View represents the basic building block for user interface components
-It occupies rectangle on the screen and is responsible for drawing and handling events.
- Examples are EditText, Button, TextView etc
refer link for info:
https://developer.android.com/reference/android/view/View.html
All UI elements in an
Android app are built using View
and ViewGroup objects.
View :- A View is an object that draws
something on the screen that the
user can interact with.
ViewGroup :- ViewGroup is used to hold Views
and ViewGroups.
This seems to be a common question yet documentation is very hard to find. I'm looking for examples that show me how to create my own view group (preferably by extending an already existing one) and then add views programmaticly.
Thanks.
ViewGroup
ViewGroup is abstract, and its onLayout is abstract too. So you need to provide an implementation for onLayout where you do assign a position at every child (View) of the viewgroup.
I have a compound UI component built up from a ViewGroup containing a number of TextView, ImageView etc. components. Many of these have StateListDrawables as their images/backgrounds. Is there any way of making them select from this drawable based on the state of the parent ViewGroup rather than the component itself? Ideally I want to be able to change the visual state of all children of the ViewGroup (text colour, image etc) based on the state of the ViewGroup, preferably without having to hook up complex logical code. This seems like a fairly common sort of requirement, so I was hoping it would be straightforward in Android - am I going to be disappointed? :)
No disappointment, just set android:duplicateParentState="true" in the layout file to enable what you want. You have to do that for each child View you want to have this functionality enabled on.