Custom ViewGroup of Android UI design series creates a general closing keyboard widget imeobserverlayout (9)

Please indicate the source for Reprint: http://blog.csdn.net/llew2011/article/details/51598682 We usually meet some wonderful needs in development. In order to realize these needs, we often rack our brains. Sometimes we don't think about food and tea, which is a bit exaggerated (* ^ ^ *)... One of the most impressed needs is to bold some words in a paragraph. It took a lot of effort at that time, but fortunately, this problem was finally solved. You can take a look at the children's boots that are interested: Android UI Design Part VI uses HTML tags to display some text in bold in textview. Before, the product side put forward such a demand: after users input information, they require to hide the soft keyboard when clicking on the non input box. At that time, when I saw this requirement, I felt that it was not difficult and practical, so I was dizzy and realized it. Later, the product said that as long as the pages with input boxes should follow this logic, they should be called user experience... At that time, there were many pages with input boxes in the project. If each page wrote the logic, it would be a serious violation The book refactoring to improve the design of existing code says no more than three principles (no more than three principles mean that refactoring should be considered if the same logical code has been written more than three times) At that time, I spent some time to build a general lightweight keyboard closing widget imeobserverlayout, which is also the protagonist of our talk today. Before we begin to explain the code, let's take a look at the hierarchy diagram of the activity and learn how the view structure on the screen after the activity is started. The most convenient way to find out the hierarchical view of the activity is to use G The tool hierarchy viewer provided by oogle is located in the tools folder of the SDK . hierarchyviewer can not only display the interface view level of the currently running app, but also optimize our layout structure through the view level. In order to use hierarchyviewer tool to view the hierarchical structure of the current app, we first make a simple test to define the layout file activity_mian.xml. The code is as follows:

The layout file is very simple. The root node is FrameLayout. A textview is nested in the middle and displayed in the center. Then define mainactivity with the following code:

The code is very simple, and the running effect diagram is as follows:

After running the program, we find the hierarchyviewer in the tools folder of the SDK and double-click it to open it. The screenshot after running is as follows:

After the hierarchyviewer is opened, the tool will list all the programs that the current mobile phone can display at the view level, and the currently running programs will be displayed in bold and black in the list. Find our program and double-click to open it, as shown in the figure below:

The above figure is the layout structure of our current mainactivity runtime. The lower left side is the structure diagram, and the right side is the thumbnail and the corresponding display location diagram. The specific use of tools is no longer explained here. Children's boots who are interested can refer to them by themselves. According to the structure diagram, the root view of the current activity is the dercorview under the phonewindow class, which contains a LinearLayout sub view, and the sub view LinearLayout contains three sub views, a viewstub and two fragmelayouts. The first view viewsub displays the status bar, and the second view FrameLayout contains a textview, This is used to display the title. For the third view FrameLayout, its ID is content, which is the direct parent view of the View view shown in Activity by calling setContentView () method.

After understanding the hierarchical structure of activity, you can consider starting with the hierarchical structure to realize the general closing keyboard widget. We know that in the Android system, events are passed layer by layer, that is, events are first passed to the root view decorview, then passed down successively and finally to the target view. If we add a custom ViewGroup between the root view decorview and its child view LinearLayout, we can intercept events in the custom ViewGroup to determine whether to close the soft keyboard.

Since you want to add a custom ViewGroup between the decorview and its child view LinearLayout, you must first get the decorview. From the structure diagram of the activity above, we know that when calling setcontentview() of the activity to set content for the activity, it is finally added to the FrameLayout with ID content. Therefore, you can get this FrameLayout according to the ID, and then cycle up to find the parent, Until a view without a parent is found, the view is decorview. This method is feasible but not recommended. When constructing an activity, Google engineers added a GetWindow () method to the activity, which returns a window object representing the window. The window class is an abstract class, and it has a method getdecorview (). Children's boots who have seen the framework source code should know that the method returns the root view decorview, So we use this method.

Now you can get the root view decorview. Next, consider the functions that our ViewGroup should have. First, click the area outside the input box EditText to close the soft keyboard. You need to know which EditText is in the current layout. Therefore, there should be a set in the customized ViewGroup, which is used to save all the input boxes EditText in the current layout file; Secondly, when to find and save all the input boxes EditText in the current layout, and when to clear the saved input boxes EditText; Again, when the finger clicks the screen, the XY coordinates of the click can be obtained. According to the click coordinates, judge whether the click position falls in the input box EditText, so as to decide whether to close the soft keyboard.

Begin to implement our ViewGroup with the above problems. The code is as follows:

Imeobserverlayout inherits FrameLayout and defines the property medittexts, which is used to save all input boxes EditText in the current page. When we look for all input boxes EditText, we choose the onAttachedToWindow () method. When the View is added to the window, the latter method will be called, so ImeObserverLayout rewrites the onAttachedToWindow () method and calls collectEditText () method in this method. Let's look at this method:

The collectedittext() method first checks the nonempty of the medittexts, and then determines whether the passed in view is of ViewGroup type. If it is of ViewGroup type, it loops through each of its child views and recursively calls the collectedittext() method; If the EditText type is passed in, judge whether the EditText has been saved in the current collection. If not, add it. After saving the input box EditText, you should also consider emptying to avoid memory leakage. So ImeObserverLayout rewrote the onDetachedFromWindow () method and then called the clearEditText () method to empty all EditText.

After EditText is saved, the logic of hiding the soft keyboard is determined. In order to obtain the click coordinates, the onintercepttouchevent() method is rewritten, as shown below:

Judge the event first in onintercepttouchevent() method. If it is a down event and shouldhidesoftinput() returns true, call hidesoftinput() method to hide the soft keyboard. Let's take a look at shouldhidesoftinput() method. The code is as follows:

Shouldhidesoftinput() method first determines whether the medittexts is null or whether EditText is saved. If it is null or empty, directly returning false means that it is not necessary to close the soft keyboard. Otherwise, cycle through all edittexts, and judge whether the click position is in the EditText area according to the XY coordinates clicked. If the click coordinates are in the EditText area, directly returning false, Otherwise, return true. Now our customized imeobserverlayout is ready. Next, we need to add imeobserverlayout between decorview and its child view LinearLayout. In order to use this control more conveniently, we need to implement the added logic. To add logic, you need to use activity to obtain the root view decorview, so you need to pass in the current activity. The complete code is as follows:

We put imeobserverlayout into imeobserver as an internal static class, and set imeobserverlayout to private, so as not to let the outside world operate on it. Then we added a static method observer (activity activity) to imeobserver, in which imeobserverlayout was added between the root view decorview and its child view LinearLayout. Now everything is ready. Test it to see the effect. Modify the mainactivity code as follows:

The code of mainactivity does not need to be changed, but the line of imeobserver. Observer (this) is added after the setcontentview () method to realize the function of closing the input box. Is it very lightweight and easy to integrate? (* ^ ^ *)... Let's run the following program, and the effect is as follows:

Well, the effect is good. The control itself has no technical content. It is required to be familiar with the hierarchical structure diagram of activity, and then understand the event transmission mechanism. Finally, you can judge the click position according to the coordinates, so as to decide whether to close the soft keyboard. Well, customize the ViewGroup and create your own general close soft keyboard control. That's the end. Thank you for watching