Plugin management mechanism for Android and WebView

The previous article said that when using webviewclient or webchromeclient to handle requests sent by an HTML page, the corresponding service name, operation method and corresponding parameter data will be passed to a class called PlugInManager.

What is the role of the PlugInManager class?

You know, when taking advantage of Android native environment features. For example, a camera. For example, these functions are very decentralized, it is unclear when these features are needed, and when they are not required, so we want to be like plugins. When it is necessary to be loaded in, do not need to ignore him, and the PlugInManager class is one such management class.

It is mainly responsible for several things:

1) When you go to the HTML page, load the controls that we have defined.

Mpluginmanager = new PlugInManager (this); Mpluginmanager.loadplugin ();

So how does PlugInManager know how many plugin the app will load to respond to requests from HTML pages?

We are defined by a configuration file called Plugin.xml.

<plugins>    <plugin name= "App" class= "com.lms.xxx.bridge.plugin.App"/> <plugin name=    "Toast" class= "Com.lms.xxx.plugin.Toast"/>    <plugin name= "Dialog" class= "Com.lms.xxx.bridge.plugin.Dialog"/>       <plugin name= "User" class= "Com.lms.xxx.bridge.plugin.User"/></plugins>

For example, in the above configuration file, we will load the app, Toast, Dialog and User of the several plugin.

It can be thought that toast and dialog are all display forms in the Android native environment, although we use HTML pages to implement the interface, but to maintain consistency throughout the application, we use controls such as toasts in native environments or dialog boxes that we define ourselves.

What needs to be used, what is defined here.

Let's take a look at the Loadplugin method:

public void Loadplugin () {int identifier = Context.getresources (). Getidentifier ("Plugins", "xml", Context.getpackagename ()); if (identifier = = 0) {pluginconfigurationmissing ();} Xmlresourceparser XML = Context.getresources (). GETXML (identifier); try {int eventtype = -1;while ((EventType = Xml.next () ) = Xmlresourceparser.end_document) {if (EventType = = Xmlresourceparser.start_tag) {String name = Xml.getname (); if ("Plu Gin ". Equals (name)) {String pluginname = Xml.getattributevalue (null," name "); String className = Xml.getattributevalue (null, "class"); Configs.put (Pluginname, ClassName);}}} catch (Xmlpullparserexception e) {e.printstacktrace ();} catch (IOException e) {e.printstacktrace ()}}

To see, this is parsing the Plugins.xml file. Then put the corresponding plug-in class name into the configs, configs definition such as the following:

Private hashmap<string, string> configs = new hashmap<string, string> ();p rivate hashmap<string, IPlugin& Gt Plugins = new hashmap<string, iplugin> ();

With the Loadplugin method, we will load the plug-in that is defined in the Plugins.xml into the configs. Only the class name is stored in the configs. And plugins storage is the realization, but we do not need to care about this here.

Over here. The name attribute that is defined in the Plugins.xml file is the service.

2) According to the requested service name and operation method, and so on, for this request to find the corresponding plugin to deal with.

String Execresult = mpluginmanager.exec ("service", "action", args);

Take a look at the Exec method,

public string exec (string service, string action, Jsonobject args) throws pluginnotfoundexception {        IPlugin plugin = g Etplugin (Service), ..... Pluginresult result = plugin.exec (action, args), ...}

In the above logic can be seen. PlugInManager will use the Getplugin method to come up with the appropriate services, such as the following:

Public IPlugin Getplugin (string pluginname) throws Pluginnotfoundexception {string className = Configs.get (pluginname); if (classname==null) {throw new pluginnotfoundexception (Pluginname);} if (Plugins.containskey (ClassName)) {return plugins.get (className);} else {return addplugin (className);}}

In this way, we get a plugin implementation class that implements the IPlugin interface.

IPlugin is an interface whose definition is as follows:

