Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Android Studio 2.0 Is Google’s New, Improved Development Suite (zco.com)
78 points by rafa2000 on April 29, 2016 | hide | past | favorite | 75 comments


Maybe this is better left as a comment SO, but we have been unable to any recent version of Android Studio for our development team for the past four months because we use a mapFragment in our app. It's a known error [0] in the Maps API v2. I understand the complexity Google is facing, but I can't imagine Apple not addressing such a fundamental UI capability in their dev tools. Frustrating.

[0] https://code.google.com/p/gmaps-api-issues/issues/detail?id=...


For several months XCode would just crash when I tried to run my application with debugging. It was eventually fixed by an XCode update.

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.


Worked as a .net dev for ~3 years, and I loved VS, but it had its share of random problems too. I remember it flipping out and suddenly consuming a shitload of CPU and RAM for no apparent reason, even working on fairly small projects. It was nearly impossible to work with it until I switched to a more powerful PC.

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?


Those of us that also use the NDK are mostly using Visual Studio, NVidia CodeWorks or trying to keep using Eclipse CDT tooling (there is a fork of it).

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.


some people are still using Eclipse...

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.


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

Agreed, VS is the best IDE out there by far. Still a shame that developing in VS implies developing on Windows.


How is it better than any of JetBrain's products?

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.


Some of us are developers and do actually like Windows, but I agree it would nice for it to be cross-platform.

It would be handy on my travel netbook, which is the only GNU/Linux device at home.


I agree. Having worked with VS, in the past 10 years I think my worst issues (as in bugs) have been corrupt Intellisense databases with resulting errors and rare flipping out in the UI designer, resolved by restarting. The Intellisense issues were worked on with a major rewrite of that engine that I think is implemented these days.


Have you ever used an Apple dev tool? If so, I'm shocked at how dramatically different your experience has been from mine. I would rank Apple absolute dead last in terms of caring about the usability of their dev tools out of any vendor of dev tools I have experience with.


Move fast, break all the tutorials.

Android has a problem with churn in tooling.


Ive noticed this across the board with google with regard to developers. They half-ass everything programmers need to interface and use what they produce. Very frustrating.


Try to find documentation as well, most of the time it is scattered around developer blogs, SO posts or devbytes videos instead of being posted on the Android documentation website.


Give me increased functionality over ease of finding tutorials any day.


Long time eclipse user, impossible to go back after using android studio. It feels like programming with one hand tied behind my back.


I'm always surprised at how many people willingly put up with Eclipse's clunkiness and performance problems, regardless of how many functions it provides.


Really ? I feel the exact opposite. Eclipse performs much, much better than Android Studio. Just having AS open is enough to kill any and all performance on my laptop, not just AS itself but the whole machine crawls. I have no issues with having shitloads of other software running the only thing that has such a dramatic impact is Android Studio.

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.


Because most of the time we don't have a choice.

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.


NDK work accounts for a small percentage of android work. If you're more comfortable with NDK on eclipse, that doesn't mean you can't build your ELFs in eclipse, and the rest of your project in Android Studio.


Looking for the amount of APKs that have at least one .so in them, the reality speaks otherwise.

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.


Having an .so in your app doesn't mean the majority of work in your app is NDK work. And it's often limited to just one or two team members while the rest are working on the java side of the app. You also don't need the NDK at all to include an .so in your app. You only need the NDK to build the .so. When it comes to regular android java work (which is the fair share of android development, as google obviously knows from anonymous statistics) - Android Studio takes eclipse hands down.

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.


If you look at my karma and post history you can easily find me.

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.


I doubt you have tried Android Studio support for NDK versus Eclipse CDT.


Your assumptions are incorrect, and rather offensive.


Uhh, have you?

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?!).


So you are highly offended that I assumed you never used the NDK!?! A programming tool.

Ad hominem reaches a new level.


I switched to Studio 2.0 hoping for better NDK support over 1.5.

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?


Does anyone ever actually experience greater emulator performance under Windows? Each time an update is pushed, I am excited to always see "XX faster emulator" listed as an improvement - but never do I see a notable improvement... So far, the only usable "emulator" that I've found is actually virtualization using Xamarin's Android Player...


What's wrong with a sane makefile oriented thing with a small tool chain and letting the user pick the editor/IDE? Why does every large company build out this ridiculous IDE for their product?


I usually use the command line for Android work, with emacs. But people demand IDEs these days. So here we are.


Any chance you feel up to sharing? I've been wanting to get into Android dev work, but I'm staunchly a CLI guy, and I've had a hard time trying to figure out the IDEs Google keeps pushing out. Not to mention the obscene sizes of these damn IDEs.


most Android projects these days use gradle. install it via your favourite package manager, and if the project is well-configured a simple 'gradle build' will do the trick. at the worst you might need to download the latest Android SDK, point some environment vars, and do a basic fetch of the most recent build tools.

android is rather cli friendly - a full 50% of the devs I know use vim or emacs.


I don't have any tricks to share. Just build the app with the command-line tool, and the included android.el will do the debugging integration for you.


Dat debugger doe.


I need to upgrade, the amount of random steps I had to take to make the old AS even remotely manageable was a headache.


Why's it so hard just to get adb these days? My adb requires like 5gb of other stuff


And it is still slower than good old Eclipse.


Hmm... no? I find Android Studio way faster in daily usage compared to Eclipse, and above all it's way more refined: I don't have to "clean" my project twice an hour, and dependencies management and writing is much easier.


