We'll email you at these times to remind you to study
You can set up to 7 reminders per week
We'll email you at these times to remind you to study
So I'm pretty sure that some of you
went to the session this morning by Justin
where he showed Hierarchy Viewer.
But I want to show you that tool again.
That's something I use very often.
So how many of you use that tool
in your developments?
That's not enough.
So Hierarchy Viewer,
let me show you how it works.
I will show you the version that's from our tree,
but Hierarchy Viewer is a tool that comes from the SDK,
so you can just double-click the Hierarchy Viewer executable
and you will get pretty much the same tool.
So that tool works with the emulator.
It also works with devices.
Unfortunately, it doesn't work for security reasons
with consumer devices.
So if you have an ADP1,
or even maybe with a phone that you just got yesterday,
it might work.
But if it doesn't work with a phone,
you can just use it with the emulator.
So here I can see the list of devices
that are attached to my computer.
I have only the emulator.
And over to the right side, I have the list of windows.
So I can inspect any window I want,
any application I want.
And it's by default. I don't select anything.
It's gonna choose the window that's currently
the foreground window.
So then you just click the Load Viewer Hierarchy.
And this is asking the device to send a dump
of the current UI back to the tool.
And then in the tool, you can get an overview
of what the view tree looks like.
So that's the home screen.
And actually, that's a pretty good tree
because it's very wide, but it's also very flat.
What really matters is that you don't have
too many levels in the tree.
If it's wide, that's okay.
Here at the bottom,
you can see how many views you have in UI.
So here we have 39 views.
So that includes the grid with all your applications,
all the icons that you have on your homescreen,
your widgets, all that stuff.
A good number of views is usually between zero,
and you can go up to 80 or 100,
but that's pushing it.
If you go above that,
you really, really need to rethink your UI
and improve it.
And something we introduced in Cupcake
to give you a better idea of whether your changes
are improving the application
is this little table over there.
So those numbers are-- actually come from the device,
and they tell you how much time it took in milliseconds
to measure all the views in the hierarchy,
how long it took them to do the actual layout,
and how long it took to draw them.
So those numbers are not perfect, 'cause if the device
is busy because there's a sync happening in the background,
or if an application is viewing the CPU,
those numbers will vary.
But it will give you a good idea
and a good understanding of what's going on.
And here, those numbers are actually pretty good
but they should be a lot better.
Having 6 milliseconds spent
doing a layout of the whole screen,
that's actually really good.
But spending 30 milliseconds drawing the screen
is not good enough.
That means you can't animate at 60 frames per second.
So that's a really good way to see
if you're improving your UI.
And usually what you want to look for
in the Hierarchy Viewer tool is places where
I don't think have an example here.
But you want to look for layouts,
a view group that has only one child.
It means that one child has widths of field parent
and the height of field parent,
then you know that one of those two views is useless.
So here, that could be an example.
That frame layout could be removed,
but that's actually used by the framework
for many reasons, so we have to keep it here.
But--so try to look for layouts that have only one child
and try to get rid of them.
So once you've looked at your layout in Hierarchy Viewer
and you decided that, yeah, it sucks
and you have too many views, you need to fix it.
And I don't know how I did that.
There we go.
And here are a few solutions we can use.
The easiest solution is actually to use a--
what we call the compound drawables.
I hate that name
'cause it's hard to say for me,
and it's really long to type,
and it has the worst API name ever.
There's a method on things you call set compound drawable
with intrinsic bounds.
Yeah, you can laugh.
But the idea behind it is if--
if in your UI somewhere,
you have an image next to a piece of text.
Usually how people do that is usually a linear layout,
then they put an ImageView for the image
and a TextView for the text.
It seems pretty straightforward and pretty logical.
But that means that you have three views
to just display an icon and a piece of text.
So instead, you can use this feature of TextView,
with its terrible name, to replace the linear layout
of the TextView and ImageView, but only one TextView.
So here, I have a simple example on the left.
You see XML that produced this tree here.
We have a horizontal linear layout
and ImageView on the left,
and a piece of text on the right.
And the equivalent to this is the XML on the right.
So it's pretty much the same TextView
except we use this attribute called drawableLeft
that will simply set a bitmap
on the left side of the text.
You can also set bitmaps above the text,
below the text, and on the right.
And you can set four bitmaps at the same time
if for some reason you need to do this.
So it's very easy to do,
very efficient way to improve your UIs.
Now, the ViewStub.
How many of you ever used a ViewStub
or even know what it is?
That's not enough.
You guys should, you know, read the docs.
Well, the docs that we wrote.
Hey, we're working on it.
So the idea of a ViewStub is whenever you have a UI
in which there's a part of the UI
that you don't show very often--
I'm sure you've all used, like, the invisible mode
or the gone mode of the views to hide them from the UI.
Uh, so if you have a UI in which, you know,
parts of the UI is most of the time gone
or invisible, instead you can use a ViewStub.
The idea of ViewStub is to, um,
is to inflate part of the UI on demand.
So a ViewStub is an actual view
but it has a size of 0.
So it's 0 pixels wide, 0 pixels high.
It doesn't participate in the layout.
It doesn't draw anything.
So it's really cheap to have a ViewStub
in your view hierarchy.
And when you create a ViewStub,
you give it a reference to an XML layout file.
And whatever you call, um--
you make that ViewStub visible,
it will remove itself from the view hierarchy
and insert the inflated XML layout
where it used to be.
So here it's the same tree,
and in blue, you see-- you can see the ViewStub.
And now we have the same tree,
but the blue, uh-- the blue subtree
actually comes from the XML file
the ViewStub knew about.
So I call set visible on the ViewStub,
the ViewStub disappeared,
and instead we get this new, uh, this new bit of UI.
It's also an awesome way to create generic screens
without paying the cost of having too many views inside.
And this is how you use a ViewStub
It's really easy.
So ViewStub must have an ID
if you want to be able to-- to get the handle of it--
to it and inflate it.
You also probably want to specify the ID
of the inflated view, so that's the ID
that will be assigned to view that
when you inflate with the ViewStub.
And you also want to pass the reference
to the layout you want to inflate.
Now, on the ViewStub, you don't need to specify
the layout_ attribute.
So you don't need to give a width,
you don't need to give a height.
But if you do, those will be automatically assigned
to the inflated view from the XML.
So it's also a really easy way
to reuse an XML layout and still customize it
with specific layout attributes in a given screen.
So then in your code, what you have to do
is, uh, find the ViewStub
and set its visibility to visible,
and magic will happen.
And everything will appear in your UI.
You can also call the method inflate,
instead of setVisibility VISIBLE.
The cool thing about doing an inflate
is that it returns you
a reference to the inflated view.
So you don't have to do another findViewByID
to find the view that you just inflated.
Uh, and I know that we use that in several applications.
And that's where-- you can use Hierarchy Viewer
to see how other people write their applications.
So if you're wondering how we did
some of the default Android application,
just grab Hierarchy Viewer
and start inspecting your layouts
to see what exactly we did
and where we used ViewStubs.
Another cool XML tag you can use to improve your hierarchies
is called, uh, the merge tag.
Uh, it's a really bad name.
I couldn't find any-- any better name.
So declaring XML--
uh, layouts in XML is pretty awesome.
But the biggest issue is XML itself.
The problem with XML is that you need to have a root tag.
You need a root.
And if you try to create XML layouts
that you reuse in other layouts
or that you inflate with the ViewStub,
you will very often introduce a view--
an extra view in your layout--
just because you must have a root tag in your XML file.
Uh, so here we have an example.
On the left side, you can see a pretty simple UI.
And the blue rectangle-- the blue rectangle
comes from my, uh-- an XML that I inflated.
And you can see it has a parent that's also from layout.
And that's so useless.
I don't need to have a frame layout
inside the frame layout because, you know,
the parent frame layout has only one child.
So one of them is useless.
The reason why I have this sequence of frame layout
is because I included an XML layout.
I needed a root tag.
So I just put a frame layout there.
The merge tag can only be used as the root tag
of an XML layout file.
And it basically tells the system,
"It doesn't matter, ignore me.
"All my children will be assigned
to whatever parents I would normally have."
So if I replace--
Yeah, somebody's using Android.
So if you replace--
uh, and shame on you for not turning the sound down.
So if you replace the frame layout
in the XML file that you're including by a merge tag,
then the hierarchy becomes
the hierarchy you see on the right.
And we have one, uh, one level less
in the hierarchy, so it's more preferment.
It takes less time to inflate and so on and so on.
So that's how you would use the merge tag in XML.
It's really simple. It has no attributes.
You just have to put the name space on the tag.
And I wrote a blog about merge,
so if you couldn't follow what I just said,
go to developer.android.com.
Click the blog tab
and look at the User Interface articles,
and you will find more--
more explanations about the merge tag.
Log in to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Sign up to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Please enter you email address and we will mail you a link to reset your password.