Why Android Studio looks very promising (a hands-on review)

After using the Android Studio Early Access Preview for 48 hours, William J. Francis walks you through the install, some surprises he encountered, and more.


Unlike previous years where Google I/O focused heavily on what cool new technology was coming to the end user, Google I/O 2013 seemed to put a lot of focus on better enabling developers. Highlights included improvements to Google Play, various Google web services, and a new app development kit called Android Studio.

The latter really grabbed my attention. After having spent many years using Microsoft's Visual Studio, no matter how much I want to like Eclipse, I can't get there. I appreciate what Eclipse represents -- that is, a remarkably flexible IDE that runs on every modern operating system. Still, when I layer onto it all the tools I need to develop Android applications, it feels clunky at best, and many times slows down my productivity.

Android Studio is based on IntelliJ. Prior to Android I was a C/C++ guy, so I didn't know a lot about Java development tools going in. However, when I talked to my colleagues who were Java savvy, many of them swore by IntelliJ's IDE. I've stuck with Eclipse all these years simply because it was Google's recommended and official Android development environment. Now that there are two development options Google has endorsed, I spent the last 48 hours trying the Android Studio Early Access Preview.


I have Eclipse installed on a Windows 7 box, my MacBook Pro, and an Ubuntu PC. While I tend to bounce around between these machines when I'm doing Android development, I usually find the tools tend to behave better on the MacBook. So to give Android Studio the best chance at impressing me, I installed it on my Mac.

The installation process is exactly what you'd expect on an Apple OS. You download the DMG, double click it, and drag it to your Applications folder. When I first started doing Android development four years ago, installing Eclipse and configuring it for Android meant jumping through all sorts of hoops. You had to download Eclipse, the Android SDK, and the ADT. But in the last year, all that has changed. With the introduction of the ADT Bundle for Eclipse, the process is pretty much identical to that of the new Android Studio -- quick and painless.

Figure A

Android Studio splash screen.

Some familiar faces

The IntelliJ Android Studio has a lot that will look familiar to anyone who has been doing Android development. The SDK manager, the AVD manager, the Process Monitor, DDMS, and ADB are all present and accounted for. You will also see some of the late additions to the Eclipse/Android offering, like the drag-and-drop layout manager and the integration of the icon asset tool in the new project wizard (Figure B). Figure B

Android Studio's new project wizard.

The new project structures, configuration files, and keyboard shortcuts will take some getting used to if you have been using Eclipse exclusively for your development efforts. When I started using Eclipse, it drove me bonkers that single stepping was done with F6 rather than F8. I'd been debugging with F8 in Microsoft's and Borland's tools since the early '90s. IntelliJ follows the F8 paradigm. But after four years I've finally gotten used to F6, and so over the weekend I was constantly trying to retrain my brain. Not that this is a big deal.  Like anything new, it just takes some getting used to.

A pleasant surprise

One welcome surprise was that even though Eclipse and IntelliJ use different configuration files for projects, Android Studio was able to import my existing Android projects I'd done with Eclipse by recognizing the Android source files and building a new configuration around them. In fact, I tried importing several projects and all succeeded. I think this is a big win and will go a long way to encouraging adoption of Android Studio.

Figure C

Android Studio landing page with import project option.

A not so pleasant surprise

My biggest complaint about Android Studio is a problem I ran into while trying to create a new project over the weekend while sitting at a coffee shop. I had not yet connected to the Internet, and to my surprise, I received an error message from the new project wizard (Figure D). Figure D

It seems creating a new project in Android Studio requires you to be online.

After I clicked OK, I was taken back to the landing page. After a bit of trial and error, it became apparent I could not create a new project without an Internet connection. Furthermore, each project I had tried to create and failed left some remnants in the workspace that had to be manually cleaned up.

As is evident by its Chromebook push, I realize Google believes everyone should be online all the time, but this is not yet reality. Whether the Internet connection requirement will change in the final release of Android Studio is yet to be seen. I will be keeping my fingers crossed.

Final thoughts

While it is still an Early Access Preview, Android Studio looks very promising. It has a modern feel that Eclipse lacks, is generally more responsive, and integrates flawlessly with baked-in plugins like ADB and the SDK manager (Figure E). It's not perfect, but it feels like a major step in the right direction. Figure E

