Live data from Hacker News

IntelliJ IDEA 13 Brings a Full Bag of Goodies to Android Developers

blog.jetbrains.com

101–104 of 104 posts

Re: IntelliJ IDEA 13 Brings a Full Bag of Goodies to Android Developers

#101

Earlier quoted context omitted.

What OS do you use? Because Swing is especially shitty on Linux, so I simply can't switch.

Ah yeah. It looked really bad on my ubuntu box. Moving to OSX was a help

Maybe have a look here: https://news.ycombinator.com/item?id=6840935

Re: IntelliJ IDEA 13 Brings a Full Bag of Goodies to Android Developers

#102
post #14

Want to like IDEA, but using a Java (Swing) based UI, in both Mac and Windows, makes me always feel like when someones scraps a blackboard with his nails. I could live with Eclipse though, despite SWT being also quite removed from the native experience. At least it had bloody native text boxes and scrollbars and such.

You might find some tips in here: http://youtrack.jetbrains.com/issue/IDEA-57233

Re: IntelliJ IDEA 13 Brings a Full Bag of Goodies to Android Developers

#103

Has anyone tried using Kotlin for Android development? (it's supposed to be lower runtime footprint than Scala, and it is officially supported by Jetbrains [1]) [1] http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin...

Kotlin works well for Android development. The annotations have gotten better recently, too, so you can interact with Android classes without too many null checks.

Re: IntelliJ IDEA 13 Brings a Full Bag of Goodies to Android Developers

#104
post #99

Earlier quoted context omitted.

When you run into the cases it is much better to write a plugin than to put imperative code into your build. Gradle builds are IMHO a huge step backwards for others trying to use someone else's build.

Really? You think someone will find it easier to go look at the source for my plugin rather than just a line of imperative code in my build script? I would agree it easily gets out of control, but I really don't think I would rather have to find and understand a whole plugin just to grok a one off piece of logic needed in the middle of a build script.

Generally, the imperative code isn't as flexible in different environments. For instance, if you look at the Gradle file for Gradle you'll find tons of stuff very specific to their actual computers they use to do the build. That is the opposite of what I want in a build file intended for third parties or even for medium teams.
Post reply on HN