[0] https://code.google.com/p/gmaps-api-issues/issues/detail?id=...
I think the only large platform owning company that has really succeeded with development tools is Microsoft. With Microsoft's newfound interest in cross platform development I'm looking forward to the day when I can just develop entirely in Visual Studio.
Is it really fair to say xCode is not a successful tool? A lot of people use it, and I don't hear enough complains about it.
And what is the most common tool for Android development? I assumed it'd be Android Studio by now, is everyone still on Eclipse?
Agreed, VS is the best IDE out there by far. Still a shame that developing in VS implies developing on Windows.
Android has a problem with churn in tooling.
It's not even using that many CPU cycles according to Activity Monitor but it slows down everything regardless. It seems to always be doing some bullshit, indexing or whatever even if it's just open in the background.
I'm running this on the latest model MBPro which has a super fast SSD and 16GB RAM. I usually have at least one Eclipse instance running with a Glassfish server. Also, Postgresql, Safari with 100-150 tabs open, countless text editors I use for not taking, usuually I have some graphics editors open too (Affinity Designer and Pixelmator), Chrome with a few tabs and Postman, Wireshark, Mail, Calendar, etc.
All this while driving a 4k screen in simulated-2560x1440 'scaled' mode (so it's basically rendering at twice that and scaling it down to 4k). All that runs smooth as butter. The only thing that seems to be able to get this machine on it's knees is Android Studio, no matter what I do. The only thing that seems to improve things a little is AS's power save mode.
At work, I am yet to get a customer that allows us to use anything but Eclipse. At home I rather use Netbeans for Java projects.
For Android, the Android Studio barely supports the NDK. So we are left with the older Eclipse CDT plugins, Visual Studio or NVidia CodeWorks.
However, it appears to still require the experimental Gradle plug-in. Which, frankly, isn't very good.
I'm still building my native .so separately using NDK build. I don't get any native code debugging either.
Is there something obvious I'm missing?
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.
org.gradle.daemon=true
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.
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".
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.
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.
Eclipse CDT with Ant + ndk-build finish a build before Gradle manages to parse all its configuration files.
Fairly limited without ReSharper, which makes it slow; language support is not particularly great; updates have made me lose half a day's producitvity (although that's par for the course for Windows); weird keybinds...
And of course: Windows-only, not open source and not free as in free beer either if you don't meet certain criteria.
It would be handy on my travel netbook, which is the only GNU/Linux device at home.
Google deprecated the Eclipse CDT and ndk-build support, went silent for two years, announced an initial CLion integration at last Google IO and since Android Studio 1.5, its support or NDK support for that matter, hardly changed.
however it is so baffling that in several conferences I have seen Googlers ask such persons to come forward and explain to them why they don't want to switch.
Cause man, I'll tell you straight up, I despise Eclipse. To the marrow of my bones. But if you wanna do native debugging, they're it. Native debugging is very important when you're getting nasty (and if you're not getting nasty, for the love of god why would you use the NDK?!).
Ad hominem reaches a new level.
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.
android is rather cli friendly - a full 50% of the devs I know use vim or emacs.
On the other hand, I guess if they had a choice, the NDK would probably not even exist.
Also that is a very lame excuse for the cold reality, that in spite of the very complex hiring standards of Google, they aren't able to write an IDE that offers an overall experience for their own platform.
As for the google rant, I'm not a google employee, but I think their work has been amazing. Are there improvements I'd like to see? of course. But I've never understood how easy it is for people to trash talk the work of others given an anonymous nickname online.
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.
I don't do trash talk, just tell my opinion as a hard truth and I stand by my opinion.
I learned through my life to stand by what I believe, without gaming up and down votes.
I would express the same opinion at Google IO, if given the opportunity to be there.
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...
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.
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.
Mobile dev being new, even Java developers get to play with more shiny toys. For good or ill...