Sub-ink Cook looked through Android Actionbar source code Analysis (a) instantiation

If you have worked on Android client development, believe that you are not unfamiliar with the Actionbar framework, or that you do not know it, but you should deal with it from time to time. Aside from the implementation of Actionbar, Actionbar is actually an abstraction of the titlebar behavior of Android, a framework that can be applied to the application of this pattern and an abstraction of the desired behavior view . Of course, maybe you are just like me, Actionbar is not satisfied with the efficiency of the implementation, because you open its view, you will find its implementation is very ugly. However, we are fortunate to see that Actionbar in the design of the time is not a strong type of posture, we found that it is not in a view of the way to exist, and as fragment is a very simple tool class. This design is just blocking the internal implementation, so that we can transform its implementation. Of course Actionbar's transformation is not the focus of the article, if you have revisiting the custom control, then I believe you read this series of articles, can help you to change the Actionbar. For this chapter I'll start with the Actionbar generation portal.

We know that when we define an activity again, the client agent that hooks directly to the WMS is the window class, which, of course, is not exactly what I'm saying. Because window is indirectly holding this proxy class, this does not affect our overall understanding of Actionbar. For the window class, it is phonewindow to deal with us directly. We'll call Setcontentview to register the internal view we need, and why it's an internal view, because in addition to our view, the window is also registered with multiple view decorations. In fact, this is a decorative mode, and even much like the template method.

@Override public    void Setcontentview (view view, Viewgroup.layoutparams params) {        if (mcontentparent = = null) { C2/>installdecor ();        } else {            mcontentparent.removeallviews ();        }        Mcontentparent.addview (view, params);        Final Callback cb = Getcallback ();        if (CB! = null &&!isdestroyed ()) {            cb.oncontentchanged ();}    }

We found that our view is actually contained in a viewgroup called Mcontentparent. The generation of this object is defined in the protected ViewGroup generatelayout (Decorview Decor) method in the window class.

We know that the effect on a window view is feature beyond Window.layoutparams. Feature the effect on the view does not directly deal with WMS. Even dealing with WMS is controlled by the Window.layoutparams class, meaning that feature itself is a small dessert that is dispensable. You will often see some property-matching code when generating mcontentparent:

