And it is still slower than good old Eclipse.
It's bizarre that a one-man-team beats the mighty Google in pretty much everything.
The build is so freaking fast that it runs ProGuard by default – and beats a Gradle build without ProGuard.
That dev implemented and shipped Instant Run way before Google "invented" it, and it's still faster compared to Google's implementation.
Since my focus is the NDK, which keeps being half-done in Gradle, I keep using Ant + ndk-build and have migrated to Visual Studio 2015 for my Android hobby coding.
The plugin can now manage and auto-install SDKs, tools, support repos and NDKs, so no messing around with Google's `android` tool anymore!
Maybe this is of use to you.
https://github.com/scala-android/sbt-android/commit/7b32e55f... https://github.com/scala-android/sbt-android/commit/53b855de...
I thought it was just the plugin and DSL handling code. That would explain why Gradle's so slow, then.
> the DSL, which can be used purely declaratively, but it's not limited to such use
Virtually no-one uses Groovy procedurally, only declaratively, in Gradle build scripts, so although that's true in theory, in practise only the non-Turing Complete portions of Groovy are used. Calling it a programming language there is like calling HTML one because you can embed Javascript in HTML.
For my day job, we use Groovy for our Spring Boot app. I love it.
I've also done a lot of Grails development, which I enjoyed also.
It was even on JEE roadmap to be an alternative language for JSF applications, presented at JSF Days in Vienna.
Nowadays if it wasn't for Gradle, I wouldn't even notice it exists.
Mobile dev being new, even Java developers get to play with more shiny toys. For good or ill...
org.gradle.daemon=true
No it not, when people make use of Java code, it starts in ms.
It is only slow when running languages like Groovy or Clojure on top of it.
From the VM side, Eclipse compiled quick, Tomcat restarted great, JUnits flew. To be fair this was pretty straight forward Spring MVC/Services, no web plugins for HTML5 stuff. Intellij for Web Development (Gulp, and AngularJS support) was just terrible. The UI would be unresponsive. It could take multiple seconds for the File menus to pull up. Builds are slow. Hot deploy wasn't much better than in Eclipse.
On OS X, there's a typing lag. I could live with that. My big issue here is that Eclipse gets better battery life. There is a known bug in Intellij that forces OS X to keep the high performance graphics card on. Battery goes from 5 hrs to 2.5. This makes getting out of the house untenable. I use Android Studio because that's the guidance, but I prefer to not use Intellij if I can.
http://tools.android.com/tech-docs/instant-run
In practice, what I've seen so far is that sometimes I'm not sure what is being "instantly run" -- my latest code change or something older. Still trying to gain confidence in that feature (or just not use it because I don't understand what it's deploying all the time).
It exists longer than Google's "Instant Run", is faster and works without flaws (in my experience).
and one of the worst thing about google is they don't deliverer feature they promise. I did a lot of NDK development. I use emacs for that , but eclipse was acceptable too. But I remember last year they promised full NDK support in android studio, but they haven't introduced it yet. This is what absolutely I will not tolerate from a company. If it is not ready , then don't introduce it in development conference , if it is ready why it took so long (1 year ??? and still no news).
another point about Google is they don't absolutely care about developers. Who are we kidding ? no one can deny for years developer begged google for new,faster,better Android emulator. But they did nothing. Right after Microsoft introduced their Hyper-V based android emulator which is fast as hell, They developed new virtual machine. (they use qt5 for its interface). Because they felt threatened by Microsoft.I promise if it wasn't for that the old emulator was still there.
It seems like Google has tried to pursue a cheap shortcut to IDE greatness, at first by building a plugin for Eclipse, and then, by putting some money into a relationship with IntelliJ and Gradle (who truly are excellent at what they do).
But still, Google has not brought the excellence of organization and deep commitment fully in-house.
On the other hand, I guess if they had a choice, the NDK would probably not even exist.
I went through all that BS so I feel your pain, but thanks to the IDE gods the IntelliJ people fixed the Linux font rendering issue in their 2016.1 release. They now include a custom JRE that fixes it. This custom JRE can also be used in Android Studio (and surely any other Swing java programs) just create a symbolic link pointing to it inside Android Studio's root folder and you're done. Needless to say this is way more elegant and safe than the ridiculous TuxJdk "fix".
Android studio lets you pull out what you need, when you need it and doesn't just throw everything in your face like eclipse (and there's a lot it it there!) either you need it or not.
I'm guessing there's a reason Google decided to obsolete their eclipse-based Android SDK tools.
I was originally planning to do dev work for android in a virtual machine like everything else I work on but I doubt it would be anywhere near performant enough.
ps: TURBO.EXE amounts to a whopping 600KB.
I worked on an assembler/editor that had a change-to-run system on the order of a couple of seconds, too.
Something changes when you have near instant turnaround time. It's magic.
Some of the most miserable time I've spent has on projects with tooling where builds took hours, and often hours just to fail. I was even okay with 30 minute turnaround time, as long as it was clear that the bottleneck wasn't fucking lame tools: The need to burn a bunch of EPROMs for each build, for instance . . . though I fixed that as soon as I could.
Eclipse CDT with Ant + ndk-build finish a build before Gradle manages to parse all its configuration files.