Interview with Tor Norbye: the Present and the Future of Developer Tools for Android

Andrey Cheptsov

Two months ago Google rolled out Android Studio, their brand new IDE for Android developers. The new IDE, built on top of IntelliJ IDEA Community Edition, has replaced ADT, a plugin for Eclipse, changing “developer experience” for millions of Android developers. As a member of the IntelliJ IDEA crew, I couldn’t miss a chance to discuss this “small revolution” with one of the Googlers behind it – meet Tor Norbye.

Andrey: Before joining the ADT team at Google, where you’re working with Eclipse, you’ve also had quite a lot of experience with NetBeans at Sun Microsystems. I’m sure you know a lot about building tools for developers. Right now you’re working on Android Studio, a new IDE designed for Android developers, which is based on IntelliJ IDEA Community Edition.

Tor: That’s right – I’ve worked on developer tools for the last twenty years!

Andrey: Can you please share your impressions of Android Studio: what do you like about it, and what do you think makes it special and different from Eclipse and other IDEs? And, of course, we’d all like to hear your version of why IntelliJ IDEA became the final choice for building Android Studio on?

Tor: IntelliJ IDEA was a very popular IDE among the engineers on the Android team, so when we set about rebooting our tools approach for Android to building a whole IDE rather than just a plugin, and wanted to have a best-of-breed code editor, IntelliJ IDEA was an obvious choice. And it didn’t hurt that IDEA already had good Android support for us to build on top of — and was working on Gradle support, another critical component for our IDE plans.

There are many things I love about the IDE, but my favorite is the “smarts” of the editor. Code completion usually finds just what I need, and quickly – which means that I rely on it for typing speed, not just to explore unfamiliar APIs as I used to in Eclipse. This code awareness permeates the whole IDE – cross language refactorings, smart variable name suggestions, and clever code inspections. I’m embarrassed to admit how often I’ll look at code I’ve just written where the IDE is pointing out mistakes – sometimes subtle ones, where for example it has tracked values through a whole method and has concluded that a particular condition can never be true.

Andrey: What is your primary focus when designing a tool for mobile developers?

Tor: The overall goal is to support developers taking full advantage of Android’s SDK, writing beautiful and stable applications that work across a wide variety of screen sizes, languages, versions of Android, and so on.

We plan to make more visual tools (both for UI design and performance tuning), but up to this point we have focused on editing and compilation, and especially compilation.

Building an Android app can be complex. First, there are a lot of different tools involved in the various stages of the build – the resource compiler (which creates generated classes needed during compilation), PNG crunching, RenderScript compilation, AIDL compilation, ProGuard shrinking, dex conversion, and so on. Second, mobile apps have a lot of unique needs that you typically don’t run into for desktop and web apps. For example, many developers want to create multiple variations of their app (e.g. a free version and a pro version, where most of the code is the same, but the set of resources and library dependencies may vary). And there can be multiple dimensions of this – free versus pro, debug versus release, high density assets versus low density assets, different versions for different ABIs when using native code, and so on.

To solve this, we’ve created a build plugin for the Gradle build system to build Android apps – with features such as product flavors and build types, signing configurations, manifest merging, code and resource shrinking, APK splits, and more. And then of course there are many other features we get from Gradle itself, such as the ability to declare dependencies on libraries and then have the build tool automatically download and manage those dependencies.

A critical part of this is that we use the Gradle build system in Android Studio too. We used to maintain multiple build systems for Android: The Eclipse one, the ant one, and there’s also a Makefile-based system which for example was used to build the Android support library. This was difficult to maintain, and the build system implementations had slightly different capabilities and behaviors. And as soon as users customized the ant scripts (which many users did, for example to generate variations of their APKs), the build systems could vary widely and show inconsistent results.

For Android Studio we wanted to avoid this, and to ensure that not only do developers have a clean way to customize the build (using the Gradle DSL), but that both the command line and the IDE would treat this identically. We’ve added some basic support in the IDE to understand some of these build system concepts. (For example, the build system allows you to override resources across product flavors and build types, and to create resources dynamically, and when you use “Show Documentation” on a resource in the editor, we show you all the various declarations in override order, to show you which values are masked and which value “wins” for the current variation.)

We’ve also put a lot of effort into adding additional inspections, to help flag Android-specific code problems. IntelliJ IDEA already has hundreds of checks for general Java problems, but for mobile, and for many Android specific APIs, there are many extra guidelines to follow to ensure that the app is correct, performant, secure, and so on.

Andrey: Tell us maybe about a few other cool developer tools from Android Studio that you’re working on. How is Android Studio integrated with Google Cloud services?

