Clearfocus Invalid?
EditText in focus and not focus, the display is different: Focus when the cursor is flashing, and we usually give it to set the selector,focus when it is added to the border and so on.
Usually when we touch a view outside of edittext, we need to clear the edittext focus. It's natural to think of Edittext.clearfocus (), but it's often not. (Edittext.isfocus () is still true and the cursor is still jumping ...)
The realization of Clearfocus
Clearfocus Call Stack (important part):
View.clearfocus ()->
view.clearfocusinternal ()->
{
1 mparent.clearchildfocus (this); Traverse the parent node up from the view, knowing that the Decorview is set to NULL for the mfocus stored in parent (ViewGroup), that is, clear focus
2. Rootviewrequestfocus ();// Call the Decorview Requestfocus () method to locate and set the view to the focus
}
As you can see from the call stack listed above, clearing the focus actually contains 2 parts of the operation:
Clears the focus flag for the current view and clears the Mfocus information stored in its ancestor node
Call Decorview's Requestfocus () method, look for a view, and set it to focus
implementation of Requestfocus ()
The Requestfocus (int) supports FOCUS_UP, Focus_down, Focus_left, and focus_right 4 parameters to indicate the direction of the focus, but in fact the incoming directional parameters do not work. (This actually better understand, to Focus_right, is this the choice of Right son tree view, or draw on the right view?)
Regardless of the parameters, Requestfocus () finds the first Focusintouchmode view and sets it to focus by first-order traversal.
The settings are as follows:
Give the current View Focus flag (Mprivateflags)
call Mparent.requestchildfocus () to assign itself to the mfocus of its parent view, and then the parent view calls Mparent.requestchildfocus () until Decorview.
So starting with the Decorview, you can find the real focus view by just mfocus.
@Override public
View Findfocus () {
if (DBG) {
System.out.println (' Find focus in ' + this + ': flags= '
+ i sfocused () + ", child=" + mfocused);
}
if (isfocused ()) {return this
;
}
if (mfocused!= null) {return
mfocused.findfocus ();
}
return null;
}
Note: According to requestfocus this search strategy, given a starting point, the view will always be the same, that is, you call Decorview.requestfocus () multiple times, the focus is the same, If you don't change the view hierarchy and focusable, you should call its Requestfocus () method directly when you want to get the focus of a particular view.
Tips: For ViewGroup, you can use the Descendantfocusability setting to prioritize parent or child to get focus. Optional value: focus_before_descendants (default), Focus_after_descendants, Focus_block_descendants.
Is clearfocus really ineffective?
Of course not, there are times when Edittext.clearfocus () is found to be invalid because: After clearing the focus, you will also find a focusintouchmode view and set it to focus in the order of the first sequence traversal. And your edittext happens to be the first qualified view. (therefore, it is not the elimination of success, but the elimination, but also to set the!!)
Once you know the reason, the solution is simple, find a view before EditText, set it to be the focus of the
View.setfocusableintouchmode (True)
android:focusableintouchmode= "true"
If you don't know how to find a view before EditText, you can choose its parent (xxxlayout) directly, because the ViewGroup default policy is: focus_before_descendants
Judge whether focus
IsFocused (), which determines whether or not you have the Focus
Hasfocus (), which determines whether or not your own child has the focus.