[Android Personal Understanding (vi)] Considerations for using the Include tag

We use the include tag to improve the reusability of some of the code while increasing the hierarchy and the rationality of the code.
However, when we actually use it, it is often due to the fact that the include attribute and the include principle are not clear enough to produce a bug.
1. First, we explain the relationship of layout file B contained in layout file A and include in the Include label
It must be clear that A and B are connected by using include, more like stitching. Include is not a view class, it is naturally within its layout object, not a nested relationship.
We all know that we can delete the include tag in a and copy and paste the code of B directly, so it is possible. But we often appear when we use it, we can't find the components under B directly by ID or in some components, such as drawerlayout, which can't recognize the components of B, but we can think of them as smoke for the include understanding. The reason for this is that the system uses the include tag to identify the XML file mechanism as a result of a loop, it naturally occurs when certain parts are rewritten, and the method that is called directly fails. (PS: Personal understanding, do not see the source of the include, do not know the specific implementation of the include)
2, then by the above, we by the splicing relationship, we can understand the necessity of the merge label.
is to tell system B that the layout file is a legitimate layout file under Include, which can be spliced directly so that the components within the B file and the components of the include tag in A are a peer relationship. The goal of a peer relationship is to optimize the UI structure and reduce node redundancy. Because the more XML is nested, the more times the system needs to traverse.
3, the question comes again, since is the splicing relation, then what is the function of the include attribute?
The meaning of the include attribute is to rewrite the attributes of the root component that he contains, not just the ID, but more the layout property. The description of the official website for Android Development is mentioned in this way:
"Similarly, you can override all the layout parameters. This means, any android:layout_* attribute can is used with the tag. "
This means that any android:layout_* attribute can be applied to the tag. Meaning there are two layers, one must be overloaded layoutwidth and layoutheight familiar, the other layout_* properties will work, no this will be ignored. The other layer is only the write Layout_* property in the Include property. Because this is still the case, the include does not make sense, and the overriding attribute is intended to determine the stitching position of the B layout file.
It is also easy to understand that the layout of the root layouts under the B file will not work because the properties of the root layout are overridden.
4, or by the last question, we elicit the id attribute of the include tag. Not only does the include specify an ID, it cannot directly be obtained directly from the control in the main XML, but it must first obtain the XML layout file and then obtain its child controls by Findviewbyid the layout file. When no ID is specified, this is the only direct. Findviewbyid to get its child controls. As for the reason, we are still attributed to the invocation mechanism of the layout file under include.

In the actual application, I have two bugs because of include, here to share.
Bug1:drawerlayout for content layout if you use the include tag but do not declare the width and Height properties, the component is not recognized. This is similar to the XML attribute requirements for the left drawer and the right drawer, which must have the same android:layout_gravity= "start" as the android:layout_width or end.
The source code is as follows:

<android. Support. V4. Widgets. DrawerlayoutXmlns:android="Http://schemas.android.com/apk/res/android"xmlns:tools="Http://schemas.android.com/tools"Android:id="@+id/drawer_layout"Android:layout_width="Match_parent"android:layout_height="Match_parent"> <include layout="@layout/flame_layout"Android:layout_width="Match_parent"android:layout_height="Match_parent"/> <linearlayout android:id="@+id/left_drawer"Android:layout_width="240DP"android:layout_height="Match_parent"android:layout_gravity="Start"> <include layout="@layout/drawer_left"/> </linearlayout></android. Support. V4. Widgets. Drawerlayout>

BUG2: The custom weight is not responding when used.
In fact, because we did not select the corresponding components, sometimes reported nullpointexceptiom, sometimes is the custom component of the listener unresponsive, then we speculated that the cause of the Onclik and Ontouch value, the custom components of the internal monitoring events, etc. Actually just whether the include specifies the ID, and the object selection problem for the Findviewbyid method. Details such as include are often the hardest to find.

Finally, I actually thought, if the include tag plus a layout tag, the above problems do not need to consider, this article is not necessary. But this goes back to question 2 above, minimizing the nesting of layouts, which is also the heart of the Android merge.

[Android Personal Understanding (vi)] Considerations for using the Include tag