41

I looked at http://developer.android.com/reference/android/view/View.html to figure out the differences but could not understand much. I only partly understood the "selected" state.

Can somebody explain the differences with some solid examples? I hope my question is not very vague. If it is, it would be great if somebody can help me improve it because I don't know how to ask it more clearly.

Thank you in advance.

2 Answers 2

45

Enabled -> User Interaction possible.

Disabled -> User interaction not possible.

  • if you hover the mouse over a widget, it is focussed
  • If you make a press-down (half click) on that widget, it is pressed
  • If you press-down and press-up while the mouse is at the same position, it is selected
Sign up to request clarification or add additional context in comments.

Thanks for the clarification! I am still not clear about focussed though: How does the focussed state work in touchscreen? Is it something like: While I am moving my finger across the screen and whereever my finger is at any specific instant, that part of the screen has focus?
But with touch input, you usually only need to take care about the selected state, right? @EnginYapici I think a text field is focused when it waits for input.
with touch input you need to take care of pressed and selected states. if the touch-down happens inside a widget and touch up happens outside the widget, it is not considered to be selected.
Actually focussed does apply to the touch interface too. If you have multiple semi-transparent views overlapping on the screen (e.g. fragments) all desktop paradigms are applicable. Plus new Android devices have proximity sensor making "hover-over" meaningful again even w/o a mouse. Pressed/selected enabled/disabled is oversimplification.
7

Focused - (Window, View) is a destination of keyboard events (yes, some Androids have physical keyboard) and some have "deodorant-ball" generating left up right down arrows keyboard shortcuts.

Activated - the widget (view) which is activated. E.g. in multi selection list the selected views are activated. I believe the necessity of this additional stage in API 11 was due to activating multi-selection that contains checkboxes. Thus the selected and checked states need to be separated.

Selected - is only applicable to check boxes and other selectable views.

The complete list of View states is (StateSet id on the left, flag on the right):

    R.attr.state_window_focused,    VIEW_STATE_WINDOW_FOCUSED,
    R.attr.state_selected,          VIEW_STATE_SELECTED,
    R.attr.state_focused,           VIEW_STATE_FOCUSED,
    R.attr.state_enabled,           VIEW_STATE_ENABLED,
    R.attr.state_pressed,           VIEW_STATE_PRESSED,
    R.attr.state_activated,         VIEW_STATE_ACTIVATED,
    R.attr.state_accelerated,       VIEW_STATE_ACCELERATED,
    R.attr.state_hovered,           VIEW_STATE_HOVERED,
    R.attr.state_drag_can_accept,   VIEW_STATE_DRAG_CAN_ACCEPT,
    R.attr.state_drag_hovered,      VIEW_STATE_DRAG_HOVERED

Also see:

/**
 * Changes the activated state of this view. A view can be activated or not.
 * Note that activation is not the same as selection.  Selection is
 * a transient property, representing the view (hierarchy) the user is
 * currently interacting with.  Activation is a longer-term state that the
 * user can move views in and out of.  For example, in a list view with
 * single or multiple selection enabled, the views in the current selection
 * set are activated.  (Um, yeah, we are deeply sorry about the terminology
 * here.)  The activated state is propagated down to children of the view it
 * is set on.
 *
 * @param activated true if the view must be activated, false otherwise
 */
public void setActivated(boolean activated)



/**
 * Dispatch a key event to the next view on the focus path. This path runs
 * from the top of the view tree down to the currently focused view. If this
 * view has focus, it will dispatch to itself. Otherwise it will dispatch
 * the next node down the focus path. This method also fires any key
 * listeners.
 *
 * @param event The key event to be dispatched.
 * @return True if the event was handled, false otherwise.
 */
public boolean dispatchKeyEvent(KeyEvent event)

Um, yeah, we are deeply sorry about the terminology here. 🐙

Your Answer

Draft saved
Draft discarded

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.