As anyone who reads this regularly will know, I spend most of working day in XCode developing for Apple’s iOS and OS X platforms. However, I have had a long affinity for Java and am a fan of the Android operating system; I have a number Android devices including the fantastic Galaxy Nexus and the much less awesome Kindle Fire (more on those in another post) and have done some Android development both as a hobby and on a professional basis.
When I first decided to jump into Android I resisted Eclipse pretty strongly and ended up on IntelliJ. Things were going pretty well for a while. The code completion was nice and fast and the IDE had enough hooks into the Android tooling that I didn’t feel like I was at an efficiency disadvantage compared to Eclipse developers.
That all changed when a friend gave a me a look at the built in user interface builder that had recently been added to Eclipse. Interface Builder is something that I sorely missed in my Android tool-chain and up until then I had been using DroidDraw to fill the gap. That was a passable solution, but I still needed to spend a good deal of time editing layouts in XML and eventually I ended up just coding all of them by hand; this felt inefficient, so I caved.
I downloaded the latest version of Eclipse, read some docs regarding the IDE’s Android specific functionality, and abandoned my trusty IntelliJ. Right off the bat I was disappointed in the layout tool. It is no Interface Builder and I still felt that working with the raw XML was easier than working with the tooling.
Still, I soldiered on for about a month and tried to get into the Eclipse mindset. More and more I became increasingly frustrated with Eclipse. One of the biggest issues that plagued me was the inconsistent code completion / suggestion; most of the time the tool didn’t make any suggestions until after I had finished typing a line of code. I am not sure if this is to do with the Eclipse ‘content assistance’ engine, since the IDE was running pretty slow overall on my machine; I was running a 2011 Macbook Pro with an i7 and 8 gigs of RAM, which one would think would be more than adequate for running an IDE. I have been told but have not been able to confirm that these performance issues do not exist on Windows, so take that for what it is worth.
Of course, there are some things that I really like about Eclipse. To start, it is a great example of an extremely successful open-source project. I love that it is highly extensible and that additional functionality can be added at no cost; one of the reason that I wanted to evaluate Eclipse is that some of the additional functionality I wanted in IntelliJ requires the paid version. Eclipse make the Android Market submission process a matter of clicking through some simple wizards; on IntelliJ, I have to drop to Terminal and do the signing from there, which can be a little confusing the first few times that you do it and is not nearly as efficient as simply clicking a button. On the same line, Eclipse seems to keep track of your signing keys for you, however, it does not back them up, so be sure that you do that; if you are unlucky enough to lose the key that you signed a Market app with, then you will quickly find that you cannot update your app at all. Period. Probably my favorite aspect of working with Eclipse is the community. There are tons of tutorials and every community member that I have contacted in IRC has been more than gracious in helping me get productive with the tool.
At the end of the day efficiency is what really matters to me, so I am going to revert back to using IntelliJ and I am going to be evaluating purchasing the commercial version of the product; stay tuned for a post on that in the coming month or so. Also, if you are interested in developing on Android and do not have your tool-chain set up yet, I recommend that you give Eclipse a look; this goes double if you are new to developing software or the Android platform, since most of the tutorials for Android assume that you are using Eclipse.