Android Studio slows down my whole machine to a crawl even if it's just running in the background doing nothing. I throw piles of stuff at my machine without a slowdown (see my other post) and the only thing that manages to kill any and all performance is Android Studio. Eclipse runs like a dream in comparison.


I don't think it's the IDE, it's the build system. When Google pushed everyone over to Android Studio they also pushed everyone from Ant to Gradle. Gradle is supposed to be a better Maven but it's just dog slow. Just typing gradle --help takes over 3 seconds on my Macbook Pro.


Migrating to sbt-android has been a revelation coming from Gradle.

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.


I really don't get their hype around Gradle, if it wasn't for it, most likely no one would care about Groovy any more.

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.


As far as I know, sbt-android just recently got even more support/features for NDK (on top of the existing support):

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


Thanks!


Was it ever popular in SV? No. That doesn't mean no one is using or cares about it.

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 popular in Germany around 2007. All JUGs were doing presentations about Groovy and Grails.

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 remember those days. Not a lot came out of those presentations, though. It was a lot about Java guys having a bit of dynamic language envy, while having to code with Struts and 1.4 Swing all day. A way of getting that hype and with it some new tech to play with into the enterprise by a backdoor. Which is way too hard to do.

Mobile dev being new, even Java developers get to play with more shiny toys. For good or ill...


It's a stretch to say Gradle "uses Groovy". In practise, it more like uses a tiny non-Turing Complete subset of Groovy.


No, large parts of Gradle are actually implemented in Groovy. You're referring to the DSL, which can be used purely declaratively, but it's not limited to such use (you can use all Groovy language featured in Gradle scripts).


> large parts of Gradle are actually implemented in Groovy

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.


Put

    org.gradle.daemon=true
in your .gradle/gradle.properties. Slow startup is an old JVM problem.


> Slow startup is an old JVM problem.

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.


I know you're getting down voted, but I agree. In my experience, in both Windows VMs and on OS X, Intellij is just slow.

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.


from my exp on Mac. Intellij is the fastest IDE. Sure beats the shit out of Xcode.


In theory, the new "instant run" feature addresses some of the "clean, build, deploy, run" pain.

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


Did you give https://github.com/scala-android/sbt-android-protify a try?

It exists longer than Google's "Instant Run", is faster and works without flaws (in my experience).


Thanks. Will definitely look into it.


Not just slower , it does not fit to native look and feel, You are not going to believe me how much time I spent for fixing ridiculous font rendering for Android Studio, at the end I just gave up (in Ubuntu. I tried all kind of patches, TuxJdk, changing arguments for OpenJdk, OracleJdk , changing fontconfig, using infinality and anything you can imagine. nothing works). Right now I am switching to Xamarin,Perfect support from Microsoft (because it is important strategic product for Microsoft. I remember one year ago I predict Microsoft will buy xamarin and open source it).Bash is coming to Windows and lets be honest , none of java's IDEs can compete with Visual Studio.

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.


> You are not going to believe me how much time I spent for fixing ridiculous font rendering for Android Studio, at the end I just gave up (in Ubuntu. I tried all kind of patches, TuxJdk, changing arguments for OpenJdk, OracleJdk , changing fontconfig, using infinality and anything you can imagine. nothing works).

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


Yeah. There's something to be said for having a highly developed intelligence for building great IDEs and libraries at the _organization level_ rather than just at the individual programmer level. Despite its reputation for hiring the very best programmers in the world, Google's ability to create a really great developer toolchain for Android didn't measure up to what Microsoft has been doing for decades.

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.


If I would be on the Android team, I would feel ashamed that Microsoft in less time that they have introduced C++ support in Android Studio, already has a better developer experience than Google will ever managed to do.

On the other hand, I guess if they had a choice, the NDK would probably not even exist.


Yeah, it just shows that Google clearly sees app developers as sharecroppers. "Don't like our terrible software quality and negligence? GTFO, there are hundred other desperate people writing the same app."


Much better to use though. Eclipse just feels like drowning, if you're not already into it.

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.


Yeah I just started dabbling with it and I have an ultra fast windows 10 laptop with solid state drive and I'm amazed at how long it takes to go from changing a line of code to running it in the emulator.

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.


If you wanna feel something rare, find a win98 box on a pentium 2/3 and run turbo pascal IDE. Enjoy the paradoxical bliss.

ps: TURBO.EXE amounts to a whopping 600KB.


LightSpeed C: modify-to-run in a couple of seconds (often).

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.


Or if you're into something more modern, Delphi 7 will do. And it'll probably run on modern Windows.


I can't decide which I prefer, the charm of text mode(TP7.0 was really pretty and nice) or the look'n'feel of early windows GUIs (Windows 3 / OS2 warp beveled boxes and pale hues are so nice).


MS-DOS 3.3, Turbo Pascal 6.0 and TASM, all in a 1.44 floppy! :)


I have a weird fetish of making everything fit on a floppy. Acute Kaytosis I guess. If I had functionning floppies I'd prep a DOS3 one like yours :)


Speed is kind of a funny thing with IDEs. All of my typical workflows are faster in Intellij than they were in Eclipse. YMMV if you are hitting different features than I am.


Not my experience on OS X.


Android development was invented by Google to convert programmers who use Windows into programmers who use OS X.


Not only it is slower and takes piles of RAM, it still doesn't support the NDK properly, which keeps being experimental and lacks the majority of features that Eclipse CDT and ndk-build have.

Eclipse CDT with Ant + ndk-build finish a build before Gradle manages to parse all its configuration files.


So, how to enable material design?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: