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