Google Android Studio Vs. Eclipse: Which Fits Your Needs?

Nerval's Lobster writes "Google's Android Studio is a development tool for Android based on the IntelliJ IDEA platform, one that managed to attract a lot of hype when it rolled out in mid-2013. Roughly a year later, the platform is still in 'early access preview,' and work on it is ongoing. Eclipse, on the other hand, is the granddaddy of IDEs; although it doesn't offer native Android support, it does have some nice tools to help you build Android applications—one such tool is the Google Plugin for Eclipse, made by Google. Developer and editor Jeff Cogswell compares Eclipse and its Google-made Google Plugin with Google's own Android Studio, developed with the help of the people who make IntelliJ IDEA. His verdict? Eclipse is beginning to show its age, especially when it comes to Android development, while Android Studio offers some noted benefits. 'Android Studio is still in preview mode, without an official release, even if that preview is in pretty fine shape—its status certainly shouldn't prevent you from using it, at least in my opinion,' he writes. Do you agree?"

Comments

Not surprising

[Shados]

I haven't done Android development, but IntelliJ IDEA has been ahead of Eclipse for ages, so this isn't surprising.

Eclipse was a good IDE (relative to others) for a brief period of time early in its life, give or take 10 years ago (i think?), and that was it. Everyone else quickly caught up, Visual Studio was brought up to speed (with plugins at least), IDEA came into the spotlight, and the only reason Eclipse was still popular was because it was a) it was free, b) people learnt it in school, c) people didn't even realize there was better IDEs out there for Java (and other non-Microsoft languages).

Re:Not surprising

[metamatic]

Yup, I switched from Eclipse to IntelliJ IDEA for my regular Java development as well as Android.

It's faster, leaner, more helpful, and has a far less cluttered UI.

I just wish it wasn't $199, I'd totally buy a personal license for $99. (There's zero chance of my employer buying it for me.)

Wait

[ArcadeMan]

What's wrong with notepad?

Re:Wait

[kthreadd]

...by writing it in Emacs.

Horrible article

[AuMatar]

With a very biased verdict. Giving Android Studio the edge because of Gradle support? That's great- if you want to use gradle. I don't. I don't even know what it is- before Android Studio came out I'd never heard of it. And I have better things to do than play with build tools unless it offers a huge advantage- which it doesn't. The fact its impossible to use Android Studio without switching is a negative, not a positive as Eclipse supports both. The edge here should go to Eclipse for giving you choice between build systems.

UI? The UI that you know is better than one you don't- always. If I have to spend even an hour finding new options, that's an hour I'll probably never make back. Eclipse has lots of flaws, but I'm used to those. The real advantage here is Eclipse if you know it, or draw if you don't.

Basically his argument seems to boil down to he likes new shiny stuff. No thanks.

Re:Horrible article

[stewsters]

Intellij supports both, I used a non-gradle build last week. Not sure about the Android Studio version, but I can imagine it's possible, just not the default in the basic project setup. That being said, gradle is nice if you have a lot of dependencies in maven.

Re:Horrible article

[farble1670]

Both ANT and Maven represent your build script as huge horrific XML files

you are really going to pick your build system on how pretty the script is?

yes, because the most important thing to me in a build system that my build scripts be as few characters as possible, right? the only thing that matters is stability and lots of good examples of how to do things you want to do.

That and ANT is goddamn slow.

ant was lightning fast compared to gradle. and yeah, i know because our company has fully cut over from eclipse + ant to android studio + gradle.

it takes nearly 30s to build just one of our android apps. upgrading from gradle 1.6 > 1.8 > 1.11, each upgrade has considerably worse performance, despite the docs claiming to have improved performance. gradle 1.11 is so much slower than 1.8 it's ridiculous. i can't even believe it was released. it does however give a progress indicator during the build now. great.

Migration is not easy

[z4ce]

The eclipse "export" to gradle function barely works. Importing an eclipse project into Android Studio doesn't really work either. If you create a build.gradle file, that gets you further along, but things in Android Studio still behave funny especially with identifying the "modules." In the end, if you're looking at migrating I strongly recommend just creating a new project and copying your source and resource files into the latest android file structure and gradle build system.

Did my last project entirely in Android Studio

[maccodemonkey]

I liked it better than Eclipse, no separate Android SDK installation/package manager to maintain. I just download and it worked. The UI is a little nicer.

However it doesn't solve my big complaints about Android IDEs in general:
1) Native code development still sucks. It sucks less on Eclipse (as in it exists at all on Eclipse), but it's a pain to set up, a pain to use, and a pain to debug. I actually just gave up on it attaching the debugger, and starting adding logging to me native code. Seriously Google, if you want me to start taking Android seriously for developing big performance sensitive things, some decent tools for C/C++ development would be good.
2) The build system... I don't know what's up with Android Studio defining it's own project format, and then on top of that adding a build system with build system files beneath it. I still have projects that open and build, but tell me the build system is set up wrong. The one thing I like about Xcode is the project and the build manifest are the same file. I'm not maintaining a project that then manages some Gradle config or something. I mean, if I want to I can add an external build system to Xcode. But most of the time I don't need that level of build management. If Android really wants to go the external build system route, just automatically generate the stuff I need every time I hit build so I don't have to worry about checking it in to source control. I don't care if it's spinning an Gradle config off just as long as I don't have to see it and worry about it. If I want to manually grab a Gradle config to throw at some other build system, make it optional.
3) The analyzer tools compared to the iOS toolchain just aren't anywhere near good enough. The data the tools do give back out is presented poorly compared to Apple's Instruments tool, and I've never gotten the tools working for native code, which is usually where I spend the most time caring about performance.
4) This isn't as much a complaint about the tools as much as Android, but Android is just behind in general on performance toolkits. Apple has a great NEON optimized toolkit in Accelerate for DSP and image work. There is no equivalent on Android, although 5 years in, a few open source projects are finally starting up around putting together a NEON accelerated library of functions.
5) x86 Android Emulator with native GPU support. It exists, but it's usually not as well maintained. There are some third party tools trying to fill that gap, but c'mon guys. That's a basic necessity. An ARM based emulator is great for simulating actual ARM calls, but most of the time I'd rather be in the x86 emulator.