Custom view, inherited from layout, reduces the layout hierarchy

Whether for the sake of encapsulation or to achieve a special effect, we will be more or less the practice of custom view, there are two main: one is inherited from view or ViewGroup, and one is inherited from various existing layout using XML to write.

Today is to discuss the second, the practice is not detailed, here is mainly for this way brought about the layout of the problem of deep-seated problems proposed two scenarios.

The first, note the use of merge in the layout XML, do not misunderstand this only in framelayout time to use Oh, this is the correct role in parsing the XML layout is not resolved by this flag bit directly to ignore this layer, the following level of view directly added to the upper level. Therefore, after the use of the course will be less than a layer of layout level. Of course, the layout you use to encapsulate it needs to be consistent with the container you would like to use for the XML file.

Note, however, that ignoring this is also a loss of attribute descriptions at this level, such as the orientation attribute of linearlayout, such as gravity, which is also reverted to the default, with many key attributes. This needs to be set up in the encapsulation class through code (why it needs to be wrapped in the layout of the XML file you want to use the same as the container), do not forget, otherwise the effect will be very problematic.

The second, similar to the above thought, is simply to remove the extra layer in the code, first the first sub-view in a wrapper class is taken out, and then the wrapper class sub-view is emptied, and finally the sub-view is added to the upper level of viewgroup, so that the view level is reduced, However, the encapsulation class interface as an interface encapsulation feature can still be maintained.

Finally, in some cases the above two methods can be used at the same time oh, the effect is obvious.

Let's take one example and use both of these.

Wrapperview.javapublic class Wrapperview extends Framelayout {public    Wrapperview (context context) {        super ( context);        Mcontext = context;//        setgravity (gravity.center_horizontal);        Init ();    }    /**     * @Description <br> Initialize *     /    private void init () {        inflate (mcontext, r.layout.info, this);    } Public    void Fun1 (object o) {            } public        void Fun2 (object o) {            }}

Info.xml<?xml version= "1.0" encoding= "Utf-8"? ><merge xmlns:android= "http://schemas.android.com/apk/res/ Android "    android:layout_width=" match_parent "    android:layout_height=" match_parent "    >    < ScrollView        android:layout_width= "match_parent"        android:layout_height= "match_parent" >        < LinearLayout ...........        </LinearLayout>    </ScrollView></merge>  

Demoactivity.javapublic class Demoactivity extends Activity {private Wrapperview mfview;protected void OnCreate (Bundle Savedinstancestate) {super.oncreate (savedinstancestate); mfview = new Wrapperview (this); View view = Mfview.getchildat (0); Mfview.removeview (view); Setcontentview (view);}}

This example is relatively simple, unfortunately, is precisely the use of the framelayout, I hope it has not caused us to use this misunderstanding. Other layouts simply require the code to dynamically set layout properties to ensure that the display is correct.

These two methods in my practice so far there is no problem, I hope that we can use to find more problems to shoot bricks, film together to discuss a better solution.

Custom view, inherited from layout, reduces the layout hierarchy