It’s been two years coming, but the first edition of Android Programming: The Big Nerd Ranch Guide is finally almost here. Brian and I got our hands on the first printed copies only a few days ago. We were indecently excited. Nobody wet themselves, but it was a near thing.

For those who don’t know, our guide to Android programming is the fruit of our Android bootcamp, a five-day intensive course that takes you from knowing Java to knowing Android. With our book, you can do the same thing at home. It’s like a Big Nerd Ranch home hair dye kit.

Two years is a long time! When we taught our first class with the materials that would eventually grow into this book, they were based on the latest and greatest phone OS, Android 2.3. Honeycomb had just been released, with a whole slew of new features and changes.

So what’s happened between then and now? Well, we taught a lot of classes, for one. When our students read through it, we found that many things we wrote in that first book just didn’t work, so we cut them down, threw them out or rewrote them. More than anything, though, we worked on one thing: fragments.

Fragments

When fragments first appeared in our book, they were second-class citizens. Fragments were for Honeycomb; Honeycomb was strictly a tablet release. Our students were much more interested in phones than tablets. That made fragments a low priority. Off to the back of the book they went!

However, a couple of things caused us to change our minds about their importance.

Hands-on Experience

The first was our consulting work. We had the opportunity to tackle a few tablet-only projects. The experience gave us a good excuse to jump head-first into using fragments in the real world.

In that work, we learned that fragments are actually pretty useful. Activities come with a lot of baggage. Once you switch over to a fragment instead, you find yourself free of those restrictions.

It also gave us questions that would nag at us: When should you use a fragment? When should you use an activity? The more we worked with the fragments, the more we wanted to pin down the answer to that question.

The Support Library

The second was the Android Support Library. This library was first introduced immediately after the release of Honeycomb, but it was fairly low-profile to start out with.

The importance of the Support Library is hard to overstate. The changes in Honeycomb were huge—almost all the fundamental APIs in Android were altered. Yet to this day, a majority of Android devices run pre-Honeycomb versions of Android. Without the Support Library to bridge the gap, it would be impossible to write real-world apps that use any of the new Honeycomb features at all.

As time passed, the Support Library became more and more fundamental to modern Android development. Luckily, it also became easier to use—nowadays, it is included in the default Android project template. All you have to do is remember to choose the right version of Fragment, and subclass FragmentActivity.

What We Teach

We decided on a fragment-first approach. Good Android apps should write most code in fragments, and only write code in activities to manage where those fragments live and how they talk to one another. Don’t need multiple fragments? Then your activity will have just one fragment.

This isn’t an earthshaking new perspective, of course; it’s best practice. We’re excited to show everyone how to do it, though, whether you’re brand new to Android or you’re looking to pick up the latest and greatest new tricks.