Hacker News Reader

Comment by amolgupta | Hacker News Reader

the NDK support in Studio will end the use of eclipse for Android development.

I like how people see Android developments as a choice of heavyweight IDEs. I do all my Android development, Java and native, with Emacs and Buck.

Can you recommend any good resources learning about taking this approach?

http://buckbuild.com/

I often program Android in Emacs as well. I use the Java Development Environment for Emacs and have been happy with it.

If you add an Android-specific class like TextView in your code, you can easily have Android Studio add the needed import command for it.

With Emacs/JDE, I point my jde-global-classpath to the Android jar, then when I need to add an import line I highlight the class and do a Control-C, Control-V, Control-Z. It is slightly more convoluted than Studio but works well enough, I could probably automate and simplify it more if I needed to. This was the main shortcut I missed when moving from Eclipse/ADT to Android, but doing this got it back for me.

The thought of writing Java without IntelliJ makes me want to quick programming. Ironically, Kotlin might be great in a text editor despite being made by Jetbrains.

Do you use Kotlin with Gradle? I like Kotlin a lot, but it feels very slow on my laptop, do you know if there any special optimizations to make it faster?

I haven't shipped anything to production yet but I haven't noticed any build slow downs. I have only really worked through Koans repo to try and learn the paradigms. It can pretty much do anything Ruby, Python, JS, etc can do and it only costs you a 200KB runtime.

You might want to make you have parallel builds and the gradle daemon on for the gradle CLI. Android Studio seems to turn these on for you but if you build from the terminal I think they need to be specified in a gradle.properties file in the project root. You can also increase the amount of memory gradle is allowed to use.

As far as I know Kotlin does almost all of its magic at compile time so I am sure it will slow down builds slightly versus plain Java. From what I have seen so far I am more than willing to pay this price.

Here is a good overview with benchmarks from Square

https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC...

Right, the runtime speed of Kotlin is very good. But the build times got much slower. An average java build with Gradle takes ~30 seconds on my pretty old laptop, but with Kotlin it is about 1 minute. Daemon and parallel are enabled in global gradle properties. I think running Kotlin compiler as a daemon would help, but I don't see an easy way to do that with Gradle.

Oh, finally I'm not alone here! I use vim/tmux and yesterday I discovered Buck and made a quick project generator: http://zserge.com/blog/buck-build-system.html

I feel like I would take more than 8 extra seconds just writing out and correcting the package names in imports than I would gain by trying to write Java in vim, and I'm saying that as someone who otherwise uses vim/tmux for everything.

I'm liking vim/tmux for Ruby, but for Android Java, so far, the AS plus IdeaVim combo seems nicer than anything I've put together with vim and tmux. Project-wide autocomplete and auto-adding imports plus the debug support is such a time-saver.

I'm actually considering going back to Eclipse (or dumping IDEs altogether) because my computer is struggling under Android Studio's memory requirements.

(I'm unemployed and don't really want to pay for a 64-bit system. Anybody want to hire me so I can afford a new computer?)

Thankfully, as they will not add Java 8 support. Source: the Q&A at the end of the developer tools session.

So at least we can make use of some C++ love, even if the frameworks access is limited.

Hmm, Java 8 is actually supported in Android Studio. That support however will not make device Dalvik/ART VMs magically support Java 8 bytecode :)

Retrolambda is rather useful to get a subset of J8 features.

> Retrolambda is rather useful to get a subset of J8 features.

I never advise hacks for production code. Either it is first class support or it doesn't get used.

Adding extra layers to debug only increases production costs.

Reply on news.ycombinator.com