Hacker News Reader

Comment by 0x0 | Hacker News Reader

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

View on HN

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 think it already did that before, didn't it? The shoe's just on the other foot now.

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 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

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.

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.

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

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.

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.

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.

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 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++.

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.

Reply on news.ycombinator.com