So... this is tender ground to be treading (holy wars).
I am a strong believer in your tool feeling good to you; it is the environment you create in. The better it feels, the faster and more cohesively you will work (within reason).
That being said, I'm comparing Eclipse+ADT to IntelliJ. I have no opinions on alternative home-brew solutions that are a combination of editors and command line.
For Android development, you'll want the following things:
- Strong Java editor support
- Strong Android UI support
- Strong debugger support
- Strong deployment/emulator integration
- Support for whatever Android version you are targetting.
The two IDEs in all those areas are damn near similar, except...
ADT 12 just added a slew of nice, Android-specific context-sensitive content assists that are really damn nice.
In addition, ADT 12 jumped the visual layout designer forward in a big way with accurate component rendering in preview as well as support for custom components[1].
I think something worth considering is that Android support is a feature, among 100 other, that the core IntelliJ team develops, support and extends.
ADT is the official, Google-driven effort to develop and expand their Android tooling on the Eclipse platform. The ADT team isn't distracted by things like autocomplete support, classpath scanning, project formats, etc... all they do is develop Android tooling directly ontop of Eclipse.
I would expect that the ADT tools continue to be more robust and outpace competitor implementations.
I would also point out that the ADT team has some seriously fantastic developers on it; if you are the type to enjoy high level "new feature" overviews of IDEs, check out Tor Norbye and Xavier Ducrohet's presentation at Google I/O 2011 showing off a lot of the new features in ADT 12[2].
I realize up to now it has sounded like I'm an Eclipse fan, but I am just a "tools to get things done" fan.
As someone who is interested in Android, but is currently being scared off by Eclipse, does anyone know any good resources for developing for Android in something that isn't $BLOATED_JAVA_IDE?
I tried vim, but the command-line builds were horribly slow, and almost all documentation and tutorials I found expected me to be using Eclipse.
Using a popular internet meme, "I don't always code in Java but when I do, I prefer IntelliJ".
Seriously, give IntelliJ IDEA a try. Personally I think it's a lot nicer and snappier than Eclipse. It has a free edition. You might still decide that you don't like it but I think it's definitely worth a try. Also, the last time I checked (which was years ago, admittedly) it worked with Android perfectly.
Why is command line deployment horrible? Write some scripts, copy stuff with ssh, etc... I continue to be horrified at the refusal of modern app developers to write code to help them write code.
Except it clearly doesn't. For the use case in question, an IDE can build a .apk and install it on a single connected device. Can you run it in the same step? What if the app has a 10MB data set and takes 8 seconds to install, can you optimize that by copying only the binary? Can you wipe the data from the host machine? How about install a known data set for a test? Install on 5 devices and run a test suite without manual intervention?
Every one of these is a valuable optimization for some workflow somewhere. All of them reduce the compile/test cycle by seconds or minutes, speeding development. NONE of them are done by any IDE I'm aware of.
Seriously: write code to help you write code. If you aren't doing this, you probably aren't writing good code. And if you gave that answer in an interview, I for one wouldn't hire you.
How good is code completion in VIM for Android apps? I was an emacs guy for many years but since I started doing iOS I can't imagine writing Objective-C without really solid code completion. Maybe it's less necessary in Android?
Because you're writing Java, which is a very verbose language, all code completion and code generation (method stubs, auto constructors etc.) are a godsend when working with Android.
That's why I'm always wondering why anyone would so much want to waste time with typing Java on VIM (even though I DO use Vim for other programming tasks) instead of just using an IDE specifically customized to make such development faster and easier.
A few years ago I was having lunch with some of the guys from Franz Lisp and one of them said that his epiphany was that Java did have macros, but that they were write only and built into the IDE. I didn't really appreciate his insight at the time but I get it now.
I do all my Android dev in VIM, and I use ant on the command line for building... what do you find horrible about the command line build? I just use 'ant debug' for debug builds, and 'ant release' for release builds - and 'adb install -r' to install the package once it is built. Usually, it ends up being a couple of up arrows, and enter, on the command line to build / deploy.
Funny, that's exactly what I do. Eclipse for building and debugging; Vim for coding. It's a pretty happy combination especially considering that the switch between perspectives is, for me, much more disorienting than the switching between two applications [I feel lame saying this, but the perspective change is really disorienting for me...].
May be I have been doing it the wrong way all along. I've used 'ant install' for build/deployment. Is that a horrible way for deployment? Does Eclipse deploy it faster?
As someone who uses Eclipse pretty regularly, what don't you like about it? I'd never really used big IDEs before I got into Java either, so I'm curious.
Well, for someone that uses VIM/Emacs heavily, Eclipse might be fine as an IDE, but I don't like to use it as an editor. When I'm using eclipse to edit code, I feel like I'm using microsoft word -- user friendly, but not "coder" friendly.
Also, try using eclipse on very large projects -- it gets very slow. Sometimes I'm not sure if eclipse is hung, or if it's still stuck compiling something or fetching something in maven.
I too, would definitely recommend sticking with eclipse for now. When you really understand all the different steps of the build you could switch to emacs/vim + cli tools, but since it's pretty undocumented there's no reason not to stick with eclipse and do some work while you're figuring it all out.
are people complaining about eclipse because it starts up slow ? After initial startup, what are the issues that cause this person to be scared of using an IDE ?
Eclipse is frankly a poor text editor. After learning enough Emacs to get comfortable, it becomes clear that there is a better way. For example, undo. In Eclipse, type something, undo it and type something else. Now you can't use the undo/redo function to get the first thing that you typed back. In Emacs, you can, since undo is an undoable operation. Similarly, having things like i-search, align-regex and rectangle editing have become vital for editing code. These things either do not exist, or are difficult to discover or use in things like Eclipse.
people claim that Eclipse IDE is slow.. I run Eclipse IDE on Ubuntu under wmware VM on a 32 bit MS Vista 2.4GHZ AMD dual core cpu machine..and yet my eclipse start times beat theirs..part of java development is knowing how to tune VM settings..some just frankly do not know how..
I hated Vim.. until I got 12GB of RAM. Now it's just another tool.
Bonus points: Install Vrapper (http://vrapper.sourceforge.net/home/) and get Vim keybindings. I also change the theme to get a black background and Inconsolata font.
And once you configure your own keyboard shortcuts and commit them to muscle memory. I have set
ctrl+] - select to the end of line
ctrl+[ - select to beginning of line
ctrl+d - cut current line
ctrl+k - duplicate current line below
ctrl+; - jump to beginning of line
ctrl+' - jump to end of line
ctrl+tab - switch perspective between debug and editor [1]
ctrl+i - focus on console [2]
ctrl+f - toggle find/replace bar
This was posted a while back, but I don't know if it's as good as you can get it. I tried some of the tricks and found Eclipse still occasionally slow and buggy.
Are there any standard tutorials on what to turn on/off? I tried eclipse and found it so damn slow and buggy I never returned - that was a while ago - maybe it's better now...
Here's my setup: Emacs, DDMS + JSwat, and ant to build.
I have emacs and a terminal open at all times. To build I switch over to the terminal and use ant. Sometimes I'll write a shell script to build+install+run on a phone.
My setup is essentially Emacs, DDMS and cscope/find/grep/etc.
I always find Eclipse to be too heavy. I don't do much actual UI coding though (I'm a platform guy), or I might consider it. The ADT UI tools seem to be very powerful and convenient.
After reading all the comments, going to have to check out IntelliJ. The thing I hate most about Android development is having to use Eclipse. Most of the time, I just end up coding in TextMate and only use Eclipse for building and debugging. I just hate how Eclipse feels and it's also slow.
Eclipse also sucks for Flash development, which is why I prefer FlashDevelop on Windows. It's just so much faster, and makes coding fun. Running FlashDevelop inside a VM is preferred over running FlashBuilder/Eclipse natively on the Mac.
Slightly unrelated, but why does everybody insist on calling it vi(m)? I have never seen a box that used vi in lieu of vim, it seems to be a historical artifact.
Calling it vi is probably used here to mean anything that acts somewhat like the original vi. There are quite a few editors like that, and vim is probably the most common.
> I have never seen a box that used vi in lieu of vim
I'm going to guess that you mostly use Linux boxes? The BSDs use nvi, which works and act like the old Berkeley CSRG vi. If you look at more esoteric systems like Solaris, AIX, etc. , you're likely to find varying versions of vi (disclaimer: I do not know the situation in Solaris or AIX. They are simply examples of esoteric systems—I'd love to be corrected if you do know).
I would not, however, recommend using anything but vim for development. nvi has its place a small text editor to get your config files in place, and vim has its place as a large programmer's text editor.
If you use any Posix environment asside from Linux, you'll find Vi installed by default but not Vim. This includes the BSDs, Solaris, and AIX in my experience. So vanilla Vi still gets use.
I think by now the terms vi and vim are all but interchangeable, except in a context where you specifically mean plain old Bill Joy vi.
On some systems vi is aliased to vim, so you would appear to have both, but you really just have vi. Even on systems where full vim is not installed, the "vi" installed is cut down vim.
I worked in Centos for awhile and vi was aliased to vim, but that might have been a local practice.
I used to use Eclipse before, but found the most frustrating thing about Eclipse is how often you'll encounter plug-in conflicts. (One plug-in doesn't want to work with another plug-in, but you just happen to want use both tools)
I switched to IntelliJ from Eclipse. The biggest frustration for me was waiting for auto-complete to populate on Eclipse, blocking anything else I wanted to do.
After using IntelliJ for a while, there i no going back. It's more responsive all round.
I've been using Galileo. Is there a reason to upgrade Eclipse? I haven't had any problems so far. I only use Eclipse for writing Android apps and don't really see a point in upgrading unless there is something special I'm missing.
I used to only use textmate because eclipse/adt was soooo slow. Since adt 12 is out and i have a brand new iMac eclipse is working just fine for me now. That said i still use ant to manually compile my releases.
Used IntelliJ on all projects so far, but looking at using emacs + eclim for code and eclipse for some nice GUI building whenever the next project rolls around.
It just works. I think the refactoring and language support may be better too, but that's not why I switched. I switched because eclipse is either too complex to work reliably, or I'm too stupid to understand it. Android, Appengine, maven, all just work great in IntelliJ. Whereas bog standard tomcat+maven was a daily game of potluck in eclipse.
I am a strong believer in your tool feeling good to you; it is the environment you create in. The better it feels, the faster and more cohesively you will work (within reason).
That being said, I'm comparing Eclipse+ADT to IntelliJ. I have no opinions on alternative home-brew solutions that are a combination of editors and command line.
For Android development, you'll want the following things:
- Strong Java editor support - Strong Android UI support - Strong debugger support - Strong deployment/emulator integration - Support for whatever Android version you are targetting.
The two IDEs in all those areas are damn near similar, except...
ADT 12 just added a slew of nice, Android-specific context-sensitive content assists that are really damn nice.
In addition, ADT 12 jumped the visual layout designer forward in a big way with accurate component rendering in preview as well as support for custom components[1].
I think something worth considering is that Android support is a feature, among 100 other, that the core IntelliJ team develops, support and extends.
ADT is the official, Google-driven effort to develop and expand their Android tooling on the Eclipse platform. The ADT team isn't distracted by things like autocomplete support, classpath scanning, project formats, etc... all they do is develop Android tooling directly ontop of Eclipse.
I would expect that the ADT tools continue to be more robust and outpace competitor implementations.
I would also point out that the ADT team has some seriously fantastic developers on it; if you are the type to enjoy high level "new feature" overviews of IDEs, check out Tor Norbye and Xavier Ducrohet's presentation at Google I/O 2011 showing off a lot of the new features in ADT 12[2].
I realize up to now it has sounded like I'm an Eclipse fan, but I am just a "tools to get things done" fan.
[1] http://developer.android.com/sdk/eclipse-adt.html
[2] http://www.youtube.com/watch?v=Oq05KqjXTvs