Hacker News new | past | comments | ask | show | jobs | submit login
Android Studio 1.0 (android-developers.blogspot.com)
725 points by ingve on Dec 8, 2014 | hide | past | web | favorite | 227 comments

The fact that they're doing this with Jetbrains excites me. Potentially enough for me to take another shot at playing with Android development. The toolset felt so raw the last time I messed around with it (Eclipse+ADT days) that it turned me (not a Java developer) off.

I have been super impressed with PyCharm, and have heard great things about some of their other IDEs. Google picked the right partner to build on/with for this.

If they have sufficiently smoothed over some of the annoying workflow/build snags I was running into in the old Eclipse+ADT days, this could be a whole new ballgame for us who don't play with Java or Android for a living.

Senior Android Dev here, moved from Eclipse to AS when it was still in preview earlier in the year. It's loads more stable and much easier to use. Definitely recommend giving it a go if you were turned off by Eclipse + ADT earlier.

That's totally true. I've been a Java developer for quite a while. And I always find myself struggling with some Eclipse bugs or bad implementations. I downloaded android studio since the very beginning for the Android projects. The more stable interface really helps a lot.

Couldn't say it better. Even the old preview releases I used were waaaay more stable, fast and user friendly than Eclipse ever was. I would definitely recommend trying AS!

Gradle is pretty tightly integrated with the IDE now, and in general I find myself rarely having to troubleshoot build problems with Android studio. Adding new dependencies is as simple as adding a single line to the build.gradle file, it's great.

Maven: <dependency> <groupId>org.sakaiproject.edu-services.course-management</groupId> <artifactId>course-management</artifactId> <version>10.2</version> </dependency>

Gradle: compile 'org.sakaiproject.edu-services.course-management:course-management:10.2'

It's worth the transition.

You're working in Intellij, it's the same number of keystrokes (the entire block is generated on <dep+tab). Making a decision about a build tool based on a few characters of boilerplate is insane.

If you like Gradle fine, but this is a really stupid thing to make that choice over.

Back in the day the standard project layout for Android was using either Ant or whatever magic Eclipse itself was doing. So developers wanting to import dependencies were copying JAR files in the "libs" folder. I don't remember Maven being in the picture at all.

> It's worth the transition

Or maybe it's worth formatting a Maven syntax sample in your comment just like an IDE would:


Gradle still looks far more efficient to me.

The word I would use is "vague".

That's still awful...

I'm interested in how you would do it better. This syntax seems fantastic to me, both terse and readable.

Maven's HTML/XML-style syntax in dkopi's example...

...is equivalent to the Gradle/CSS-style ...

      groupID: "org.sakaiproject.edu-services.course-management"
      artifactId: "course-management"
      version: "10.2"
...via simple syntactic transformations. Of course, IDE's go a step further and automatically generate and parse the whole shebang so the issue of syntax readability is moot if you use an IDE.

I'm absolutely nitpicking here, but Gradle's style is closer to json.

If at least they had used a JSON parser instead of a full blown (slow) language!

Using Groovy to parse their build scripts instead of an industry standard like JSON is what's holding Gradle back. But I suspect they'll open their build process up as an API now that Java provides lambdas.

I don't know enough about the ecosystem to suggest a better alternative, but given the obvious redundancy, I'm not sure how it could be described as 'terse'.

I suppose you're talking about the "course-management" bit. That's just the way they named things. You could just as well have the following:

The artifactId is the name of the jar file.

Since you don't know about the ecosystem...there is no redundancy in his examples.

One could argue the conventions are poor though. groupId isn't really necessary. Most artifactIds are unique, and Maven Central could be the authority for (rare) naming conflicts. Works fine for ruby gems, apt repos, etc.

"com.google.guava:guava:18.0" could have been "guava:18.0".

Not really. You should have seen the discussion about the new Rust package manager. Putting everything top level means that good package names are taken forever by what is possibly abandonware. With namespacing everything is equal, first comers don't take over everything. Especially with the Maven/Java "use your reversed domain name" as groupId/package. Maybe it's a bit too verbose, but I'd still keep a group layer above the actual package name.

With namespacing, the namespaces end up being taken forever. A top level name of 'google/guava' isn't a big difference compared to namespace:google, artifact:guava.

If everyone followed the reversed-domain-name naming scheme, then namespaces taken up by abandonwares will get flushed out of the system after a few years.

That's a pretty huge "if" though.

You appear to have forgotten the HN rules:

For all statements X If X contains "Java" Emit comment Y where disparaging(Y) is true.

...ly good

Happy paid PyCharm user here. I'll definitely look this up.

The only criticism I have of jetbrains is that their support isn't the best. My experience has been that you can get faster and better answers by scouring the 'net than by using their support system or forum. They need to hire someone to own this and bring it into compliance with what is to be expected when you pay for a software products. I have software products costing around the same as PyCharm that have massively better support.

Again, love PyCharm, will continue to use it and recommend it, I just think they need to do better on this one area.

Yes. I've started using PyCharm recently and even though it's great, the inability to have a few trivial getting started questions answered means I probably can't justify paying for it to replace the Komodo IDE I've been using. ActiveState actually answers questions.

Well, I am not worried about trivial questions which can be easy to google. The problem I see is two-fold:

First, the lack of tutorials/videos on relevant topics that are up to date. For example, the Django with PyCharm video didn't have any audio and, last time I looked has not been replaced. I find video presentations to be particularly efficient as a means to quickly communicate intended usage and workflow.

Second, support becomes invaluable when it comes to non-trivial situations. For example, I still don't have an answer for this:


I frankly didn't even try to reach out to support due to my prior experience. And that's the issue. I have no problem with paying for good product. And I want to stress that PyCharm is a damn good product. When I do there's an expectation of quality support.

So I find myself at a strange point. I would unequivocally recommend PyCharm to anyone considering it. It is a very good product. And I have to do this while not being thrilled about their support, which feels really weird.

I absolutely love PyCharm, I use it also for all my coding needs, not just python!

Although it is ironic that I am using the keyboard scheme from Eclipse. It's just...embedded in my muscle memory.

Actually, as a non-Java programmer who has been attempting to use Eclipse from time to time over the years, I can tell you that it's actually pretty good for Java. But just for Java. With that said, Android Studio is superior for me. If I'd known it's a Jetbrains thing from the start, I would probably go with it immediately. Eclipse also seemed like the 1st choice according to the Android developer docs at the time (I hope they update(d?) that), so that threw me off too.

AS has been my first exposure to Java and I find it very intuitive to work with. The last 4 months in particular have seen a lot of improvements. I use it with Genymotion and real devices.

I hated Android Studio when I first started using it. All my shortcuts were different from Eclipse, and the whole module structure wasn't as intuitive for me (I stayed away from IntelliJ too). However, after using it for the last 6 months, I have to say, it is a huge improvement for Android Development. There are soo many slick IDE features, like icon previews to the left of the editor, smart code collapsing (done automatically by the IDE without modifying the source), preview's on text resources, UI preview's that put Eclipse + ADT to shame, and very very nice gradle integration.

