14th Chapter 7 "Monkeyrunner Source Analysis" hierarchyviewer realization principle-Equip viewserver-get version number

The version number obtained here is two, one is the version number of the Viewserver itself, and the other is the version number of the Viewserver current usage protocol.

Why do we need to get the Viewserver version and its protocol version here? In fact, the main reason is that viewserver some of the features in the old version is not supported, such as Hierarchyviewer in the list of the current Activity window, for the focus of the window will be based on different Viewserver protocol version of different processing, Please see the source code example:

Window[] Loadwindows (ihvdevice hvdevice, IDevice device) {317 arraylist<window> Window s = new arraylist<window> (); 318 deviceconnection connection = null;319 Viewserverinfo ServerInfo = g Etviewserverinfo (device), 321 connection = new DeviceConnection (device), and 322 Connec Tion.sendcommand ("LIST"); $NON-nls-1$323 BufferedReader in = Connection.getinputstream (); 324 String line;325 W          Hile (line = In.readline ()) = null) {...          Window w = new Window (Hvdevice, line.substring (index + 1), id);       Windows.add (w); }342//Automatic Refreshing of Windows is added in Protocol version 3.343//before, the user NE Eded to specify explicitly that he wants to344//Get the focused window, which is done using a special type of345//window with hash code-1.346 if (serverinfo.protocolversion &lT 3) {347 Windows.add (Window.getfocusedwindow (Hvdevice)); 348}} catch (Exception e) {:      . }    }

Code 14-7-1 Protocol version action example devicebridge-loadwindows

The code first sends the "list" command to Viewserver to list all the open windows, and then saves each window. 342 line up according to the source of the comment parsing is said: from the Protocol version 3 has been added to the Windows Automatic Update function, but before this, if the user wants to get a focus on the window, you need to explicitly create a special hash value of 1 of the window instance to complete. How do you know it's hash value is-1? See the Getfocusedwindow Method for the window class:

  public static window Getfocusedwindow (Ihvdevice device) {    return new window (device, "<focused window>",-1); c4/>}

code 14-7-2 Window-getfocusedwindow method

Then look at the constructor of the window it calls and the corresponding incoming parameters:

  Public Window (Ihvdevice device, String title, int hashcode)  {    this.mhvdevice = device;    This.mtitle = title;    This.mhashcode = hashcode;    This.mclient = null;  }

Code 14-7-3 window-Constructors

The final creation is a window instance with a title of "<focused window>" and a hash value of 1.

Through the above example, mainly to explain that the Viewserver version will affect the different ways of processing the code, so we still need to see how these version information is obtained and saved.

Well, then we continue to analyze Hierarchyviewer's approach to equipping Viewserver Setupviewserver the Last Call method Devicebridge.loadviewserverinfo, this method is a bit long, We analyze it separately and look at the 1th part first:

