In the previous Building ‘Droids post, we went through an exercise of figuring out what was going wrong with a RelativeLayout used as rows in a ListView. This exercise used “retro” diagnostic techniques, such as changing background colors, to see what’s going on.
Two commenters, including Romain Guy from the Android team, pointed out the Hierarchy Viewer tool that has been added to the 0.9 SDK. So, today, let’s see what this tool is all about and how it can help you make sense of your layouts as they are used.
To use the Hierarchy Viewer, you first need to fire up your emulator, install your application, launch your activity, and navigate to spot you wish to examine. For today’s demonstration, we’ll use a trivial activity, whose layout is shown below:
[sourcecode language=”xml”]
[/sourcecode]
Next, launch the Hierarchy Viewer, found in the tools/ directory of your Android SDK installation. This brings up the main Hierarchy Viewer window:
The list on the left shows the various emulators you have opened. The number after the hyphen should line up with the number in parentheses in your emulator’s title bar.
Clicking on an emulator shows, on the right, the list of “windows” available for examination:
Note how there are many other windows besides our open activity, including the Launcher (i.e., the home screen), the Keyguard (i.e., the “Press Menu to Unlock” black screen you get when first opening the emulator), and so on. Your activity will be identified by application package and class (e.g., com.commonsware.android.files/...).
Where things get interesting, though, is when you choose a window and click Load View Hierarchy. After a few seconds, the details spring into, er, view, in a perspective called the Layout View:
The main area of the Layout View shows a tree of the various Views that make up your activity, starting from the overall system window and driving down into the individual UI widgets that users are supposed to interact with. You will see, on the lower-right branch of the tree, the LinearLayout, Button, and EditText shown in the above code listing. The remaining Views are all supplied by the system, including the title bar.
Clicking on one of the views adds more information to this perspective:
Now, in the upper-right region of the Viewer, we see properties of the selected widget — in this case, the Button. Alas, these properties do not appear to be editable, which would be a wicked-cool modification to the Viewer (in case Mr. Guy happens to be reading this post…).
Also, the widget is highlighted in red in the wireframe of the activity, shown beneath the properties (by default, views are shown as white outlines on a black background). This can help you ensure you have selected the right widget, if, say, you have several buttons and cannot readily tell from the tree what is what.
And, if you double-click on a View in the tree, you are given a pop-up pane showing just that View (and its children), isolated from the rest of your activity.
But, wait! There’s more!
Down in the lower-left corner, you will see two toggle buttons, with the tree button initially selected. Clicking on the grid button changes puts the Viewer in a whole new perspective, called the Pixel Perfect View:
On the left, you see a tree representing the widgets and other Views in your activity. In the middle, you see your activity (the Normal View), and on the right, you see a zoomed edition of your activity (the Loupe View).
What may not be initially obvious is that this imagery is live. Your activity is polled every so often, controlled by the Refresh Rate slider. Anything you do in the activity will then be reflected in the Pixel Perfect View’s Normal and Loupe Views.
The hairlines (cyan) overlaying the activity show the position being zoomed upon — just click on a new area to change where the Loupe View is inspecting. And, of course, there is another slider to adjust how much the Loupe View is zoomed.
As always, additional details of how the Hierarchy Viewer works can be found in the Android SDK documentation.
