Whenever we start a new edition of the Android book, our first question is what you would expect: what new things do we want to put in the book? And for many books, that would be the start and end of it: you decide on the topic, you write the coverage of the topic. And then you’re done.

Things can be more complicated than that for us, though. I’ll use ConstraintLayout as a case to show why and how this is the case.

The Dream

Before we started working with ConstraintLayout, Chris and I were absolutely sold on it.
We had read blog posts about it, watched talks and believed in what it was trying to do.

ConstraintLayout is a replacement for RelativeLayout.
Now, we have always taught RelativeLayout.
It could do things no other layout can do.
We have never been big fans of it, though: It often performs poorly, and even if it performs well it’s still unreadable.

ConstraintLayout is supposed to fix both of these problems.
Its performance is comparable to RelativeLayout, but its constraint system is capable of so much more that you should be able to reduce nesting, which is a big performance benefit.

More importantly, though, ConstraintLayout was introduced to make real visual layout editing possible.
Visually editing nested LinearLayouts and RelativeLayouts wasn’t really a visual process, so much as it was a way of visualizing the XML you were tweaking and rearranging under the hood.
With ConstraintLayout, there is a visual metaphor of tying anchors to edges.
It corresponds directly to what’s under the hood in a way that was never the case for the old layout tools.

Some developers prefer the security and sense of control that direct XML editing provides, but I’m a believer in visual editors. Once you’ve gotten used to one and seen how much better it is to directly manipulate the resulting view, you can never be satisfied by mixed-mode editing again. I love Android, but iOS has always had a leg up on Android in visual layout editing.

Starting the Work

So here we are: day one of working on ConstraintLayout. “Maybe we should update THE ENTIRE BOOK to use ConstraintLayout.” Such is the mood when my coauthor Chris Stewart gets to working.

Five Minutes Later…

Five minutes later, the mood has utterly changed. Chris is shaking his head and sighing. “ConstraintLayout is horrible. Nobody should use it.”

This kind of thing happens. And it matters to us. When we write, we’re just like you or anyone else: we use a tool, we see how useful it is. If we love it, we ramp up our usage of it. If we don’t, we back off a bit. Data binding? Ramp it up. Loaders? Eh, let’s back it off.

In his initial take at working with ConstraintLayout, Chris had found that his experience just didn’t match up with his expectations. The layout he made visually ended up looking totally different when he ran it, and he had a beast of a time getting the visual editor to cooperate in the first place.

What to Do?

Our job is to dig deep into these tools and figure out the good way, the right way to use them, if there is one. That means digging into things longer and deeper than we normally would.

It’s not uncommon for us to disagree on this. That’s what happened here: Chris, having used the deal, hated it. I, having not used it at all, loved it. (Obviously, I was right.)

The push and pull in this case ended up in multiple passes on the ConstraintLayout chapter by both of us. We found that some of the sharper edges of the tool could be sanded down — they needed some more emphasis than they were given in the docs. And some of those edges were the result of the tool just having a different model for thinking about ideas we’d grown used to over time, like layout width and height.

The Final Result

Any good creative work is a sort of crash landing that happens between what you envision and what you can actually make. Did we put ConstraintLayout everywhere in the book like I wanted to? Well… no, we didn’t. Is it relegated to the back of the book? Nope, that’s not the case, either.

And I think that makes sense. Our book is a reflection of what we practice. Much as we loved playing with ConstraintLayout, we do not rely on it habitually yet. Until we do, until we believe in it enough to use it habitually in our practice, our book will not habitually use ConstraintLayout, either. And that’s the way it should be.

So that’s our third edition: a snapshot of where we are today. Hopefully, we’ll be lucky enough to have a fourth edition. Until then, though, you can expect that we’ll be pushing our own practice forward as much as we can.