And at this point I freaking love gradle over Ant. I use to be an Ant fanatic (which isn't saying much), but gradle gives so much more structure to my builds now, and Maven is no longer such a pain in the ass.

I've started later with Android Development than you did. So I've just used Eclipse for a pretty short time. To be honest, I can't stand those different views (e.g. when starting to debug). The resource editor with its live preview is so much better in Android Studio. Showing the content of the string instead of just showing the ID - there are so many little things which are far better than with Eclipse. I really like the decision to go with JetBrains instead of Eclipse.

You've likely already discovered this, but in the off chance not, you can set your keymap to match Eclipse. Just go in Preferences > Keymap, and select Eclipse or Eclipse OS X from the dropdown.

Please don't do this. I know I'll probably get voted down by people, but doing this is terrible if you're in a team. You can't move efficiently to a co-workers computer and pair program like this.

Take the time to learn the shortcuts for AS. They might be long and arduous, but learn them. Then you can jump from keyboard to keyboard without having to tell a team member, "Before we begin, let me change your keyboard shortcuts to my preference".

Sure you can. Ctrl-Shift-A, type 'keymap', and you get a handy popup (same size as the 'recent files' switcher available with Ctrl-E) with the defined keymaps ready to use. Few seconds, maximum.

Even quicker: Ctrl+` brings up a quick switch context menu that allows you to instantly switch keymaps, code styles, L&F and colors.

What if I told you

not every team does pair programming

Well, that's a fair comment. But I've been the lead on multiple projects for multiple companies. This means that I'm often at someone's PC working in Eclipse. I know the shortcuts, they might not. In either case, having to change someone's settings to suit me is a slow process.

Especially problematic when I get called off to something else. I might forget to set the editor back. Now the person is annoyed until they either figure it out or call me back saying, "Fix it, ass."

What about shops where programmers use different IDEs? Even if they go by the principle that forbids them to customize anything, you still have different keyboard shortcuts to deal with. I dread the thought that you might prefer to impose One True IDE on everyone in the team just for this reason...

General rule? No multiple editors. That doesn't mean no specialized tools, but no one offs. On one team a member wanted to use VIM for most of there stuff. I thought fine. Unfortunately VIM's formatting is different than Eclipse's. The result is files were hard to read in both tools.

Besides, to the point at hand, my rule is no dicking around with how the Romans do it. IntelliJ has its own rules. Eclipse another. The same is true for Emacs and VIM. Trying to make one the other overly complicates the matter for the team. Think how many people get confused by Emacs in Evil Mode.

A team requires that we work in concert. They should argue and defend tool selection. Once decided stick with it until its been played out.

"Unfortunately VIM's formatting is different than Eclipse's"

Now can't THAT be fixed without throwing Vim away?? I've never used Vim, but I think its fans hail it as very configurable etc., the best thing since sliced bread (or is it Emacs? I can never remember which one cures cancer) :))

Anyway, these are discrepancies that "leak out" of your machine; like code formatting. That's a showstopper to be sure.

But keyboard shortcuts I see as a "private area", just like being left-handed and configuring one's machine to accommodate for that - sorry, but Ctrl+X and Ctrl+C aren't that convenient for someone who uses their left hand to control mouse (statistically 1 person in 10).

Maybe Android development isn't the best example here, since 1. no offense to those who swear by it, but Eclipse is inferior in compare to Android Studio, I don't think anyone would fiercely insist on sticking to it, 2. both these IDEs are closely integrated with different build systems.

But, say, in PHP? You can (or should be able to) freely switch between PhpStorm, NetBeans, Eclipse or even a regular text editor without affecting other team members as far as code itself is concerned.

To put it that way - personally I wouldn't like to work in an environment where it's prohibited :) That's just fascist, man...

"efficiently ... pair program"

Also interesting is that the Eclipse based ADT is no longer being maintained. Guess there's no choice but to migrate. http://developer.android.com/sdk/installing/migrate.html

It's for the best. Android Studio today is far better than Eclipse+ADT ever was. Maintaining two entire toolsets would be wasteful. Clearly Google decided it was easier to build the tools they wanted on top of IntelliJ than on top of Eclipse, even accounting for having to start over. That speaks volumes about the two platforms.

For a time Android Studio was unstable and not feature complete[1], there were valid reasons to stay with Eclipse. These days the only people that aren't happy about it are those that prefer Eclipse to IntelliJ. That certainly is a valid opinion, but there were people that preferred IntelliJ to Eclipse the first time around. You can never please everyone.

[1] Yes, I know NDK support isn't yet in Android Studio, it is coming.

It's still very unfortunate, the developer community is about split between Eclipse and IDEA: forcing half of the developers to learn a new IDE might slow down Android adoption.

They have enough resources to maintain both ADT and Android Studio, it's a very surprising move.

> forcing half of the developers to learn a new IDE might slow down Android adoption.

I know of a platform that forces developers to learn how to use their IDE, their Operating System, their Hardware, and recently their new language, and their adoption hasn't slowed down...

heh I actually know of two platform's if you consider new windows phone.

Nope, Windows Phone (fortunately) doesn't force you to use Microsoft Hardware (yet).

Pardon me? I wasn't aware of any other platforms that you can use to develop for windows phone.

The windows platform runs on third party hardware, including Macs.

I know that you can run Windows on a mac, but you can't use OSX to develop for Windows.

You can't even install OSX on something without an Apple logo (well, in theory you can but you shouldn't because insert legalese and threats here).

In the case of Apple their closeness is not hurting them, and definitely not decreasing their adoption.

In the case of Microsoft... well, they still need to convince people to take Windows Phone seriously, so their closeness only helps to hurt them.

Not MS hardware, but you are forced to use Win 8

The writing has been on the wall for a long time. At this point most of the full time developers that work on Android are using Android Studio. I personally have been using it for ~18 months as my daily driver IDE. About 9 months ago I asked a meetup audience of about ~150 people how many were using Studio and the hands showed about 50%. I imagine it is far higher than 50% today.

The best developers I know are debating between Maven+IntelliJ and Gradle+Android Studio. If this turns off a handful of people that are tangentially attached to Android development, so be it. The people pushing the boundaries of writing apps have switched already.

I know some people personally are more familiar with Eclipse than IntelliJ. I was one of those people. There are lots of training resources for people going from Eclipse to IntelliJ, it is a well tread path. Just give it a try.

" forcing half of the developers to learn a new IDE might slow down Android adoption."

I think it already did that before, didn't it? The shoe's just on the other foot now.

Honestly, if you have problems getting used to an IDE, you'll have a huge problem developing for Android anyway - it's a platform that's significantly different than any out there and learning the IDE is such a minor thing that developer hung up on that probably shouldn't be developing Android apps.

Also, you're not "forced" into anything - any Gradle compatible Java IDE will load and compile AS projects without a hitch (sadly, Eclipse Gradle support is really bad, hence the switch od IntelliJ platform).

Eclipse support of any build tool is quite bad, since they are always seen as external tools (looking at you M2E).

I rather like the approach taken by Netbeans where they refactored the IDE to use build tools as the project format, with known targets mapped to IDE actions.

Same approach taken by Visual Studio as well.

Cannot say much about Android Studio, because lack of C++ editing/linting/refactoring/debugging and NDK support keeps me on Eclipse.

NDK user. Staying with Eclipse for the time being.

Yeah. This is a sticking point for us, also.

There's ways around it, but it's still pretty broken. :(

> Also interesting is that the Eclipse based ADT is no longer being maintained.

It was announced quite a while ago that ADT was being abandoned and that Android Studio would replace it when available.

Those of us doing C++ on Android still cannot.

To be honest, I use my favorite IDE with C++ projects, and use eclipse exclusively to build the APK file.

I do as well (QtCreator/Visual Studio), but some times you really need to go back and forth between Android tooling and C++ and it feels nicer all from within Eclipse.

Plus Eclipse has quite good static analyzer, which is something non optional when I code in languages like C and C++.

I would be extremely interested in how you approach that-- specifically with respect to the debugger. I'm using the canonical eclilpse/cdt/gdb stack and it is nothing short of torture compared to any modern IDE.

I mean, eclipse is a broken hellscape of failed promises on its own, but gdb is.... words fail me. Truly. AND I KNOW HOW TO USE GDB PRETTY WELL.

The applications we build are cross-platform games, and the Android-specific code is reduced to the bare minimum and abstracted behind a framework.

The development and debugging is done with the desktop version of the game. We avoid using Eclipse & friends unless we manage to break something at the Android side, which fortunately almost never happens.

We found this approach to be the most productive and less frustrating for our team.

same thing here, we restricted our public APIs to native scalar types, and the JNI glue is just a wrapper around these functions. Off the top of my head, we only expose a couple functions to set the native surface handler, get a valid reference to the AssetManager, and receive input notifications.

the Java code base only consists in a single Activity object and a ScaleListener.

We also ended up integrating our android build process in visual studio using a mix of python/batch scripts.

The make utility provided by the NDK is notorious for not being able to process absolute windows paths, so we cannot use the all-subdir-makefiles command. A workaround was to use a simple python script to generate a viable Android.mk file, setting the LOCAL_SRC_FILES var with a list of relative paths to our source files.

In the post-build event of a dedicated VS project, we batch the calls to ndk-build, the ant command, and the final little adb dance.

with the proper file hierarchy (src, res, jni and asset directories), the build process is very smooth.

I do audio programming, among other things. This sadly requires a familiarity with low level mobile development that many find.... distasteful.

I would advise anybody listening to stay well away from NDK programming. Here there be dragons. Google has done their absolute best to pretend nobody ever needs to get their hands dirty in android. Which would be nice, if it were true.

Fully agree.

Native development is a pleasure in iOS and Windows Phone.

On Android it feels like something Android team was forced to provide by upper management and do as little as they can.

Which given their reaction to alternative languages on the Android Team Fireside, might actually be true.

Can you elaborate on your tools and approach? Got a blog post your recommend? Best practices?

I can recommend you the book "Advanced Android 4 Games" from Apress, the book basically consists in porting C/C++ games to Android, but it has everything you need to get started.

You should also check SDL 2.0 if you are starting a new project, they already did all the heavy-lifting for you.

Jetbrains is working on a C/C++ IDE (CLion), so I would expect this functionality to flow over. I spend most of my time in AppCode and IntelliJ, and core functions from other projects flows between their IDEs regularly.

I just wished that we (NDK users) would be considered for a 1.0 release, but given how the NDK tools are, it isn't a surprise.

Yes, Eclipse is pretty much busted now due to Google Play packages using .aar (you have to just copy the .jars into your Eclipse project now) and Android Studio is an uphill battle if you are already using Gradle, since it uses a newer version that probably wasn't compatible with your third-party plugins.

As a strongly leaning iOS developer, something like the "Xcode for Android" was something that was holding me back from committing more to experimenting on the platform. The fact that Instruments, Interface Builder, etc are integrated well alongside the editor is huge and I think Google is wise to invest here.

Developers, developers, developers!

What? You don't hate XCode? How?! ;)

XCode was terrible around 2009, but it has come on a long way since. I'm not using it much these days, but when I need to it does amaze me how easy it actually it is to use. I normally depend on vim keybindings, but I find that the autocomplete in XCode is so good that I actually don't seem to mind reaching for the cursor keys for navigation (much).

Just to check - you're not a time traveller, and you're talking about the current XCode, not some future version which isn't a rude joke compared to any decent IDE around (AppCode, Visual Studio, even Eclipse)?

Edit: sorry if I came up like a complete tool, but every time when someone say that XCode is a good IDE small part of me dies :)

Am I the only person that really likes Xcode?

It's the first IDE that I've used that doesn't dedicate the entirety of its chrome to 100 different buttons. The developer workflow is nice (Open Files Quickly, Go to Line, Symbol navigation, pragma marks, breadcrumb bar, continuous build cycle, CI integration with OS X server, etc). I can get Vim bindings with Xvim, (this is not an Xcode feature by default but it's worth mentioning because it's the best Vim emulation plugin I've used apart from IntelliJ's). It has Interface Builder, Instruments, etc all integrated and super easy to work with. Most of all, Xcode's simplicity. I started iOS and Mac dev with 0 experience working with Xcode and I didn't need any, since it's so easy to use.

Yes, it's a good IDE. Is it a perfect one? Of course not, there are still hundreds of issues like Xcode complaining that a certificate already exists when I try to code-sign my app but Xcode doesn't use it, first few releases of new versions of Xcode are always crash happy, and Xcode's build settings are the ugliest part of Xcode.

Different people prefer different things I suppose. Maybe people became so used to Eclipse and Netbeans ugly UI and incomprehensible buttons everywhere that Xcode doesn't seem as feature full to them.

> It's the first IDE that I've used that doesn't dedicate the entirety of its chrome to 100 different buttons.

Maybe this is everyone's problem with it?

I've spent about 6 hours a day in Xcode since 4.4, so it may be a bit of Stockholm Syndrome, but I feel very comfortable. In the last year, I've had to do some work in IntelliJ/WebStorm/RubyMine (all the JetBrains IDEs!), and while they're definitely nice, I would say they're harder to use, less predictable, and have wayyyyyy too many buttons. Also you can tell they're not quite native (as someone who cares about aesthetics, even in IDEs).

Xcode forces you to figure out the shortcut keys. I like it that way. And I spend more time hitting tab and enter than I do actual typing, and that's all we really want from an IDE anyway, right?

Yes. Every time I look at a default Visual Studio setup, I get mental fatigue just from trying to figure out all the buttons, toolbars, and options that I'll never ever need to use. It's completely gross and bloated — the Microsoft Word of IDEs.

Xcode, on the other hand, is so nice and Appley and clean. It's a shame it runs so slow and crashes at the slightest breeze. Still, I'd rather use an Xcode that I have to force quit every 30 minutes than a stable Visual Studio any day.

You do know that you can move/remove and customise all of those buttons and toolsbars and options and whatnot? I have never seen that as an excuse.

I only have half a line of buttons under the main toolbar. The number of windows I have docked varies from 1-2 while programming to about 5-6 while debugging (with the watch list, call stack etc. all easily viewable).

I would reckon that most programmers spend at least some amount of time customising their development environment; I mean it's what you spend most of your day using. What is important is what features and development-helpers your IDE supports (you don't have to use all features) and how configurable the environment is (while not being overly slow and buggy), in my opinion.

My excuse is that I'm getting older and I just don't want to deal with the fiddling anymore. It gives me nothing but stress. All my IDEs and text editors have the default config (modulo a few settings), and I'm OK with that. I don't use emacs or vim.

I got the impression before that the only people who really like Xcode are those that have never used any other IDE. Are you one of the exceptions?

> incomprehensible buttons everywhere that Xcode doesn't seem as feature full to them My issues with Xcode isn't the lack of buttons, it's the lack of functionality. I started with Borland IDE's for Pascal and Java, then Jetbrains IDEs for Java, JS/HTML, and now Obj C, and through those, the tool became an extension of my person. I've been using Xcode now since 2009 and I find that it still gets in the way instead of helping me translate thought into code. It's gotten better in letting me know what I might need, but still falls short of actually letting me have it.

I used Borland Codegear and C++ Builder before that for a number of years, then moved to Visual Studio, spent significant time in Eclipse developing Android apps, and also spent a large amount of time in KDevelop and Code::blocks under Linux.

Xcode took some getting used to when I first came across it ("Where are all the buttons? How come the big PLAY button at the top runs the app but doesn't CONTINUE like it does in VS? Why are there no floating windows? How come the project and target options are a big list of stuff instead of tabbed pages? (The filter helps!) Why does it crash if I have a large header with many #defines in it? How do I easily switch between Release and Debug targets? Why is there no built-in TODO/FIXME filter?").... but having used it for a few years and having seen the updates to it and daily using it, I really really enjoy using it now. The debug overview of memory use and CPU/Network use and deep Instruments integration ("where am I leaking?!?! Let's just take a look!"), as well as the splitting usage by thread during runtime is really helpful and there isn't much going on screenwise, so I just have to look at code. The recent version is better than the previous one because it has a logical call graph shown for each thread instead of a popup irritating menu like the previous one (click click click click misclick arrgggh)

The navigation bar at the top is also strangely useful, with back and forward buttons! I never thought I'd miss that but I do if I go elsewhere.

A trip back to VS (admittedly an old version, thanks work) makes for unpleasant experiences (argh building is sooooo slow, where are parallel builds???).

The 'callers/callees' list is really helpful when inside a function to see where things are getting called from; admittedly no refactor support for C++ is disappointing but I don't really use refactoring much.

EDIT: One thing I really really really miss from Visual Studio is the Ctrl-Shift-Space shortcut for showing function parameters. You get them as a hint first time in Xcode and it might shove them into the text where you can tab between parameters but with overloaded functions it typically chooses the wrong function. With VS the popup hint dynamically changes as you're typing to show the right overload, and I miss it.

> My issues with Xcode isn't the lack of buttons, it's the lack of functionality.

I always hear this, but never the specific feature that some other IDE offers. Please share.

I'm using AppCode for code editing and debugging, and XCode for practically everything else (project settings, designer, etc). These are features I'm using every single day:

* Buttons and toolbars - I don't use any. I have more or less consistent shortcuts between AppCode and XCode, and for less used features I'm using Cmd+Shift+A shortcut. It's an equivalent Cmd+Shift+P in Sublime and more powerful feature search than standard Cmd+? (which search only inside menus).

* Code navigation - put cursor on function, variable, property, whatever, press Alt+F7. You'll get a split panel, on the left are all places where function/variable/property is used (and you can filter it by read or write access), on the right is the preview panel, so you can see the code without changing cursor position in your main editor.

* Code navigation - Cmd + Ctrl + J to easily jump between function definition and declaration

* Refactoring - rename: yes, XCode have Rename, but AppCode rename is much more streamlined: put cursor on method/property name, press Ctrl+Cmd+E, change the name in place, as I'm typing every occurrence of the method/property name changes. I press Enter and the change is done, without modal dialog to review change. And rename works on protocols, too.

* Refactoring - Change Signature: in case I need to reorder function parameters. Put cursor on method name, Cmd+F6, reorder/rename parameters. And AppCode is smart enough to try to preserve natural flow of words - if the function is called saveContent:toFile, when I reorder params it will become saveToFile:content:

* Refactoring - easy promotion from ivar to property. And vice versa.

* Local history - I try to commit as often as possible, but I like an ability to see what I changed on the file in last couple of hours (with diff). And that option saved my ass couple of times.

* AppCode marks methods/properties that aren't used. I like to delete code. Less code is better. Very useful after refactoring.

* Better editor - I can split my editor horizontally/vertically however times I wish.

* Better editor - Shift + Ctrl + 1 - 9 will toggle quick bookmark. Ctrl + Alt + 1 - 9 will jump on the bookmark.

* Better editor - Cmd + Alt + UpArrow will expand selection. First sub-word (up to first "hump" in camel case) will be selected, then the whole word, then the next word, then the whole line... Cmd + Alt + DownArrow will go the other way.

* Better editor - Shift + Alt + Up/Down Arrow (or Shift + Alt + Click) will make multiple cursors, just like Sublime. Handy for changing lots of similar text lines.

* Better editor - select couple lines of code, Alt + Cmd + T will bring "Surround With..." popup. Press the mnemonic on the right to surround text with if, if/else, while, respondsToSelector, #ifdef,@try/@catch, etc, etc, etc. Time saver.

* Better editor - type SomeVeryLongClassNameIReallyHateToTypeTwice* var = alloc, press Tab, and AppCode will change "alloc" with [[SomeVeryLongClassNameIReallyHateToTypeTwice alloc] init]. Time saver.

* Better editor - Cmd+N will bring "Generate" popup where you can choose "Override method" or "Implement method", among other things. When the list of methods to implement/override is shown, you just type to narrow the selection. It's way faster to implement mandatory or optional delegate methods that way than to XCode-like start typing return value, then tableView: (for example) and picking the right method from the list.

Etc, etc - there's many more small things that good IDE ( * ) does to make programming more enjoyable. This list is just from top of my head.


( * ) AppCode is just "good". For "very good" see Visual Studio + Resharper.

I've used a number of IDEs. My favourite would certainly be IntelliJ, but Xcode would probably be second, certainly above Eclipse and Visual Studio (though the last version of VS I used seriously was 2003, at which point it was clinky and awful; things may have changed).

I'm actually a version behind, I haven't got round to updating to the latest yet.

What is it about XCode that you think is bad?

Everyone uses their tools in different ways. I use Visual Studio in my day job, but I prefer to use Emacs for most of my side dev these days. Given that perhaps I don't use everything an IDE has to offer.

Comparing Visual Studio with XCode, the following features are what I use to most.

Autocomplete - XCode wins here. Say I have two variables - clientService and clientMapper. In XCode I can type cl<tab> and it will complete the client part of the variable for me, I then only have to choose between Service and Mapper. Visual Studio doesn't. Pressing <tab> will choose the entire current selected item.

Quick open - XCode wins. Cmd + Shift + O (I think) start typing the file name, hit enter and there you are. Visual Studio (without Resharper) forces you to search through the Solution Explorer, which is slow and searches for methods as well as files.

Syntax/Error/Warning Highlighting. Both IDEs do this just fine.

Debugging - Cant think of anything to differentiate these IDE's. It used to be a real pain to inspect variables in XCode, but that was more GCCs fault rather than XCode. Since moving to LLVM, I haven't had any problems.

Refactoring - I probably don't use these tools as much as I could. But the basics are covered. Extract method, rename variables etc.. can be handled fine by both. I don't use anything else.

Vim keybindings. There is vsVim for Visual Studio and now I see there is XVim for XCode.

Disclaimer: i left C++ behind 8 years ago, so if you're using Visual Studio as a C++ IDE, I trust your opinion. I used Visual Studio as C# IDE for 7 years, and...

* Autocomplete - the XCode way to do autocomplete drives me crazy. Why XCode hides what I'm typing with it's guess? Regarding Visual Studio autocomplete: you start typing variable. The autocomplete narrows your choice. You press up arrow/down arrow, enter/tab, you're there. And the choice is always relevant, instead of "I'll put just everything I can think of" XCode autocomplete

* Quick open - which Visual Studio version you're using? In VS 2013 you can press Ctrl+, and get essentially the same functionality as XCode. Type file name, symbol name, enter, the file is open.

* Syntax/Error/Warning - Visual Studio gives you extra help if something isn't quite right. You typed "Regex" and there's red squiggly line? Place the cursor there and press Ctrl+. What's that? An option to include System.Text.RegularExpressions namespace automatically? Or you typed parameter name that doesn't exists? XCode will curse you, Visual Studio will offer (via Ctrl+.) to make the method for you, and it will infer return value and type of parameters from your code. That's great way to start writing class from scratch, and I miss it in XCode.

* Debugging - again, I can't argue about C++ debugger, but C# debugger is actually much more powerful than XCode debugger. You can inspect variable values in tooltips, there's powerful visualizers, there's an option to pin tooltips with values so they're always visible (even when the program stops, so you can see the last value while fixing the error) and last and not least - very, very powerful Immediate window, sort of REPL for C#. I hope LLDB will have something similar for Swift.

And there's much more that Visual Studio provides. Code Lenses (only in Ultimate version, but still). Code Peek - XCode sorta have something similar in Assistant Editor, but not quite. Find References. Call Hierarchy. And that's just the basic Visual Studio (now free) functionality. With Resharper it's completely different beast.

I have been doing C#.

I never knew about that Ctrl+,. Thanks for pointing it out. I don't think it is as powerful as XCodes, XCode does more fuzzy matching. I think (don't have mac open to check) in XCode if I have a file called ClientsController and I type ClientC it will bring up ClientsController. In VS it seems I have to know I want the plural ClientsController..

You are spot on with your other points though re debugging and syntax fixing. VS is better than XCode in many ways, but I would say not so much that XCode should be despised as satans spawn.

If it's vim keybindings you're missing then check out https://github.com/XVimProject/XVim

It's the only way I can use Xcode and keep my sanity :)

Wow! Thanks.

I wouldn't say Xcode is perfect by any means, however I think Apple has a deep appreciation for workflows and simplicity. Whether it's about the end-user consumers or the developers themselves any sort of friction inhibits delight, engagement, etc.

Say what you want about Xcode but it is not in as bad a state of most of the Android IDEs. And Visual Studio is light years ahead of both.

In what way? I use VS every day alongside Xcode and it's like pulling teeth (but with easy remote debugging, admittedly). I am using an old VSC++ version (2010) but has it significantly improved since then?

Visual Studio's C++ support is far, far behind its C# support. Using Visual Studio with C# is perfect, but I always hate using it for C++.

Disclaimer: MS employee, not on VS team though.

There's nothing quite like Instruments integrated well with Android Studio, sadly.

xCode today is and extremely sophisticated IDE. I think there's no other software more complex than it that is so well designed to maintain simplicity, ease of use and speed. It was ultra slow years before, but nowadays every time I develop for Android I'd kill for having an xCode like realtime autocomplete and documentation. XCode it's extremely solid and you feel it every time you use it. Android Studio is build on Java, then it's slow and the UI is nowhere near as polished as Xcode. If I were Google I'd start coding my own IDE from zero ASAP.

Your comment tells me you haven't used Android Studio at all, and are making up attributes based on what you assume something written in Java must be.

I use Jetbrains IDEs and Xcode every day. Whenever I have to write any significant amount of code, I switch from Xcode to Appcode.

> I'd kill for having an xCode like realtime autocomplete and documentation

From my experience, this is true for Jetbrains IDEs, and not for Xcode, particularly for autocomplete. Xcode autocomplete is a pain, and sometimes gets in the way instead of being actually helpful.

I am sorry to disappoint you. I wrote a huge app in Java and in Kotlin. Months of develoments. xCode still years ahead of AS in every sense. Inheriting another company IDE is philosophically wrong, but that's the way Android and Google work. Maybe I love details too much.

So, given that IntelliJ IDEA has been in development for 14 years and XCode for 11, when would you expect Google to release a high-quality IDE if they started from scratch today?

This is a subjective issue, of course. Personally I find autocomplete and navigation in Xcode still sorely lacking compared to IDEs in the Intellij family, to the point where I happily pay for AppCode to do most of my iOS work (basically any serious coding, although I return to Xcode for UI work). I will concede the AppCode can be sluggish at times, though, which is my major gripe. Conversely I find Xcode more buggy: every other version seems to be plagued with crashing bugs.

As for the idea that Google should start from scratch: that would just put them back a decade. I'm very glad they decided to build on an existing great platform instead.

Java/Swing is slow is a myth due to badly written applications. Jetbrains does it right. My main machine is a little 11" MacBook and I use AppCode/IntelliJ all day long without performance issues. I use XCode for Interface Builder as the code crafting abilities of the editor are primitive in comparison. I do agree that everything integrates nicely, and it's great to just jump in as a newbie, but I miss solid refactoring, code navigation, smart template and multiple cursors the most when I occasionally use it. I can see the evidence when I start on an existing codebase - typo's, misnamed methods that have evolved to something else etc. Things that AppCode does trivially, and with full trust are things that XCode users seem to balk at as one never knows if the build will break. Maybe things have improved over time (I've used AppCode for 2+ years now), but the evidence in existing code tells me otherwise.

From someone who uses both daily, this is far from the truth, and I can only conclude that you have not used Android Studio in your day job.

XCode is fine for what it is, and its strength is the tool integrations. For everything else like actually editing and refactoring code it is worlds behind something like Intellij/Android Studio.

If Google does anything, they need to build/buy a simulator (Genymotion for example) instead of the emulator.

> xCode-like realtime autocomplete and documentation

XCode's autocomplete is a joke compared to Android Studio's -- a strongly typed & non-dynamic language does wonders for how efficiently & accurately an IDE can fill in your dots for you.

I am sorry but AS autocomplete takes seconds to appear on my rMBP. xCode flies. I write methods and I see the docs on the right. I can cntrl+click and see the full docs. Let's not talk about the Quality of the Apple docs compared to android's, or debugging and instruments tools.

> takes seconds to appear on my rMBP

seconds is far too long... That you're even trying to argue that autocomplete is more powerful in XCode than AS shows you haven't used AS for more than maybe a minute. I've used both side by side for years (well, Eclipse and IntelliJ before AS), and it's honestly not even close. XCode takes longer and consistently suggests functions not available on my object, or classes I never use. XCode is great at plenty of things, but autocomplete is its #1 weakness.

> I can cntrl+click and see the full docs

And in AS I can Cmd+Click and see the source..

> debugging

debugging live running apps w/o having to launch from the IDE is awesome. And I don't think there's a single debugging feature that XCode has that AS doesn't. Seeing as Obj-C is a dynamic language, the console REPL is pretty nice, but that's a language feature more than an IDE feature.

I've only learned to really appreciate Android Studio after I went back to Eclipse for a project, and felt the sharp drop in productivity.

Jetbrains sure know how to produce an awesome IDE.

This! Same with Zend Studio (based on Eclipse) vs Jetbrains PHP Storm, huge improvements in productivity due to more features and most of all faster speeds.

Somehow on Core I7, 26GB ram + SSD it still takes me less time to make a cup of coffee than for Eclipse to start up :(

I love Jetbrains tools!

As another poster mentioned, the latest eclipse version "Luna" is much faster and better than previous versions. It boots up faster than the beta versions of Android Studio.

I've been using Luna for a month, it's much faster at startup, they did a great job with Luna. Each version of Eclipse in the past 6 years has been improving.

> Somehow on Core I7, 26GB ram + SSD it still takes me less time to make a cup of coffee than for Eclipse to start up :(

Eclipse (I use Luna which seems to be faster than the previous version) starts in a matter of seconds on my MacBook Air (8GB of RAM + SSD).

I just tried eclipse last week after having stayed away from it for a couple of years. You're right, you really feel the difference immediately.

Eclipse was great for what it was at one time though.

I'm in 2 minds regarding Studio. On the one hand, I'm a whiz at Eclipse and Maven, and because time is so precious, I have no motivation to learn Gradle, and so I use the excellent android-maven-plugin[1]. (I'm also dependent when using Eclipse on the Emacs+ plugin for Emacs key bindings) When learning a new language / platform, I'm fine with learning its "standard" build tool, but with Android dev, I wish I could use Maven. I just can't emotionally bring myself to have to spend brain energy on yet another build tool chain for Java dev (I'm already juggling "build tool chain" knowledge for iOS dev and Clojure dev, just to name a couple).

On the other hand, I want to be using the best and latest tools, and stay up to date with what the broader Android dev community is doing.

Would love to hear from others with similar feelings...

[1] https://code.google.com/p/maven-android-plugin/

I too am satisfied with Eclipse for Android development. It does what I need and I'd like to stay with it for a while longer.

Android Studio is fanciful, I used it for months during the beta. There is one gotcha which leads me to prefer Eclipse. In Eclipse, the compile process is much more integrated with the IDE. The compile step appears to happen inside the IDE app/process tree/whatever. In JetBrains, the compile process is a separate process, much more disconnected from the IDE. Hence JetBrains takes more memory and is slower and running a project build and getting errors back into the IDE. I can appreciate an external build process being flexible for Jetbrains to use their IDE with nearly any language/compiler, but Eclipse worked much faster overall on a 4GB ram setup.

You're right. This is also a problem with Eclipse over the IntelliJ toolchain, in general.

Eclipse has it's own compiler and it uses that to build from within the IDE. Since this is not using Javac, it means that you might and very likely will not have equivalent binaries. Not specific to Android, but this also meant that when a new version of Java is released, IntelliJ can immediately take advantage, but you will be stuck waiting on Eclipse (and NetBeans).

Personally, I prefer the IntrlliJ approach since the IDE, javac on my workstation, and javac on the build server can output identical binaries, I trust the results even more so.

My understanding has always been that you can have Eclipse invoke an external build. However, if you use its compiler you do get quite a few niceties. Largest being that it can let you debug partially broken code. (You just can't call a method that was unable to compile.)

Also, if I am not mistaken, IDEA has its own compiler, as well. It just doesn't emit bytecode.

I only tried Android Studio a bit, but I had a similar impression. Eclipse for Android works very well. I'm already familiar with Eclipse.

Are you doing something really specific with the build tool? What testing tools do you use? Do you use the NDK?

Gradle covers the 80% use case really well. Everyone new to Android should use Studio + Gradle, no question. Dependencies are a breeze, the integration between Gradle & Studio is wonderful, the syntax is super simple, and the plugin handles most things by default pretty well. There are several things like build variants & package name interpolation that were impossible with Ant, difficult with Maven, and are trivial with Gradle.

The intermediate level stuff is more of a mixed bag. Some tests work well with Gradle, others (like Robolectric) are more of a pain. The NDK support isn't worked out yet. Some of the more fringe plugins like code coverage and formatting aren't plugged in yet. Here you will probably have to understand a bit about Gradle, but the tools team is making progress fixing the issues. What was a problem 2 months ago just works out of the box today with no Gradle specific knowledge.

For advanced things like writing your own plugins, then you have to know the respective build system. I don't know Maven well enough to write my own plugins. I have written a couple Gradle plugins. I have one that uploads APKs at the end of the build to various distribution APIs, one for secure signing, and one for bumping the versions whenever I want to. It was pretty straightforward to figure out.

No, I wouldn't say I'm doing anything specific. No on NDK. It's simply that Eclipse/Maven serve me well (I'm even able to create/run Android unit tests with the android-maven-plugin). In short, so far my entire workflow is well-served by Eclipse/Maven.

I'd concede that Studio/Gradle is the future, and that Gradle is more powerful than Maven; my "issues" are purely emotional :) With all that there is to learn and explore in this world, I don't want to have to spend time on another Java build tool when I already know 2 good ones (Ant and Maven).

Totally understand the sentiment, but given Gradle's rising popularity, it will probably be difficult for us Java (and especially Android) devs to avoid it. Might as well give in and pick it up now.

It already works for simple builds. It's a bit harder if you have many MK files for various libraries. I migrated my Cocos2d-X game to Gradle a while ago and I could only solve the problem through a gradle exec task. Still, the build is already much saner than the Maven version. I just wish they would give the NDK more attention, because the problem exists for well over a year.

Its only a build tool. Maybe Maven has damaged you and you expect a build tool to require a significant time investment.

The Gradle documentation is 66 chapters [1].


I would certainly not call Gradle easy nor fast to learn.

[1] https://www.gradle.org/docs/current/userguide/userguide.html

That's a feature not a bug. Gradle has phenomenally good documentation. I wish Google kept that level of documentation up for their plugin, or for any part of Android in general. Large swaths of the Gradle user guide are not applicable to the Android plugin because they are for other language specific plugins. The core of the user guide is only a few chapters long and well worth reading.

The Android specific ones are here:

* http://developer.android.com/tools/building/configuring-grad...

* http://tools.android.com/tech-docs/new-build-system/user-gui...

I was actually excited when I saw the size of the documentation. I really was, and I read it several times over the year.

And then one day, I realized that the web site that I always get back to in order to fix my build files is Stack Overflow, not gradle.org.

The fact that the documentation is so big is an issue, not a feature, because at this size, it's just too big to navigate, contains extreme amounts of redundancies between sections and basically, is not usable in this form.

You know your tool has a problem when the only way to fix problems is to search Stack Overflow.

This. Like most folks here, I like learning new things. I learned Ant a long time ago, and then Maven (to GP's point, learning Maven was NOT trivial). When I started through the Gradle docs and realized that it's a DSL written in Groovy, I had to open a new tab in my browser and start learning Groovy. Now I'm thinking to myself: "Great. In order to really grok Android Studio, I need to learn Gradle. To grok Gradle, I need to learn Groovy." As I mentioned in a previous comment, with all there is in this life to learn, I just can't bring myself to learn Gradle when I already know 2 other Java build tools :)

You're quite right to avoid learning Groovy, especially with its lack of documentation, but Gradle doesn't really use Groovy. It bundles Groovy, and the Gradle build scripts you write are parsed as Groovy code, but typical build scripts only use a small subset of the gigantic Groovy grammar. I've yet to see an open source project's build script, even Groovy's itself, that drops out of the Gradle DSL syntax to do something procedural using Groovy. The whole point of Ant, Maven, etc is to do build declaratively instead of procedurally. In the small number of instances where you do need to, you're better off using Java or any other JVM language you want to configure the build via the Gradle API.

Not only that, but I suspect Gradle won't use Groovy to parse the build scripts for much longer. Those scripts conform to a rough CSS-style syntax that Gradleware could easily replace with their own custom lightweight parser calling Java 8 lambdas. Given that they replaced virtually all the Groovy in their codebase with Java when they upgraded to Gradle 2.0, the next logical step is to eliminate dependence of the Groovy parser as soon as they can.

Gradle documentation is 66, but Android's gradle plugin is only a subset. Plus, gradle _is_ simple and easy to use in the standard scenario of a run-of-the-mill Android app.

It's when your app becomes more complicated (product flavor's for example), that you need to read and understand the gradle documentation. If this is the case, then you are not a novice and 66 chapters of docs is a blessing not a curse.

and Again _the Android gradle plug-in only supports a subset of gradle_!

I was under the impression that the "Android Gradle plugin" is a plugin to extend Gradle's behavior? So really you're dealing with 66 chapters plus Google's wildly-insufficient Android-plugin documentation.

Maybe XML has damaged me, but I am quite happy with Ant and Maven.

FWIW: I'm assuming this intel-j based apps, like phpStorm will have emacs key binding. Not emacs obviously but it works pretty well.

Their main Android Developer website, and their 'Getting Start' docs seem to have been updated for Android Studio, too, respectively.



Things are looking good for Android development, especially with regards to Firebase being acquired.

Very interesting. I had been using development under Linux under Eclipse for a long time and found it alright, although recent moves to Mac OSX as the fulltime development system meant it felt awkward under OSX (and upgrades between Eclipse versions always broke something).

Anyway, having installed the JDK 8 u25 on Mac OSX, Android Studio wouldn't run. You need to export:

export STUDIO_JDK=/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk

Modify .bash_profile in your home directory to get that to stick.

Unfortunately the documentation isn't 100% worked out yet. They published a bunch today, but the post explaining that is buried in release notes for an RC build:


You're right - that link you provide is far better. Modify the Info.plist within /Applications/Android Studio.app/Contents and modify the JVMOptions / JVMVersion string to read 1.8* instead of the default 1.6*.

Much better than the BASH profile thingy (which doesn't work without opening a terminal, obviously).

The above trick also works with Intellij proper. The only downside is you have to change it again after every update.

Android Studio has become a good, mature IDE. Having had to go back to Eclipse for my current project, the positive difference is vast once you get deeper into it. I still believe Eclipse is far superior on Windows than it is on Mac- the usability and scrolling performance is terrible on retina Mac.

This brings me to my most wanted feature in Android Studio - smooth native scrolling! Right now it scrolls lines-at-a-time rather than pixels-at-a-time, which is slightly annoying. Eclipse on Windows was very nice in this respect.

Finally, all the languages for all localized strings in one big, massive table. For all us >10 languages polyglots out there.

It's deeply disappointing to see Google moving to a proprietary IDE for Android. I've wasted time in the past learning proprietary development environments, and it's not a mistake I want to repeat — years of muscle memory and ecosystem knowledge down the drain when the IDE owner went out of business or didn't support the new platform I wanted to develop for — but it seems like now I have very little choice if I want to develop for Android. I mean, Eclipse will still work, at least unless Google breaks it, but it's falling by the wayside.

It's also alarming to me that nobody else here on Hacker News seems to be concerned about this.

I know Google isn't a free-software business like Red Hat, but they've benefited enormously from the work of the free software community, in particular in building Android, and they touted Android as being open. It was inspiring to see a really open phone platform birthed, but every month it seems like Android is less and less open. Supporting only a proprietary development toolchain is one more step toward the dark side.

How is it proprietary exactly?

Android Studio is open source:


There is certainly a commercial version which is not, but you don't have to use that and Google isn't shipping that version at last check.

...I was wrong. Completely wrong. I thought IDEA was proprietary, because it used to be, but IDEA is free software now. Furthermore, if I had investigated that question for only a couple of minutes before posting, I would have known that. Thank you for taking the time to correct me.

I'm happy that the truth is much brighter than what I thought.

The Jetbrains guys are also extremely skilled at creating IDEs. Short of buying Jetbrains (which seems unnecessary unless Google wants to scale its tools team extremely aggressively and a bad things for other languages), I don't think Google could have made a better move.

How about support for NDK (C++ development) ? Does the Android Studio ships with support for C++ editing ?

Nothing at all.

Apparently Google is waiting that JetBrains eventually releases CLion.

It is anyone's guess when it will achieve parity with CDT.

This isn't entirely true... I'm using some, albeit trivial, NDK support by adding: android { ndk { moduleName "<some_module_name" stl "stlport_static" ldLibs "log" cFlags "--std=c++11" } }

To my gradle file. I've set up a pretty simplistic JNI directory structure though. I can provide more info if this isn't enough as it's been awhile since I've set up a project from scratch.

That is very little. As you say, rather trivial.

I want native code debugging, refactoring, static code analysis (Codan like), code navigation.

And for that you can easily use pretty much any other editor/IDE that supports that. You don't HAVE to use only Google's tools you know?

Oh, I though Android was a Google's product!?!

Android Studio can support highlighting C++ syntax and compiling. It can follow functions, header declarations, etc. It can also do some level of intelli-sense and give compilation errors/warnings based on clang (I think).

Unfortunately this is not seem to be the case, but the people who make IDE upon which Andrew studio is based do have an experimental C++ development IDE so you'll be able to use the same shortcuts as in android studio. It's not even close to free though, Ormoc though it will be once it is out of Beta.

I can't remember what it is called, but you will be able to find it on jet brains homepage.

Great to see Android Studio reaching 1.0 I'm also a happy user of IDEA CE 14 for Dart.

JetBrains et al really built an impressive IDE platform. I'm glad there are open source alternatives to Eclipse.

Wait, IntelliJ is open source?

Yes, it is. You can also get a version without "enterprise" features for free (called "Community Edition")


The Community Edition of IntelliJ is open source. Android Studio, which is a fork of Community Edition, is also open source.

You can also get the enterprise version if you show them you use it for open source development

I don't see any mention of NDK support. Has studio added that yet? Also, is ADT support going to continue? I really prefer eGit to whatever ships with studio.

Unfortunately it is not good.

The current NDK integration is a dead end, we don't recommend using it, as we are working on a new version that use the native support in Gradle.


There too goes the new low audio latency updates they were raving about out the window. As far as I can tell the NDK is needed for doing any real-time audio processing as you're forced into using a large 4096 buffer in the Java API (testing in Lollipop...) :/

Yep. The entire rationale is that audio must be run on a thread which is never going to be GCed, and for that reason the low latency stuff only makes sense in the NDK.

I think you hugely misunderstood the post. NDK is going nowhere, just the current Android Gradle PLUGIN support for compiling NDK code is a hack that will be rewritten in more Gradle native way.

There is absolutely nothing stopping you from using NDK code with AS and Gradle.

I realise this is subjective but how hard have people found converting over to Android Studio for someone used to Eclipse? I was taught to use Eclipse in university and having been using it full time at my job for the last couple of months so its workflow is quite ingrained in me.

'A couple of months' isn't a big investment in my opinion. I used Eclipse for ~8 years, including writing plugins for it. I switched to IntelliJ about 18 months ago. I'm probably still not 100% as familiar with IntelliJ as I was with Eclipse. I'm still far more productive.

I've waited a couple of months for Eclipse just to respond to a right click.

How the hell are you codding that switching to another fairly similar IDE makes you that much more productive. Could it be that what youe are really saying is that you just like it better.

I'm having trouble getting my point across but basically what I'm saying is that most of my time is spent thinking. The coding part is small and as long as the IDE is not batshit crazy I kind be just as productive in any IDE.

I will admit that there is one IDE that I like the best but I wouldn't argue that I'm able to finish projects twice as fast with it than with any other reasonable IDE's.

And yes, XCode, Eclipse, Android Studio are more or less the same.

Sorry, should have been clearer, couple of months in my job and past 4 years at university.

Glad to hear though, I'll try it for my next android project.

If you are doing traditional app development then Android Studio is by far the superior choice. The gradle integrations make everything one liners without having to manage a ton of random plugins or master a build system. It just works.

Also, not to belittle your investment in Eclipse, but counting university is laughable and unless you're a maestro and use some random plugins that make you a 10x developer you're probably better off switching.

As others have mentioned you can change your keymap to Eclipse, or just learn new ones. Hell, I only know 4 keystrokes: autocomplete, find class by name/click, rename variable/method, and reformat code. Yet somehow I am successful -- I doubt it's my IDE. It's just effortless and I don't have to deal with stupid build crap while writing code. Granted, I don't know much about modern Eclipse, I haven't used it for two years.

If it weren't too much effort I'd be writing java in vim where I have almost 8 years experience, but I haven't gotten around to bothering because my environment is not the bottleneck to writing good code. It's probably more the crappy Android APIs and unexpected behaviors of standard libs that will unlikely be timely fixed.

It's very similar to Eclipse in terms of general layout/workflow. Shortcuts might differ a bit, but nothing major. Many of the tasks which were somewhat awkward in Eclipse like managing libraries are simpler in IntelliJ/Android Studio. Android Studio's integration with the Android SDK is significantly better than Eclipse+ADT, and the build system seems to work much more reliably for me, when it would randomly fail for me frequently in Eclipse.

I've been using Eclipse for my day job for the past 4 years and I have no issue switching between that and Android Studio.

My first thought was "oh PLEASE, let them keep distributing the CLI-only SDK".


Because I got burned by Eclipse so many times I got used to developing solely with vim and ant - then I started using NetBeans+NBAndroid and found it comfortable enough.

Still, now that it's 1.0 I'll eventually migrate.

Um... now that Gradle is the default build system used, you can build any (AS-created) project in command-line by default. You can also easily create new one (you just need a skeleton build.gradle).

Glad to see this reach final. Have been using it since the first alpha release at I/O 13 and it's been getting better and better.

Has there been any word about their Android Go project? Would be awesome now that they are updating all their development tools.

Does anyone know if I can customize the IntelliJ with plugins to be exactly equal to Android Studio? Is this possible?

I switched to Android Studio just a couple months ago and the main deficiency I've found compared to Eclipse is that it doesn't auto-build the project on every change so you can immediately see all breakage. I'm constantly hitting "Rebuild Project" because someone decided it couldn't be done for me.

As for advantages over Eclipse, they've been minor. No real big improvements except the automatic dependency management of Gradle.

The reason for the giant effort to switch the entire ecosystem over is a bit mysterious to me.

I believe you can switch that in the settings. Go to Preferences > Build, Execution, Deployment > Compiler and use the checkbox for "Make project automatically".

Likewise, under Compiler there's a "Java Compiler" panel in the hierarchy. You can switch it to using the Eclipse compiler which I think allows you to launch with errors in your project.

For me, IntelliJ's auto-complete is a lot nicer than Eclipse's and that makes me more productive.

Yes, lack of auto-build, plus no problems view!

However, i've found that i do not notice that so much and get much more benefit from gradle then ant. Also, the project structure has ended up being alot cleaner and easier to navigate for me. Plus, I like all the slick IntelliJ style features.

As for the giant effort to switch? I'd say gradle is a big one.

To be fair, had the ant based build system been written by someone that actually understood ant properly then it wouldn't have been such a mess.

It was also educational just how big a performance difference at code or xml editing existed between ADT and the same Eclipse installation on a vanilla Java project: the latter is like using a machine a decade newer.

The tools people have always had a casual disregard for NDK users too, who make a disproportionately large amount of the Play Store revenue. The whole thing has never seemed like it was dog fooded at all, just developed for amusement.

View > Tool Windows > Problems gets you a problems view.

Doesn't exist.

On *nix, there should be a tool that lets you execute a command whenever files in a certain directory are changed. I did this years ago but forget how I did it.

On Linux I use inotify for this; currently using it to rebuild a C project through make whenever I write to files. Very handy.

AFAIK they use Gradle 2.1, which introduced incremental compilation. Unfortunately it's not yet very good at figuring out dependencies. Gradle was never a speed demon to begin with.

I still don't know how to add an aar dependency in Eclipse

Can these features be added to a vanilla Intelij install? What will happen to the existing Android plugin?

They are added back to IntelliJ. It is sort of a weird development process. Android Studio is a fork of IntelliJ, so it always runs a bit behind. At the moment Studio is branched off IntelliJ 13.3, not 14. Meanwhile, IntelliJ pulls in the Android Studio stuff into their plugin a bit after Studio releases it.

If you want the latest and greatest IntelliJ features, use IntelliJ + Android Plugin. If you want the latest and greatest Android specific features, use Android Studio.

If you have a paid license of IntelliJ, you are probably better off with IntelliJ + Android plugin.

Most of those features are already available in IDEA 14, others will trickle through very soon (usually it's couple of weeks difference or so).

ADT plugin is being abandoned.

as someone who uses gradle everyday I cant express my disappointment enough. I cant think of any greater dev friction th an the incredibly slow gradle builds I deal with daily - not to mention the langue. its like someone wanted to redesign javascript poorly.

How do you delete a project?

Why do they make it SO HARD to even delete a project?


To delete a project you simply delete the directory using your OS file manager. This is not a common operation and your file manager likely has options for undo and such that are OS specific.

It doesn't have simple project management?

If you are currently in a project, select File->Close Project. In the list, select the project you wish to delete. Press the delete key.

You will be prompted if you really want to delete the project. Click Yes.

I've been using it almost since day one, and professionally too. The frustrating thing was compatibility breaking, mostly associated with Gradle. Every second upgrade, I had to spend a while getting my project to build again. Yes, I'm new to Gradle. I only learned the required minimum, I should get to know it in-depth. But I have work to do in meantime. Fortunately, this integration is constantly improving.

Yes, that was annoying - but I guess that was the legacy of actually being a pre-release version (0.x versions).

Tools team promised that compatibility breaking changes will stop after 1.0 until other major revisions. Let's hope that holds up :)

I've been using Android Studio for a while now, and greatly prefer it over Eclipse ADT (being phased out anyway, and thankfully so) but I've had a lot of trouble getting my projects from earlier versions of Android Studio up to date - it's always a form of a gradle incompatibility; Android Studio is great when it works, but it's been a rocky path to 1.0.

When they can go a major version without seeing a bunch of Gradle changes in the patch notes, that's when I'll upgrade my project from Ant.

How does this compare to the combo of C# + Visual Studio (which seems to be the target market here)?

Eclipse + Java has always been a non-intuitive headache for me - will this IDE support Python? Has Google made Python a first-class language yet in their stack?

Inquisitive minds would like to know.

It only seems to be the target market to you in your MS-centric world. It compares very well to C#/VS. Although I fail to see the relevance, yes, the IntelliJ IDE supports Python - https://www.jetbrains.com/pycharm/

Why is that mentioning C# in an Apple thread is A-okay but mentioning in a Google related post is a deathnell?

If you people think the target market for this is just Eclipse and Android developers then you have not been paying attention to the larger picture of cross-platform stacks.

It even has the word Studio in the name for crying out loud.

Android Studio is customized very specifically for Android development, not a general purpose IDE. Even the New Project dialog will not let you continue without selecting the target Android form factor.

You're being downvoted because your comment reads as being off-topic and/or uninformed (especially with the Python mention). If by Visual Studio and C# you were referring to Xamarin or Mono for Android it would have been clearer if you mentioned that. It would be helpful if you also mentioned why you feel Android Studio targets developers who use those technology instead of the larger pool of Android developers in general. I don't think there's a bias against those technologies here, only against poor comments.

OK that's cool it's based o IntelliJ IDEA. Now only if Google comes up with a faster emulator it will help many of us to take Android seriously. Seriously I can't wait light years to test my Hello World script.

Isn't light years a unit of distance?

Yes distance from my Laptop to Kitchen. More it takes time to load Emulator more I stay in kitchen to eat stuff.

The only thing Genymotion basically does is use a host-native image x86 based android image, rather than the actual emulated device image, typically ARM as the android emulator would do by default (for some reason).

If you use the android emulator with the x86 android image (on a HAXM capable CPU), then it runs fine. iOS has always used a simulator.


Is Google planning to release a 2d graphics library like SpriteKit but for Android?

Try LibGDX

android studio is really good. but gradle is annoying me. every gradle-build project force me to download a new gradle-wrapper. I install the newest gralde in my OS, but it can not be use repeatedly

Emacs and command line tools still for the win!

Have any good setup tips?

Sorry to disappoint, except for setting C bracing style to "bsd", I don't really do anything to set up Emacs for Java code. Unlike crawling horrors like J2EE, the Android API is quite manageable without a whole lot of IDE support, especially if you've been coding in it a while.

Should I get this or just keep using Intellj?

The majority of new features developed by the Android Studio team are integrated into IntelliJ, so if you're already using IntelliJ version 14, there is no big advantage to switching to Android Studio.

Android Studio is free.

As Intellij community edition.

hopefully they improved resiliency. my first experience with android studio beta was: 1. create one project and close it 2. edit single file outside. 3. reopen project on android studio and watch it go down in flames.

Finally making the switch from Eclipse to IntelliJ

Late 2014, a single-target-OS IDE is released - makes me chuckle :).

I`m using.

Call me when I can develop android apps from within an android device.

It seems a strange specification to have - why that in particular? Are you thinking "democratising development"?

You can use MIT's AppInventor via the website, so presumably you could use an Android based web browser if you really wanted to. Seems like it would be pretty painful trying to do that from a small screen device however.

Why would you want to ? Can you develop Windows apps on a Windows RT device? What about iOS apps on an iPhone? Or Blackberry apps on a Blackberry? Despite the fact that you can with tools like AIDE on Android, the devices are meant to be low-powered convenience devices, not developer workstations. I think you might be misinterpreting their purpose?

I've found AIDE to be an interesting option for developing on the device itself.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact