What is the difference between a View and widget in Android?
As is 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 UI elements and a Widget is loosely defined as any ready to use View.
Let's emphasize these concepts a little more.
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, therefore it 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 word "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 it clear your intended definition so that people can better understand what you're referring to.
Further Reading
What is the difference between Views and widgets?
A Widget is a View. A Layout is a ViewGroup. To create a widget, you extend a View.
Widget is package in Android which contain all user interfaces such button, textView and layout,etc. but view is an abstract class which includes properties, focus and event handling method ,rendering ,etc
But all widgets extends the view for getting UI with it behavior such as properties, focus, etc.Thus all widgets are examples of view, but view is not the same as a widget. A View-group acts as container which contains different views examples are the frame-layout, relative-layout. They extend the view group and have as purpose as acting like a container which adds specific behavior to all the views it contains.
I don't believe any of the earlier answers are really correct. Different UI toolkits use different terminology for what is often essentially the same thing, and it is true that an Android View is pretty similar to a .NET Control or a Qt widget.
But "widget" also means something very specific in Android. If you long press on the home screen, you get an "Add to home screen" dialog that offers to add Widgets (among other things). If you touch the Widgets line, you get a menu of widgets like Analog Clock 1 through 4.
According to developer.android.com/guide/topics/appwidgets, these are special entities that lets your process display content in another process's View. Like the home screen. There is a special broadcast protocol that you inherit for free, but you also interact with the Views in your developer.android.com/reference/android/widget/RemoteViews.html host via a special protocol that appears to involve marshaling. I have just started to look into writing one (which is how I found this question) but the docs do say that you can only use FrameLayout, LinearLayout, and RelativeLayout layouts, and that they can only contain AnalogClock, Button, Chronometer, ImageButton, ImageView, ProgressBar',TextView, andViewFlipper` "widget classes" - "Descendants of these classes are not supported."
This is just a bit restrictive!
Lets come to the clear differences, without gigantic description..
A view is an object, can be put in layout or in pages. It is the
basic building block for user interface components (you can refer
these components as widget).
Widgets are small scale views(like button view, check box etc), that can be embedded in other views(like Home screen, login screen
etc).
Now you can think like , view is a container or place holder and widget is independent controls that you can place in any view.
But keep in mind these are more like design concepts, not hardcore definitions.
Finally, it can be concluded like,
An independent view, ready to use in any other views as an UI elements, can be referred as widget.
For more explanation, have a look on basic code below:
<!doctype html>
<head>
<title>New jQuery UI Widget by souro</title>
<link rel="stylesheet" href="http://code.jquery.com/ui/1.10.4/themes/smoothness/jquery-ui.css">
<script src="http://code.jquery.com/jquery-1.10.2.js"></script>
<script src="http://code.jquery.com/ui/1.10.4/jquery-ui.js"></script>
<script>
$(function() {
$.widget("iP.myButton", {
_create: function() {
this._button = $("<button>");
this._button.text("My first Widget Button");
this._button.width(this.options.width)
this._button.css("background-color", this.options.color);
this._button.css("position", "absolute");
this._button.css("left", "100px");
$(this.element).append(this._button);
},
});
$("#button1").myButton();
});
</script>
</head>
<body>
<div id="button1"></div>
</body>
</html>
Now you can see myButton is a small scale independent view i.e., widget and it is getting placed in a container button1 i.e, view, and yes you can put this widget in any other view i.e., purpose of widget. Make sense i guess.
Views are concerned with layouts, placeholders.
Widgets are concerned with data, UI behaviors (ex Sliders). Views contain widgets.
I had your same confusion about it, above all for the two packages android.view and android.widget. I ended up thinking of widgets as "ready to use" views, and views as just elements to build widgets. If I make a custom view that will be directly used in a layout, I would consider that a widget.
Just some quotation from "The Busy Coder's Guide to Android Development", Ch 6:
All widgets, including the ones shown
above, extend View, and as such give
all widgets an array of useful
properties and methods beyond those
already described.
view is super class of widget so that a widget is a kind of view. In "pro android 4",the author take them as the same thing.
"View,widget,control Each of these represents a UI element.Examples include a button,a grid,a list,a window,a dialog box,and so on.The terms view,widget,and control are used interchangeably in this chapter."
Related
I read this here:
Android provides a number of ready-made views that you can use to
design and organize your layout. "Widgets" are views that provide a
visual (and interactive) elements for the screen, such as a button,
text field, checkbox, or just an image. "Layouts" are views derived
from ViewGroup that provide a unique layout model for its child views,
such as a linear layout, a grid layout, or relative layout. You can
also subclass the View and ViewGroup classes (or existing subclasses)
to create your own widgets and layouts and apply them to your activity
layout.
If I am not wrong, this means people can even design their own widgets and layouts? Does that ever happen? Any examples?
this means people can even design their own widgets and layouts?
Yes.
Does that ever happen?
Yes.
Any examples?
There are hundreds of examples out on the Android Arsenal alone. Just looking at a couple of columns of the recent items, there are the following custom widgets and containers:
material-drawer
Material Design Android Library
StarBar
AndroidProgressLayout
DiscreteSeekBar
Android-SingleInputForm
SunDate Picker
I'm following the examples in a recent book (Learn OpenGL ES For Mobile Game and Graphics Development) and the suggestion made there is to programmatically add a new layout (let's call it settingsLayout) in the main activity and then:
LayoutInflater settingsInflater = (LayoutInflater) getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View settingsLayoutView = settingsInflater.inflate(R.layout.mySettingsLayout,settingsLayout,false);
settingsLayout.addView(settingsLayoutView);
addContentView(settingsLayout,settingsLayoutParams);
This works fine, but I've added it to the callback for one of my action bar menu items, and I'd like to be able to remove this view when the back button is used. So far, that is causing me a lot of headache.
Meanwhile, it seems that the most natural way to implement dynamic views (addable to backstack, etc) is through Fragments. However, fragments need to belong to a layout, and currently my code assigns the GLSurfaceView directly as the content view for my main activity, without using a layout at all. Since GLSurfaceView is a subclass of View (and not View Group), I cannot use it to spawn children such as fragments.
The author of the book claims that this approach is "sleek", but doesn't give any other reason for assigning the GLSurfaceView directly as the content view. Is there a performance issue to be aware of? Or is it just as "sleek" to make a "master" layout to which both my GLSurfaceView and subsequently spawned views belong?
Is there some other even more natural way to get buttons, text boxes, etc. to dynamically appear and disappear on top of my GLSurfaceView?
I'm not sure what your specific performance concern is -- rendering the View objects, or rendering GL? Nothing you do is going to affect the performance of the GL rendering (except perhaps changing the size of the window).
SurfaceView and GLSurfaceView provide a transparent "place holder" in the View hierarchy that other elements use when computing the layout, but the actual pixels are drawn on a separate layer. This is why the SurfaceView is either behind all View elements or in front of them all -- the layer is passed to the system compositor (SurfaceFlinger), which takes care of generating the final display image.
I typically organize my code/logic by a fragment represent one layout. Now I am in need of few relatively simple forms to get input data from user, which are somewhat related in purpose.
Say I hav 3 screens, and I could create 3 fragments to handle them (display view, read input, submit, ..). Or should I use one fragment, and use FrameLayout create a stack of layouts. I was thinking like, stacking all 3 views and hide/display the view I like. But the documentation say
Generally, FrameLayout should be used to hold a single child view,
because it can be difficult to organize child views in a way that's
scalable to different screen sizes without the children overlapping
each other
Any good way to do this or should I create multiple fragments for this (the down side of this is lot of small classes and repeated code. I may use a base class, still like to explore other options)
Thanks.
It sounds like you don't really care that much if the views overlap each other in the FrameLayout, or in fact they are supposed to overlap because you expect to be showing only one at a time. FrameLayout can certainly display stacked child views that each take up its full width and height just fine, and if you set the visibility of the unused views to INVISIBLE or GONE, they will not intercept screen presses or take focus if they happen to be located above the visible view the user is interacting with.
On the point of readability and code maintenance, I think swapping fragments makes more sense though, even if there is more memory overhead. The layout management can be encapsulated within the individual fragments, and you do not need to worry about showing/hiding views, as fragment transactions will take care of that aspect.
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
I have numerous activites in my Android app., and most should contain the same, relatively complex set of UI widgets on the screen's top area (lets say that its a kind of toolbar that you can find on most screens).
Right now, every screen's layout contains the markup for this toolbar, along with its logic inside every Activity's source, so it's damn redundant. Could you recommend a more efficient / less redunant way to do this?
I would take advantage of the <include> tag in the layout's xml. This will let you reuse that toolbar very easily and effectively. As for the code I would subclass Activity and place the logic in there, then each of you activities can subclass your custom Activity class.
There are 3 very useful articles on the dev site about this topic. Here is the first one link
I would create a custom View object (subclass View) and then include it in all of your layout xml. You can actually pass parameters, etc. just like built in views. Then define XML for that view that will always be used when that view is drawn on the screen. Also, this allows you to change the view and have that change populated across all of your Activities without having to manually modify all of the code.