260 public     static Viewserverinfo Loadviewserverinfo (IDevice device) {261         int server = -1;262         int protocol =- 1;263         deviceconnection connection = null;264         try {265             connection = new DeviceConnection (device); 266             Connection.sendcommand ("SERVER"); $NON-nls-1$267             String line = Connection.getinputstream (). ReadLine (), 268             if (line! = null) {269                 server = Integer.parseint (line):             }271         } catch (Exception e) {272             log.e (TAG, "Unable to get view server version F ROM Device "+ device"; 273         } finally {274             if (connection! = null) {275                 connection.close (); 276             }277< c17/>}    ...}

code 14-7-4 devicebridge-loadviewserverinfo get Viewserver version

The first important part of the code shown in line 265 is to establish a deviceconnection connection, and the incoming parameter remains an instance of the Ddmlib device class:

     deviceconnection Public (IDevice device) throws IOException {Notoginseng         Msocketchannel = Socketchannel.open (); 38         int port = devicebridge.getdevicelocalport (device),         if (port = =-1) {+-             throw new IOException ();         Msocketchannel.connect (New inetsocketaddress ("127.0.0.1", port));//$NON-nls-1$         Msocketchannel.socket (). Setsotimeout (40000); /+     }

Code 14-7-5 deviceconnection-Constructors

What the whole code does is clear:

• Create a Socketchannel
• Obtain the corresponding Viewserver local forwarding port number according to the device instance
• Connect the Socketchannel to the local viewserver to the originating port.

It's worth mentioning how to get the Viewserver local forwarding port number based on the device instance. You remember the 4th bar when we said Port forwarding, the final device instance and the corresponding local forwarding port number are stored in a static member HashMap named Sdeviceportmap in Devicebridge. So the thing to do here is to go to this hashmap. Use the device instance as the key to remove the value of the port number:

155 public     static int getdevicelocalport (IDevice device) {156         synchronized (sdeviceportmap) {157             Integer Port = sdeviceportmap.get (device); 158             if (port! = null) {159                 return port;160             }161             log.e (TAG, " Missing forwarded port for "+ device.getserialnumber ()); 162             return-1;163         }164     }

Code 14-7-6 devicebridge-getdevicelocalport

So now we have obtained viewserver corresponding to the local forwarding port number, Viewserver has also been in the instantiation of the deviceconnection when the connection is good, the rest of the order sent. Let's continue to look at the 2nd important part of "code 14-7-4 devicebridge-loadviewserverinfo Get Viewserver Version":

Connection.sendcommand ("SERVER");

It is obvious that the socketchannel that has been established to connect to Viewserver just deviceconnection to send the "SERVER" command:

     sendcommand public void-String command throws IOException {         BufferedWriter out = Getoutputstream (); 64
   
    out.write (command);         out.newline ();         Out.flush ();     
   

Code 14-7-7 Deviceconnection-sendcommand

So we're done analyzing. How do I send the "SERVER" command to Viewserver to get its version number? Not yet, and don't forget that we need to get the version of the protocol that Viewserver is currently using, in addition to getting viewserver, "code 14-7-4 Devicebridge- Loadviewserverinfo Get Viewserver Version "is just part of Loadviewserverinfo. Now let's analyze the 2nd part, but how does it get the protocol version:

260 public     static Viewserverinfo Loadviewserverinfo (IDevice device) {261         int server = -1;262         int protocol =- 1;    ...//Get Viewserver version number part slightly 278         connection = null;279         try {280             connection = new DeviceConnection (device); 281             Connection.sendcommand ("PROTOCOL");//$NON-nls-1$282             String line = Connection.getinputstream (). ReadLine (), 283             if (line! = null) {284                 protocol = Integer.parseint ( line); 285             }286         } ...  }

Code 14-7-8 devicebridge-loadviewserverinfo Get Protocol version

As you can see, the process is exactly the same as the code 14-7-4, but the command that is ultimately sent to Viewserver is the "PROTOCOL" instead of the "SERVER" that gets the agreement.

Finally we look at how Loadviewserverinfo is handled after obtaining these version numbers:

260 public     static Viewserverinfo Loadviewserverinfo (IDevice device) {261         int server = -1;262         int protocol =- 1;    ... 296         Viewserverinfo returnvalue = new Viewserverinfo (server, protocol); 297         synchronized (sviewserverinfo) {298             sviewserverinfo.put (device, returnvalue); 299         }         return returnvalue;301     }

Code 14-7-9 devicebridge-loadviewserverinfo finishing touches

Two things to do at the end of the final phase:

• First: Create a Viewserverinfo instance based on the acquisition agreement
• The second piece: Save this instance to sviewserverinfo this hashmap, like the above mentioned Sdeviceportmap, or use a device class instance as the key, The value is the Viewserverinfo instance that was just created

Here we first look at Viewserverinfo this class, in fact, it is the inner class of Devicebridge:

The public     static class Viewserverinfo {The public         final int protocolversion, and the public         final int serverversion ;         viewserverinfo (int serverversion, int protocolversion) {             this.protocolversion = protocolversion; 64             this.serverversion = serverversion;         +     }

Code 14-7-10 devicebridge-viewserverinfo

There are two member variables in it. A constructor is finished, and two member class variables are saved with the Viewserver version number and the Viewserver protocol version number we just obtained.

Note: More articles please pay attention to the public number: Techgogogo or personal blog http://techgogogo.com. Of course, you are also very welcome to pick up directly (ZHUBAITIAN1). This article by Heaven Zhuhai Branch Rudder original. Reproduced please consciously, whether the complaint rights to look at the mood.

14th Chapter 7 "Monkeyrunner Source Analysis" hierarchyviewer realization principle-Equip viewserver-get version number