(scattered applause)

- Hello, everyone.

Okay, cool, the mic's working.

So, yes, welcome to this talk

about efficient Android layouts.

If you've never met me before,

I've been doing Android drawup for about seven years,

first the Travel App company, the Expedia,

then currently at Trello.

As per usual, my thing doesn't work.

All right, I'm gonna give my presentation over here.

You know, you can click to engage, to rate sessions,

and ask questions, of which I will probably then answer

the questions at the end if you ask them.

Anyways, so this talks about efficient Android layouts,

and when I was writing it, what I found that

I was really interested in wasn't so much so

the efficiency in terms of performance,

but the efficiency in terms of leverage that you have

as a developer, and so I started thinking about it

in the way that Archimedes was referring to, like,

how fulcrums work, where, like, if you just give him

a proper place to stand, he can move the Earth,

and so that's sort of the focus of this talk,

is like, how to get the most leverage

as a developer, because a lot of Android teams

are fairly small, and you're asked to do a lot of things.

And so in my case, it would be if you give me a

a standing desk, I will write you an Android app,

and I hope that you're not expecting me to make

any more terrible jokes this entire time,

'cause it won't happen.

So, this is really just kind of a mish-mash of things,

there's no narrative, so I'm just trying to cover up

the fact that I have no transition here.

Let's talk about ViewGroups.

In particular, picking ViewGroups,

which ViewGroup are you gonna use for

any particular layout, and I think the main thing

is the simpler the ViewGroup you can get away with,

generally, the better, because the more complex ones

require a lot more maintenance, and you can run

into a lot more bugs, and so on the higher end of things,

I'd say probably RelativeLayout's one of the most complex.

ConstraintLayout is yet to be seen, but it looks like

it's probably going to be more complex

than RelativeLayout when it's finally done.

Somewhere in the middle of there is LinearLayout,

and then down there at the bottom is FrameLayout,

which is one my favorites, because it's so simple.

And there's a lot of other views in between,

but these are the main building blocks

for most applications.

So RelativeLayout and ConstraintLayout,

they sort of occupy the same space in Android right now,

which is that they position views relative to each other,

and RelativeLayout's sort of limited in this regard,

but it's what we've had since the beginning,

whereas ConstraintLayout is new and can do,

like, all these amazing things,

but there's some key problems with both of them

besides the fact that they're fairly complex.

One of them is that RelativeLayout is fairly slow,

and then the issue with ConstraintLayout

is that it's fairly alpha-ish at the moment.

They haven't officially released it yet,

So there's alpha out on Maven central, but a few times

they've completely changed the API around, so it's not

necessarily production ready.

I mean, you could play around with it now, and you could

use it if you want, but you're gonna end up with

some of that cutting-edge problems that you end up when

you're trying to experimental technology.

LinearLayout is great, stacking views vertically and

horizontally, you can distribute the weight, so this is a

simple view, so rows are stacked vertically, and then also

I distributed the weight between those

two spinners equally.

I'm actually fairly okay with nested linear layouts

as an opposition to RelativeLayout, and I actually,

last time I told someone this, this was like by far

the biggest question that I got, is everyone coming

to me later saying, "But I love my RelativeLayouts,

that's all I use,

I was then that nested LinearLayouts are the worst

things in existence and so I can't believe that

you just said that."

SO to head off that question that I was going

to be getting on the sessions thing, is that LinearLayouts

are sometimes slow.

So if you use layout wait, and you nest them pretty

deep, then they an get pretty slow, but that's only

a sometimes thing, whereas by opposition, RelativeLayout

always has to do two passes, it's always slow.

So the hope is that eventually ConstraintLayout

will be our savior and save us from the situation

of having to decide between the two of them.

But in the meantime, I think really what's most

important is just to focus on profiling.

So whatever layout that you do end up with just turn

on profile GPU rendering, and see if things are

running fast enough on whatever test device

that you're using, hopefully like

a really slow one.

And if you've never used profile GPU rendering,

I highly recommend Googling that and looking into

that, 'cause then you get these nice bars that

show you whether or not you're hitting

60 frames a second, and what sort of things you're

spending too much time on if you don't.

But really I talked about all that, so I can talk

about FrameLayout, which is my favorite layout in

the world, because it's so incredibly simple.

All it can do is position things based

on the parent bounds.

