I'm reading the android docs on custom component development and i'm a little confused. If you're creating an activity, you can add add a hierarchy of views via setContent. however, if you're creating a custom component, you have to handle everything in the draw() overload.
if i want to build a custom component that relies on a view hierarchy, is the model simply to create a hierarchy internally and then in draw call myViewHierarchy.Draw() or something?
however, if you're creating a custom component, you have to handle everything in the draw() overload.
Not necessarily. That's one approach, but hardly the only one.
if i want to build a custom component that relies on a view hierarchy, is the model simply to create a hierarchy internally and then in draw call myViewHierarchy.Draw() or something?
No. Just add children to a container, then add logic to the container for representing the composite widget. For example, I have a ColorMixer custom component that combines three SeekBars, three TextViews (labels for the SeekBars), and a plain View (used to provide a color swatch).
Related
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 am new to android and trying to make something like the fingerlock security system of the android. The problem is that I have found a lot of reference on drawing onto a plain background (that sets different content view and allows drawing onto that), but not regarding drawing onto the same activity layout.
To draw manually on a View, you need to override its onDraw method. For this you need a custom View (often extending from an existing View type).
If you are using an xml to set the Activity's layout in setContentView() then you need to add the above custom view to this xml. Then, you can draw onto the same activity layout.
setContentView is noting but the activity view. once the view is set in main activity (max in oncreate method) it can update from multiple classes according to your logics.. i think before trying this you have to understand the view and its hierarchic properties properly
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
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."
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.