June 2014 Archives

Android Studio's Killer Feature

| No TrackBacks

When Google announced Android Studio, I was highly intrigued. I've spent years of my life in Eclipse, and my secret hope has always been that sometime before the heat death of the universe, we'll get a better IDE for Android development. (I'm not here to drop a truth bomb on Eclipse's flaws; hating Eclipse is like hating gravity at this point.)

As an experiment, I began using Android exclusively on my side projects at home. I've grown to like it quite a bit: it has a nice layout editor, I like the refactoring support, and I have fewer issues with IDE stability. However, the part of Android Studio that I like the most is its integration with Gradle, the build tool. I did not expect this.

In my previous big Android projects, I've always had two separate build process. There's the build process within Eclipse itself, used for compiling and execution as an engineer writes code. Then there's this separate build process, usually driven by ant, to create build artifacts; these builds are often part of a continuous integration pipeline and used for testing/submission. (Sure, you could simplify by mandating that everyone builds everything all the time with ant. Here's the problem with that: Eclipse is right there! It's taunting us with its fast, easy builds.)

Two build processes is problematic because they need to generate the same binary. That's not easy; every time you tweak your class path or a dependency in Eclipse, you need to make the equivalent change in your build.xml. I've never found a good way to automate this, or a forcing function for synchronizing these build processes manually. As your project gets bigger and you take on more dependencies, entropy does its thing and inevitably the build processes begin to diverge. This leads a lot of problems. QA finds a mysterious crash in the APK created by ant, which no one can reproduce in Eclipse. We change the classpath in Eclipse, then ant fails and no one realizes it until QA threatens us with pointy sticks. Working through these problems is a waste of everyone's time.

Android Studio has a great solution, which is that it uses Gradle, a first-class build system, for builds within the IDE. Need to create an APK for QA? Just use the exact same Gradle command on the command line. All of your app's dependencies and all steps within the build process are thus made explicit via your Gradle config file. There is one and only one build to rule them all.

Could you do the same thing with Eclipse? Maybe. There is a Gradle plugin for Eclipse; I spent a few hours of quality time with this and made very little progress. I can't imagine integrating that plugin across a large engineering team without a lot of cursing and adult beverages.

I think this choice in tooling is pretty indicative of the difference between Eclipse and Android Studio. With Eclipse, you can do anything, given you get the configuration right. The odds of this occurring straight-away are low. In Android Studio, the defaults are much smarter, obviating the need for much of the configuration. It's convention over configuration all over again.

About the Author

The Art of Delightful Software is written by Cody Powell. I'm currently Director of Engineering at TUNE here in Seattle. Before that, I worked on Amazon Video. Before that, I was CTO at Famigo, a venture-funded startup that helped families find and manage mobile content.

Twitter: @codypo
Github: codypo
LinkedIn: codypo's profile
Email: firstname + firstname lastname dot com