Tor: We have dedicated support for Google App Engine and Google Cloud Endpoints, via dedicated plugins, such that you can create backend modules, run and debug them locally and deploy them to the App Engine, etc. (see https://cloud.google.com/mobile/ for more).

There’s more in the works, but we generally don’t talk about future plans.

Andrey: What is your favorite feature in Android Studio?

Tor: Oh, that’s a very difficult question to answer – it varies!

But I’ve always been passionate about static analysis and features which automatically identify bugs, especially in nontrivial ways, so it would probably be the plethora of code inspections. If I have to name one in particular, it would probably be the API check, which ensures that all calls (and field references and resource lookups) are available on all versions of Android that you’re targeting. The safest way to do this is of course to compile with the SDK from the oldest version, but that has some significant downsides – such as not being able to conditionally access more recent APIs and features (or if you do it, to use Reflection, which instead of “strong typing” gives you “string typing,” where you are potentially trading off one type of crash for another.) So with that inspection, you can always compile with the latest SDK, yet have the IDE warn you if you’re unconditionally calling APIs that are not available for all your users. And when we integrated this lint check into the IDE, we were able to make it a bit smarter by using the IntelliJ Platform PSI APIs, such as filtering out calls that are already inside version checks.

I have many other favorites – the code folding feature in the editor (where anonymous inner classes and simple getters are compacted into a terser format), and the debugger which as I’m stepping looks at the source line, figures out expressions I’m about to step over and adds a temporary watch showing me the value. And both of these features have even been enhanced in the new version of IntelliJ IDEA (14) to be even better – inlining parameter names in calls, and overlaying debugger values directly in the source editor. I’m really looking forward to merging those features from IntelliJ IDEA 14 into Android Studio as well!

Andrey: As a developer who has switched from Eclipse to IntelliJ IDEA, can you please describe your experience? Was it difficult? Was it worth it? There are people out there who are in the middle of the same process right now. Could you maybe give them some pointers on what to do and what to avoid?

Tor: I’ve gone through many primary IDE changes in my career – and I think it’s similar to the process of learning to speak a foreign language: the hardest jump is from your first language to your second. At first, the IDE will feel foreign, and “rewiring” your muscle memory does take a few weeks. It might also feel like a net negative at first, since you notice the things that are missing from your old workflow, and you’re not aware yet of the new things you’ll come to rely on.

For example, in Eclipse, many refactoring operations are offered as quick-fixes, such as Extract Method. In IntelliJ IDEA, there are dedicated refactoring operations for that; you can just invoke Refactor This, or once you become proficient with the IDE you just know the different keybindings – there’s actually an Extract action that takes a second keystroke ‘c’ for constant, ‘m’ for method, ‘f’ for field and so on. Arguably it would be even more discoverable if every single thing you could do to a selected identifier was exposed in the quick-fix menu, but the set of possible actions is so large that it wouldn’t be practical, so instead the intentions are focused on the context-specific ones. Once you get used to the differences and find out how to get things done in the new way, the migration pain goes away.

The workflow is pretty different; the window management is quite different, and you get used to compiling rather than looking at the Problems view for errors. This issue is specific to Android Studio; IntelliJ IDEA does offer a Problems view, but in Android Studio, since we only support building with Gradle, we’re currently not able to immediately offer a global set of errors, since build plugins have a lot of freedom in how they can affect compilation.

When you’re trying out Android Studio, you may want to use Eclipse keybindings such that you can get comfortable right away as you’re exploring the basic features of the IDE. However, as soon as you’re getting serious about migrating, I would strongly encourage you to *not* use Eclipse keybindings, and instead use the native IDE keybindings. These have been designed to work well together, and are more likely to work correctly and without conflicts in future updates, with third party plugins, and so on.

Andrey: Building a top-notch developer tool like Android Studio, you (at Google) now have more experience with IntelliJ Platform than anyone else outside of JetBrains. What are your impressions with it so far?

Tor: I really, really like it. The APIs are very clean (though they could use more documentation on some of the APIs, hint, hint… :-). The APIs for language support (PSI) are brilliant; it makes it a breeze to not only operate on the semantic model the IDE has for code, but to add new languages and cross language refactoring and navigation support.

And, unsurprisingly from JetBrains, the tools support for plugin development is very good too. Not only does refactoring operations and code navigation work for plugin extension registrations, but there are also plugin-development-specific code inspections which help you do the right thing, for example making sure that your code is always using the IDE theme-aware Swing widgets rather than the default Swing widgets.

Andrey: Now, when Android Studio 1.0 has been officially released, could you tell us a little bit about your further plans? What are you working on now, and what does the future hold for Android developers?

Tor: Right now we’re putting the final touches on Android Studio 1.1, which is really just a bug-fix release (with a few small features). But most of our effort is directed towards Android Studio 1.2, which we hope to ship sometime in the first half of the year, where we are migrating Android Studio from the IntelliJ IDEA 13 codebase, over to IntelliJ IDEA 14.1. We’re also working on new features and other architectural improvements, including accessibility support. Google put a lot of work into supporting accessibility in Android, and we want to make sure developers using accessibility tools can also be productive with the IDE. There are many other features in development for upcoming releases as well, but I don’t want to spoil any surprises :-)

Andrey: Thank you, Tor!

Subscribe to IntelliJ IDEA Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!