Debugging in the new studio has a modern look and feel.

When working with Android and Eclipse these past four years, I always felt like I was developing with a tool that had been adapted to work pretty well for something it was not originally purposed for. With Android Studio, it feels like a tool designed from the outset with Android development in mind. I know this is not the case, as IntelliJ was around long before Android. Still, give it a try, and I think you will see what I mean. Even in this early stage, it has a polish that is missing in its Eclipse counterpart.

Also read on TechRepublic: Android Studio can fix Android development


William J Francis began programming computers at age eleven. Specializing in embedded and mobile platforms, he has more than 20 years of professional software engineering under his belt, including a four year stint in the US Army's Military Intellige...


If the internet goes down... The phones go down (VOIP) Email is down Interoffice connections, including databases are down What am I going to work on? Righting comments in my code?


My grandfather, despite not having stayed in school past 12th grade, was one of the smartest and most well-read people I've ever known. If he used a word or a term we didn't understand and we asked him what it meant, his response was always the same: He would hand us a dictionary and say, "Look it up - it'll be yours forever." By that he meant that by expending even a few seconds' extra effort to look the word up it would be indelibly burned in our brains, which likely wouldn't be the case if he simply told us the word's meaning. To borrow an old adage - The older I get, the smarter he gets.


I think this is a pretty safe assumption for a developer that they will be online.


I read articles on TechRepublic on subjects for which I have little understanding or pre-knowledge in the hope that I can continue to round out my general IT awareness. I'm sure I'm not alone in this. One of the hurdles I have to get over when doing this is the difficulty caused by the constant use of acronyms and abbreviations by authors who seem to assume everybody knows what they mean. In my case, sadly, this simply isn't so. In this fragment, for example, "The SDK manager, the AVD manager, the Process Monitor, DDMS, and ADB ", the only one I recognised was SDK with any certainty (because it has been around for so long and is in general use across various technologies). Can I beg that your technical writers follow what was traditional best practice in writing where the first time something is used, product name or whatever, it is spelled out in full with the accepted acronym or abbreviation included next to it in brackets. After that the shortform can be used in place of writing the term out in full. Many thanks.


I've been in to Java for 10+ years and have been using Netbeans for most part. I've used eclipse as well but felt that it lacked the responsiveness & polish of Netbeans. Tried Andriod studio yesterday & am right at home with this IDE. Your last line sums up my opinion about Andriod Studio "Even in this early stage, it has a polish that is missing in its Eclipse counterpart."


And how many of the shortforms I didn't know can be found in a dictionary; say, Webster's or the Oxford Concise? Words is one thing and if they aren't neologistic a visit to Google to "look them up" is in order but shortforms will have many synonyms and it's really up to the author to make sure his readers know what he means reliably.


From what I could tell one only need to be online with the current version of Android Studio when creating a new project. Once created it seemed I could open and work on the project without connectivity. Annoying but not a show stopper.


The assumption of omnipresent internet connectivity is a pleasant fantasy, but is an oppressive policy for software use in the real world. A user or a developer might be working within a vehicle, at a remote location, or at a normally connected location where some unplanned event occurs. Consider my own too frequent experience at my Silicon Valley location, presumably at the heart of connectivity: some bozo crashes his vehicle into a utility service pole several blocks from my home. My electrical power is fine, but the power to the local internet service provider's equipment is knocked out for much of the day. Should I have to stop doing productive work in my home? Of course not. Also consider hurricanes, typhoons, rail crashes, floods, chemical explosions, terrorist perils, and other events of recent news. Try calling cell phones and corresponding by email with typical residents of Moore, Oklahoma, even in the parts that weren't leveled by the recent tornado. Should an undamaged developer have to stop working because of software's artificial and unnecessary connectivity constraints?


Fair statement and I will try to be more diligent with acronyms and abbreviations going forward. For the record AVD stands for Android Virtual Device, DDMS is the Dalvik Debug Monitor Server, ADB is the Android Debug Bridge, and as you already know SDK stands for Software Development Kit. Thanks for the feedback! We really do read the forum posts and take reader comments to heart.

Editor's Picks