I think there was a session this morning.
I think that was Justin who talked about it.
RelativeLayout is often a very nice way
to, uh, simplify UIs
and to replace a bunch of nested layouts
by just one RelativeLayout.
It's very powerful.
I often use it myself to replace a bunch of LinearLayouts.
The only problem is that it's really hard to use.
Uh, and I think on the Android thing,
I'm kind of the only one who understands how it works.
So very often I get people, you know,
come to my desk and are like,
"Hey, I'm trying to use a RelativeLayout
but it doesn't work."
I'm like, "Yeah, I know."
And again, totally my fault.
And the problem is, uh, it does work,
but you have to understand how it's implemented
to use it in some situations.
Um, and I promise I will fix that.
I know how to fix it,
I just need to find the time to fix it.
But I will.
Send me, you know, letters of encouragement
and emails, or threaten me.
Or if you bring me cookies, too, 'cause I didn't have lunch.
So if you bring me cookies, I'll--
I might fix the RelativeLayout.
Anyway, I also wrote an article about RelativeLayout
on the, uh, the Android blog.
If you go there, you will get,
I think, a better understanding
of how it works.
I show in that example how to replace
a couple of LinearLayouts with just one RelativeLayout.
And again, don't hesitate to use the Hierarchy Viewer
and inspect, uh, the default Android applications
to see how we did-- uh, we implemented the layouts
that we have, and to see how we solved
that kind of issues.
Another awesome tip that you should be using,
and I keep telling that to application developers,
"Use custom views, use custom views."
Uh, but usually the developers are scared
of using custom views for some reason.
So how many of you ever wrote a custom view?
Okay, you're-- you're really good.
Thank you. Any other ones?
Shame on you.
Um, custom views are awesome
because you have control over the view.
You know how it's used.
So you can take shortcuts.
And you can improve performance by a lot.
The problem we have on the framework team
is that we have to write very generic pieces of code.
And sometimes it's very hard to optimize that.
Or, you know, the cost of optimizing the view
actually ends up costing more in the--in some situations.
So here--an example--
It's actually something that we shipped in Cupcake.
So the guy who's sitting in my office
is working on the Gmail application,
and he was having all those preference issues.
And I kept telling him, you know,
"Use custom views, use custom views, use custom views."
And he finally did. And it's awesome.
So the item you see here, um, an email.
So you have a check box, two lines of text,
the--the time or the date, and the star.
That used to be a very complex layout.
So there was, you know-- there were
a bunch of email layouts, maybe a RelativeLayout,
there were a couple of image views, three text views.
It was a lot of things for something that simple.
So instead, in Cupcake, he wrote a custom view.
So that's now one view.
He's doing all the drawing himself.
That gives him a lot more power, uh, over the drawing.
That's how he can do the-- the different ellipses
in the same lines-- line of text.
And the preference of the Gmail application
is now much better.
When you scroll through a long list of emails,
it's a lot smoother in Cupcake.
So if you can, uh, write custom views,
And take all the shortcuts you want,
all the shortcuts you need, to make your application fast.
And actually, writing custom views is pretty easy,
but I'll get back to that.
So that's the skeleton of a custom view.
All you have to do is extend the view class.
Uh, you need to have at least one constructor
that takes the context as a parameter.
And the only two methods that you need to override
are onDraw to do your drawing,
onMeasure is used to-- to tell the framework
how big your view wants to be.
And when you override onMeasure,
you have to call, at the end of the method,
If you don't, you will get an exception,
and it will tell you that you need to do it.
Um, setMeasuredDimension is how you tell the framework,
okay, I want to be, in this case,
100 pixels wide and 100 pixels high.
We'll get into more details
about that in the next session.
But just know that the dimensions that you indicate
might, uh--might not be used by the framework.
LinearLayout, for instance, is really good at that.
It, you know, asks the text view,
like, "How big do you want to be?"
The text view says, "Oh, I want to be 600 pixels wide."
And the LinearLayout's like, "Eh, I don't care.
You won't be 600 pixels wide."
So, you know, don't freak out if, uh,
those are not respected.
That's perfectly normal.
Use custom layouts.
How many of you have ever written custom layouts?
Ooh, a lot less. Okay, better.
Custom layouts are also awesome.
Sometimes, I'm sure, you-- you all had issues
when you're trying to come up
with the exact layout you wanted.
We tried to have some generic layouts
that are easy to use.
Sometimes they are not, like RelativeLayouts.
And, in some cases, it's actually a lot simpler
to write your own layout
than try to fight with the default layout
and come up with the one you wanted.
So this is an application I wrote for Android 1.0.
And I wanted a simple grid.
I wanted a simple, simple grid of photos.
So instead of using a table layout
or, you know, trying to use a bunch of LinerLayouts,
uh, to do what I wanted,
I just, you know, spent 30 minutes
writing my own custom layout that I call the grid layout.
That can only support six items,
because that's all I wanted on screen.
And it's very fast. It's very nice.
It does exactly what I want.
And I didn't spend my time getting frustrated,
fighting with the-- the default layouts.
Writing custom layouts
is similar to writing custom views.
It's a bit more complicated.
Again, we'll go into the details about custom layouts
in the next session.
Uh, but you extend the ViewGroup class.
You override the onMeasure method.
And the difference here is that not only do you have
to indicate what size you want to be,
but you also have to call Measure on all your children.
So you want to know, as a layout,
you want to know how big the children want to be.
So you just go through your children
and, uh, you measure them.
Then you also want to override the onLayout method.
And this is actually where you position the children
and where you give them a size.
So if you write a really good layout, like I just did,
you--you just do the simple mask,
you know, consisting,
putting the items in the right place.
Usually what we do, and what you should always do
when you are-- when you write a custom layout,
is ignore the children that have a visibility of gone.
Children in the gone state
must not participate in the layout.
It must be totally ignored.
Uh, and it actually could be ignored
in the measure-- measure phase as well.
But I didn't have enough space on the slide.
Invisible children still participate in the layout.
They still take-- take the room.
But they don't draw.
That's the difference between invisible and gone.
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.