Changing displayed state of Views based on a parent ViewGroup's state - android

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.

Related

Is it possible to enable touch events for a View inside a ViewGroup but outside its bounds?

I'm currently trying to design a ViewGroup (specifically a subclass of FrameLayout) that can layout any number of subviews and enable them for drag/drop outside the layout group. It's almost identical to a LinearLayout:
Curently I am able to drag the views outside the ViewGroup and draw them, however after letting go of the view it can't be re-selected and further dragged around.
I'm wondering if there is a way to do this in a way that isolates the logic to the Layout subclass and doesn't involve needing to do much/any extra stuff in consuming fragments/view groups.
I've tried overriding getHitRect(Rect) in my FrameLayout subclass but it never seems to be called. dispatchTouchEvent(MotionEvent) is of course not called either, presumably because the parent ViewGroup has decided not to deliver the touch to it because it was outside the bounds. I've tried implementing a TouchDelegate as well, but I think that needs to be set on the parent view, which means needing to know about this and doing this additional step when using this Layout.
Any ideas on if/how this is possible? On iOS it can be implemented fairly easily by overriding hitTest: to take into account the frames of the child views. Is there a similar method like this on Android?
Your help is greatly appreciated!
Without any code it is very hard to see what you are doing, but best guess would be that each view should a child view of the relative layout.

What is the difference between Views and widgets?

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

Which is the lightest view?

In Android, Which is the light weight view ?
ex:- View, Textview, Edittext, etc....
In some case we need to use a view to fill the area without showing the view to the user.
At the same time the screen should load fast.
You can use Space.
android.widget.Space
Space is a lightweight View subclass that may be used to create gaps between components in general purpose layouts.
If by "lightweight" you meant memory footprint, then there is none exists on Android, because each view have to derive from View, which itself is a massive object (well, not massive, it is about 8kB), so it's not that big.
But in terms of measure, layout and draw time the basic View performs well. You just have to set its visibility to INVISIBLE. And so it will be measured and put into the layout (contrary to GONE with which the view would not take up any space).
Unfortunately ViewStub is not meant to be used for this purpose. Its default visibility is GONE.
If you are really picky, then you can extend View and override methods like draw() (to do nothing, do not even call super), dispatchDraw(), setVillNotDraw(true), etc. (Take ViewStub as a sample).
You should have a look at ViewStub.
Use ViewStub if it is sufficient or LinearLayout which may be somewhat light weight.

What is the difference between a View and widget in Android?

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."

Effective way to handle redundant UI elements in Android?

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.

Categories

Resources