int flagstoupdate = (flag_layout_in_screen| Flag_layout_inset_decor)                & (~getforcedwindowflags ());        if (misfloating) {            setlayout (Injector.getfloatingwindowwidth (GetContext ()), wrap_content);//MIUI Hook            SetFlags (0, flagstoupdate);        } else {            SetFlags (flag_layout_in_screen| Flag_layout_inset_decor, flagstoupdate);        }        if (A.getboolean (Com.android.internal.r.styleable.window_windownotitle, False)) {            requestfeature (FEATURE_NO_ TITLE);        } else if (A.getboolean (Com.android.internal.r.styleable.window_windowactionbar, False)) {            //Don ' t allow an action Bar if there is no title.            Requestfeature (Feature_action_bar);        }        if (A.getboolean (Com.android.internal.r.styleable.window_windowactionbaroverlay, False)) {            requestfeature ( Feature_action_bar_overlay);        }

We know that we can develop a collection of themes for a view, which can be customized with various appearance parameters, as well as feature attributes. Part of this is to transform into a window.layoutparams to deal with WMS. Like what:

if (!hassoftinputmode ()) {            Params.softinputmode = a.getint (                    com.android.internal.r.styleable.window_ Windowsoftinputmode,                    params.softinputmode);        }

As we can see, in fact, for a window of the input method management, it is necessary for the WMS to intervene, and this involves you in the client configuration file definition, you need to convert to the Window.layoutparams parameter attribute, let it pass to the WMS to trigger the management.

if ((Features & (1 << feature_action_mode_overlay))! = 0) {            Layoutresource = Com.android.internal.r.layout . Screen_simple_overlay_action_mode;        } else {            //Embedded, so no decoration is needed.            Layoutresource = com.android.internal.r.layout.screen_simple;        }

We see that if you have defined the Actionbar topic, then it will use the screen_simple or overlay of the two modes we only consider the simple way, we look at simple layout file:

<linearlayout xmlns:android= "http://schemas.android.com/apk/res/android" android:layout_width= "Match_parent" android:layout_height= "match_parent" android:orientation= "vertical" android:fitssystemwindows= "true" > <com. Android.internal.widget.ActionBarContainer android:id= "@+id/action_bar_container" android:layout_width= "MATC H_parent "android:layout_height=" wrap_content "style="? Android:attr/actionbarstyle "> <com.andro            Id.internal.widget.ActionBarView android:id= "@+id/action_bar" android:layout_width= "Match_parent" android:layout_height= "Wrap_content" style= "Android:attr/actionbarstyle"/> <com.android . Internal.widget.ActionBarContextView android:id= "@+id/action_context_bar" Android:layout_width= "mat Ch_parent "android:layout_height=" wrap_content "android:visibility=" Gone "style="? Android : Attr/actionmodestyle "/>    </com.android.internal.widget.ActionBarContainer> <framelayout android:id= "@android: Id/content" and Roid:layout_width= "Match_parent" android:layout_height= "0dip" android:layout_weight= "1" android:foreg Roundgravity= "Fill_horizontal|top" android:foreground= "Android:attr/windowcontentoverlay"/> <com.android . Internal.widget.ActionBarContainer android:id= "@+id/split_action_bar" android:layout_width= "match_parent                  "Android:layout_height=" wrap_content "style="? Android:attr/actionbarsplitstyle " Android:visibility= "Gone" android:gravity= "center"/></linearlayout>

We can intuitively see that this is consistent with the Actionbar layout we know. Portrait, Actionbar is actually actionbarcontainer. For the parsing and layout of the actionbar we put it back to talk. We see when we decide which layout to use, by calling:

ViewGroup contentparent = (viewgroup) Findviewbyid (id_android_content);

method to get mcontentparent, which means that our view is contained within the content container in this Actionbar container.

We return to the Setconentview method of activity. After we have set up our view, it initializes the Initactionbar ();

As I said earlier, Actionbar and fragment are not part of the Androidui system themselves, so it needs to be initialized. The Actionbar implementation class is Com.android.internal.app.ActionBarImpl, because Actionbarimpl is for window, So whether you're an activity or a dialog or a popupwindow, you can theoretically use Actionbar. This theory can actually explain that it is reasonable to have two actionbar in the same interface. It is even possible to implement your own set of Actionbar in a different fragment in the same window. Because it's not included in the management of WMS, well, a bit far away, we continue the previous article.

Public Actionbarimpl (activity activity) {        mactivity = activity;        window window = Activity.getwindow ();        View decor = Window.getdecorview ();        Init (decor);        if (!mactivity.getwindow (). Hasfeature (Window.feature_action_bar_overlay)) {            Mcontentview = decor.findViewById ( Android. r.id.content);        }    }

We see that the initialization of Actionbarimpl is mainly implemented by the Init method.

private void init (View decor) {Mcontext = Decor.getcontext (); Moverlaylayout = (actionbaroverlaylayout) Decor.findviewbyid (Com.android.internal.r.id.action_bar_overlay_        Layout);        if (moverlaylayout! = null) {Moverlaylayout.setactionbar (this);        } Mactionview = (Actionbarview) Decor.findviewbyid (Com.android.internal.r.id.action_bar);        Mcontextview = (Actionbarcontextview) Decor.findviewbyid (Com.android.internal.r.id.action_context_bar); Mcontainerview = (Actionbarcontainer) Decor.findviewbyid (Com.android.internal.r.id.action_bar_contai        NER);        Mtopvisibilityview = (viewgroup) Decor.findviewbyid (Com.android.internal.r.id.top_action_bar);        if (Mtopvisibilityview = = null) {Mtopvisibilityview = Mcontainerview;         } Msplitview = (Actionbarcontainer) Decor.findviewbyid (Com.android.internal.r.id.split_action_bar); if (MACtionview = = NULL | | Mcontextview = = NULL | |                    Mcontainerview = = null) {throw new IllegalStateException (GetClass (). Getsimplename () + "can only is used" +        "With a compatible window decor layout");        } mactionview.setcontextview (Mcontextview);                Mcontextdisplaymode = Mactionview.issplitactionbar ()?        Context_display_split:context_display_normal;        This is initially read from the Action Bar style final Int. current = Mactionview.getdisplayoptions ();        Final Boolean homeasup = (current & display_home_as_up)! = 0;        if (homeasup) {mdisplayhomeasupset = true;        } actionbarpolicy ABP = Actionbarpolicy.get (Mcontext);        Sethomebuttonenabled (Abp.enablehomebuttonbydefault () | | homeasup);    Sethasembeddedtabs (Abp.hasembeddedtabs ()); }

The main purpose is to initialize some view parameters, and to inject a Actionbar control callback into the Actionbaroverlaylayout object, which is itself, of course. But we can also see from the code that the Actionbar itself has a relatively high degree of coupling between each internal object, referencing each other, but programming against the Actionbar interface effectively masks this inefficiency. Here, in fact, the instantiation of the Actionbar has been completed. In the next chapter we will start the discussion of Actionbar view layout.

Non-sub-ink:

qq:1025250620

Sina:http://weibo.com/1752090185/profile?rightmod=1&wvr=5&mod=personinfo