So that is, you can position things inside the center

of the FrameLayout, or you can position things on one

of the eight cardinal directions of the FrameLayout.

Wait, am I getting that right?

Yeah, eight.

So, but there's a lot you can do with this.

It turns out that a lot of layouts, if you just wanna

have like say, a simple progress bar in the center

of some large screen, like that's a FrameLayout,

you don't have to do anything complicated with

RelativeLayout or what have you.

It's also really great as a simple layout for overlapping

views, so if you need two views to be on top of each

other, FrameLayout is a great container for that.

It's also good for things like clickable item backgrounds,

so if you have some image that takes up a very small amount

of space, but if you wanna have multiple views that

compose a single thing that you click, it's good to have

like a FrameLayout as the parent of that, that can

actually have the click detection so when you click

on it, it actually looks like something is happening.

So a good example of this, like in the Trello application,

is the notification bar in the upper right corner.

So this always present on the screen, it's a single

FrameLayout, and there's a icon inside of it that,

that white icon is always present, and then if you have

unread messages, it'll put that little red thing

on top of it.

And so, the white icon centered and the red icon is

actually pegged to the upper right corner, but then

you can use the margin or to push it in so it doesn't

just ram up against the sides.

And on top of all of that, I can just have these views

be very simply positioned, and then pair with clickable

item background behind that, so when you actually

click on it something happens.

Another thing I really like using FrameLayouts for is

what I'm calling "toggle containers", so if you have

two different states that you toggle between, sometimes

you just have a single view that you actually change,

sometimes I've found it more handy to have multiple

views that you can switch between.

And so a FrameLayout's a good way to contain two things

in exactly the same spot, and then toggle between them.

So a good example of that in the Trello app is

the avatar view.

So this is whenever you represent a member of a card

or something like that, if the user has their avatar

Seth and we wanna show that, if they've never taken

a picture, then we wanna show their initials.

And so it's essentially choosing between an image

view or a text view.

Littler fancier versions of which that allow you to

render a circle, but basically lets you toggle

between these two.

So the avatar view brings up the next thing I wanna

talk about, which is view reuse.

We use this avatar view all over the application,

so these are just three screens, like the Trello

board, a open Trello card, some activity on the side,

and there's actually I think, three or four other

locations we use an avatar view within the application.

And so the question becomes, how do I reuse this

in multiple places without having to rewrite

the code everywhere, 'cause that would be kind of dumb.

So the most obvious way is to use

something called an include.

So if you've never seen it before, the include tag

allows you to point to a direct layout, and then it's

as if that layout was just copy and pasted into the

code right there.

And you can't modify much of what you're including,

but you can modify any of the layout params, that's

any of the things that starts with layout_, so that's

a nice way to be able to include something that may

have been may have been match-paired, but you don't

quite want it to be in the end.

But the problem here is that okay, you get the XML

in every single location, but you don't get

any of the logic.

So now I have to come up with some way to then apply

like, find these particular views that were in the

include, and then add the logic for actually

binding that to the view.

So what I actually prefer these days is

using custom view.

So with a custom view, I call, instead of include,

I actually just have the view in reference directly,

and then you need to write the actual custom view

itself, but it's not very hard, because this isn't

a custom view that's doing custom drawing or

anything like that, it's just taking the place

of what would have been in that include.

And so with this custom avatar view, I'm extending

Framelayout, so I'm saying the topmost is gonna be

a Framelayout, remember I'm toggling between

the two states.

I've got an image view and a text view, and then

inside of a constructor itself, it actually inflates

all the views that are underneath it.

So I don't need to, as a parent using avatar view,

I don't have to worry about what's inside of it.

It's handling all of that for me.

And then I can have this one nice bind method where

I take my member object and figure out whether I

should be loading an icon or loading the text.

So this makes my life a lot easier.

One thing worth noting though, if you're using

this sort of custom view setup, this is like

a very hand-wavy version of what would

be the included XML.

But if you include the XML like this, you end up

with a view hierarchy that looks like this.

You wend up with an avatarview on the top, it's a

FrameLayout, and then it inflates another FrameLayout, which

then has the text view and image view.

So obviously, this middle FrameLayout is pointless,

we don't really need it, the lint check in Android

is particularly harsh when you do this, something like

"has no reason to live" or something like that,

"has no reason to exist".