Abstract Factory---ipolicy in Android source code

Abstract Factory application is very wide, in the Android source code, this ipolicy is a simple abstract Factory mode. The following analysis of Ipolicy and its implementation, as well as the creation of related objects (source based on 5.0.0).

Abstract Factory Intent

Provides an interface to create a series of related or interdependent objects without specifying their specific classes.

UML Class Diagram

By inheriting abstract factories, different product families can be produced.

code example

    AbstractClass absfactory{ Public AbstractAbsproductaCreateProduct1(); Public AbstractAbsprodcutbCreateProduct2(); }AbstractClass absproducta{}AbstractClass absproductb{} class ProductA1 extends absproducta{} class ProductB1 extends absproductb{ Public void interactwithproducta(Absproducta product) {//associated with producta}} class ConcreteFactory1 extends absfactory{Private StaticConcretefactory instance =NewConcretefactory (); PublicConcretefactorygetinstance(){returnInstance } PublicAbsproductacreateproducta(){return NewProductA1 (); } PublicAbsprodcutbCREATEPRODUCTB(){return NewProductB1 (); }    } Public Static void Main(string[] args)        {Concretefactory instance = Concretefactory.        Absproducta Product1 = Instance.createproducta ();        ABSPRODUCTB product2 = INSTANCE.CREATEPRODUCTB ();    Product2.interactwithproducta (PRODUCT1); }

Abstract factories are the creation of a series of interrelated objects, so that the concrete implementation of each abstract factory creates objects that are interrelated and can be different product lines, which is equivalent to designing a set of product specifications from the top. Here is a brief introduction to the abstract factory. If you want a good understanding, you can refer to the design pattern: The basis of reusable object-oriented software for an introduction to abstract factories. Ipolicy is described below.

Ipolicy

Ipolicy under the Com.android.internal.policy bag. It is an abstract factory about Android windows, window management, layout loading, and event fallback handler this series of Windows related products. First look at the UML class diagram of Ipolicy.

UML diagram

Ipolicy is the abstract interface for generating window screen related objects, in the Android phone source code, Com.android.internal.policy.impl.Policy is its only implementation, according to the notes in the source code, is that policy is a simple implementation of the Ipolicy, which is used to generate the object collection. Policy creates a series of Windows related objects for the phone: Phonewindow,phonelayoutinflater,phonewindowmanager,phonefallbackeventhandler. From the UML diagram can be seen, ipolicy is a typical abstract factory, only in the source code only a specific factory implementation.

Another special aspect of the policy implementation is that it uses the static domain to pre-load the objects he needs to create, meaning that when the virtual machine loads the policy class, it loads the class of the object it creates.

Related Object Introduction

Each object created by Ipolicy is described below separately

Policymanager

Policymanager equivalent to the client of this abstract factory, it only static method, his static method and Ipolicy interface is corresponding. It contains a policy object, equivalent to a policy agent, the corresponding creation will be given to the policy to create, such as the implementation of the Makenewwindow method:

// The static methods to spawn new policy-specific objectspublic static Window makeNewWindow(Context context) {    return sPolicy.makeNewWindow(context);}

window and Phonewindow

Window is the windows in Android, each activity will correspond to one window, in the activity's attach method, there is window's creation code:

    final void attach(Context context, ActivityThread aThread,        Instrumentation instr, IBinder token, int ident,        Application application, Intent intent, ActivityInfo info,        CharSequence title, Activity parent, String id,        NonConfigurationInstances lastNonConfigurationInstances,        Configuration config, IVoiceInteractor voiceInteractor) {        attachBaseContext(context);        mFragments.attachActivity(this, mContainer, null);        mWindow = PolicyManager.makeNewWindow(this);        mWindow.setCallback(this);        mWindow.setOnWindowDismissedCallback(this);        mWindow.getLayoutInflater().setPrivateFactory(this);        ...

The Attach method is to assign a value such as context,application to the activity, which is called during the Activiy startup process. We pop up the dialog box (Dialog), which also has a window. In addition, the activity corresponds to the Startup window (starting Windows). A window can also have child windows. In addition, there are some other windows in Android, the input window, the Status bar window, the wallpaper window.

The window has a dedicated window management service Windowmanagerservice, which corresponds to each activity in Windowmanagerservice for Appwindowtoken, while Appwindowtoken describes a set of Windows (a group of WindowState), corresponding to the various windows of the context in the activity.

In the mobile phone, the concrete implementation of window is Phonewindow. Phonewindow is a window implementation that corresponds to an Android phone. Phonewindow contains the Decorview, Decorview contains the title bar and the specific view (set by the Setcontentview). The relationship between them is as follows:

The real direct correlation between window and view is WindowManager, set by Window.setwindowmanager. Each window will correspond to a windowmanager. Add, update, remove view from window with WindowManager Addview,updateviewlayout,removeview.

WindowManager can be obtained through Context.getsystemservice (Context.window_service), which is the Mwindow windowmanager of activity, and the concrete implementation of WindowManager is Windowmanagerimpl, and Windowmanagerimpl will be the related operation of the window (AddView, Removeview) Handed over to Windowmanagerglobal to achieve. Windowmanagerglobal is a singleton pattern that contains a Viewrootimpl list (ArrayList), a view list, A list of windowmanager.layoutparams, three linked lists correspond to each other, representing a view corresponding to the Layoutparams and Viewroot. Windowmanagerglobal obtained the binder interface Iwindowmanager for Windowmanagerservice. Viewrootimpl obtained windowsession (Binder's proxy) through the Iwindowmanager of Windowmanagerglobal, The Viewrootimpl W (Binder object) is passed to Windowmanagerservice to communicate with Windowmanagerservice. The UML diagram between them is as follows:

Windowmanagerpolicy,phonewindowmanager

This windowmanagerpolicy differs from the WindowManager described in the Windownmanager,window described in window as the management of window and view interactions. The Windowmanagerpolicy is more inclined to manage the window screen, for example, the startup windows are created by it. Also includes a specific screen management, such as to get the screen display size, screen rotation, screen settings and so on. Phonewindowmanager is the implementation of Windowmanagerpolicy in mobile phone specifications. Windowmanagerpolicy also has an internal static class Windowmanagerpolicy.windowstate, which is managed by Windowmanagerservice, is added from a window, is present, removed from the window, is a window state interface, can be To get the process that the current window belongs to, the package name, the current frame

Layoutinflater,phonelayoutinflater

Layoutinflater should be familiar, it is the class used in Android for XML layout loading, it is an abstract class, Phonelayoutinflater is its implementation on Android phone. The Oncreateview method and Cloneincontext method are mainly implemented in Phonelayoutinflater.

Fallbackeventhandler,phonefallbackeventhandler

This is the fallback event handler, mainly to handle the fallback event (Fallback).

Design analysis of Ipolicy abstract factory

If you look only at Ipolicy,policymanager,policy's UML, you will find that these three parts are also like a UML diagram of a strategic pattern. This part itself can also be said to be a strategy, a strategy of creation. But it would be more appropriate to understand Ipolicy as an abstract factory, which is responsible for generating a series of related products without having to control the specific implementation of the product.

First of all, the relationship between the four products, window is to represent Windows, Abstract window management, and Windowmanagerpolicy is about the window screen management policy, Layoutinflater is an XML parser, Parsing the XML into a specific element view in the window, and finally fallbackeventhandler the fallback event handler, the event acts on top of the window. The specific performance of these four products in different product clusters is not the same, but they have a relationship with each other. With a unified creation interface, it is more convenient to use these interfaces.

Take the phone's four product implementations, the Phone window, and windowmanagerpolicy nature is different, and the other layoutinflater will vary, such as the XML view may be limited, In Phonelayoutinflater, the package name is prefixed with "android.widget.", "Android.webkit.", "Android.app." These three to create a view. In addition, if the product cluster is TV, Fallbackeventhandler processing may be directly back to the previous station, and the phone will return to the previous operation.

Implemented with four factory methods

In fact, four different products (Window,windowmanagerpolicy,layoutinflater, is the XML parser, the XML parsing into the Window of the specific element view, the last Fallbackeventhandler), It is certainly possible to use four factory methods, but there is a lack of separation of products that should have been interrelated, and the abstraction of factories has improved the coupling between them to a certain extent.

Extended Advantage Analysis

If in addition to the phone, and suddenly have a new product cluster (for example, TV, smart watch, I do not investigate the implementation of these two methods), then only need to create a corresponding policy, and the corresponding product line, Then the Policymanager Ipolicy point to the new product cluster policy is good.

Abstract Factory---ipolicy in Android source code