Public interface IPlugin {public static final string service = "Service";p ublic static final string action = "ACTION";p UBL IC static final String args = "args";/** * Run request *  * @param action *            function * @param ARGS *            number * @return Pluginresu LT results */public Pluginresult exec (String action, Jsonobject args) throws actionnotfoundexception;

The most important way to define this is the Exec method. Each of our own defined plugins will implement this interface, just here. We first implemented an abstract base class plugin. Implement some common logic inside, and for the detailed implementation, it is inherited by plugin subclass.

Public abstract class Plugin implements IPlugin {protected DROIDHTML5 context;

For example, let's take the toast class above. It will inherit the plugin. Then, according to the corresponding service to implement the corresponding logic, invoke the native environment toast.

public class Toast extends Plugin {@Overridepublic Pluginresult exec (String action, Jsonobject args) throws Actionnotfound Exception {if ("Maketextshort". Equals (Action)) {return maketextshort (args);} else if ("Maketextlong". Equals (Action)) {return Maketextlong (args)} else {throw new Actionnotfoundexception ("Toast", action);}} Private Pluginresult Maketextshort (Jsonobject args) {try {String text = args.getstring ("text"); Android.widget.Toast.makeText (context, text, Android.widget.Toast.LENGTH_SHORT). Show (); catch (Jsonexception e) {e.printstacktrace (); return Pluginresult.newerrorpluginresult (E.getmessage ());} return Pluginresult.newemptypluginresult ();} Private Pluginresult Maketextlong (Jsonobject args) {try {String text = args.getstring ("text"); Android.widget.Toast.makeText (context, text, Android.widget.Toast.LENGTH_LONG). Show (); catch (Jsonexception e) {e.printstacktrace (); return Pluginresult.newerrorpluginresult (E.getmessage ());} return Pluginresult.newemptypluginresult ();}}

From the code above. I believe we are very easy to understand the plugin mechanism.

3) Called from an HTML page.

We have defined this set of plugin mechanisms in the Android native environment. Then in the HTML, you can also have this set of interface methods to correspond to different plugin, so we also define a variety of objects in JavaScript.

For example, the toast plugin described above, we can define a corresponding object in JavaScript. For example, the following:

var toast = {Maketextshort:function (text) {return exec ("Toast", "Maketextshort", json.stringify (text));},maketextlong : function (text) {return exec ("Toast", "Maketextlong", json.stringify (text));}}

Here, we can see the toast of the Maketextshort method, will call the Exec method mentioned in the previous article, because the pop-up window display such things must be synchronous, do not say a process, suddenly ran out of a box. Tell me, you just did it wrong. Right.

And here, we're going to have the service name (Toast). Operation Method (Maketextshort). There are also the contents of the display (Json.stringfy (text)), etc. through the Exec method, and then take advantage of the Webchromeclient Onjsprompt method. The command is passed to PlugInManager, which is handled by PlugInManager.

public boolean onjsprompt (WebView view, string URL, String message,string defaultvalue, jspromptresult result) {System.ou T.println ("Onjsprompt:defaultvalue:" + defaultvalue + "|" + URL + "," + message); Jsonobject args = null; Jsonobject head = null;try {//message:{"service": "XX", "Action": "XX"}head = new Jsonobject (message); if (defaultvalue ! = null &&!defaultvalue.equals ("")) {try {args = new jsonobject (defaultvalue);} catch (Exception e) {e.printstacktrace ();}} String Execresult = mpluginmanager.exec (head.getstring (Iplugin.service), head.getstring (iplugin.action), args); Result.confirm (Execresult); return true;

4) We will write these definitions of plug-in objects, as well as synchronous (exec), asynchronous run (Exec_sync) methods are written into a JavaScript file, convenient for unified management, so the general content of this file will be like the following:

var toast = {Maketextshort:function (text) {return exec ("Toast", "Maketextshort", json.stringify (text));},maketextlong : function (text) {return exec ("Toast", "Maketextlong", json.stringify (text));}} var Dialog = {...} var AndroidHtml5 = {..../* * Exec_asyn method called @params {jsonobject} cmd service name and action command @params {String} args parameter */callnative:func tion (cmd, args, success, fail) {....},<span style= "White-space:pre" ></span>...callbackjs:function ( Result,key) {...}};/ * * HTML5 Sync interface with Android */var exec = function (service, action, args) {var json = {"Service": Service, "action": action};v Ar result_str = prompt (Json.stringify (JSON), args), var result;try {result = Json.parse (RESULT_STR);} catch (e) {CONSOLE.E Rror (e.message);} ...} /* * HTML5 with Android asynchronous interface */var Exec_asyn = function (service, action, args, success, fail) {var json = {"Service": Service , "action": action};var result = androidhtml5.callnative (JSON, args, success, fail);}

End.

Plugin management mechanism for Android and WebView