Slashdot Mirror
Google Launches Android Studio 2.0 With Instant Run, Faster Android Emulator, and Cloud Test Lab (venturebeat.com)
An anonymous reader quotes a report from VentureBeat: Google today launched Android Studio 2.0, the latest version of its integrated development environment (IDE), with a long list of new features. You can download the new version for Windows, Mac, and Linux now directly from Android.com/SDK. In November, Google unveiled Android Studio 2.0, the second major version of its IDE. Version 2.0 brings a slew of improvements, including Instant Run, a faster Android emulator, and app indexing improvements. Google released a beta in February, though it didn't say when the final version would be ready ([VentureBeat] speculated in time for its I/O developer conference in May, and the company debuted with a month to spare).
The full feature list includes Instant Run, Android Emulator, Cloud Test Lab, App Indexing, and GPU Debugger Preview.
Two Google Android articles in one day. This is too much!
Dave's first rule of software engineering; All build systems are terrible, get used to it.
All build systems get ignored. In a decade and a half I've never seen anyone just use a build system, they always end up writing their own around it (or in place of it).
I still have more fans than freaks. WTF is wrong with you people?
I can't get too enthusiastic about the 'lightweight' wars when I'm so spoiled by cheap hardware; but it is worth noting that, unless they've really fixed the hell out of it in this release; Android Studio is about as far from 'lightweight' as they come. Running it is like picking up a decent size chunk of tungsten: you expect it to be heavy; but just how much heavier than you had expected is still a bit of a shock.
You'd think that an SSD, 32GB of RAM, and a 3.4GHz i5 would make starting an IDE containing a blank project at least reasonably fast-ish; but no, minutes later, gradle is still gradling away to itself and the lovely alien-on-every-supported-platform UI is lagging and waiting for it to catch up.
What baffles me is how the Intel x86 atom-based emulator manages to be so sluggish. Assuming you have the correct alphabet-soup of Intel VT-D and VT-X and whatever else they are lasering off half their SKUs more or less at random today, even Intel's fairly tepid desktop parts will quite cheerfully emulate roughly as many guests as you have RAM for. Until you open up the emulator that only needs to emulate some feeble, power constrained, phone-SoC atom part.
Then. Then you wait. A lot. This seems strange.
It is better to use Vim/Emacs (Spacemacs ftw!). Real devs however use whatever works best for them.
Agreed. I use both actually. Android Studio is kept on one monitor. I use it for syntax checking, auto imports, refactoring, etc. I do the real coding in vim on the other monitor (with portrait orientation). It took some effort to get vim to auto-load changes made by android studio, but it works very well now. In the Before Time when Eclipse was the standard for Android dev, I used eclim which eased the pain of Eclipse significantly. Thank goodness those days are over.
Anybody want a peanut?
The emulator wasn't slow before if you picked a decent x86 image. Instant run only works in the smallest kinds of cases and any amount of time saved with it is wasted by fighting it when you know it won't work...
The bigger question here is why does google spend time on toys like that rather than actually add stuff that people need? They are pushing material design - but you can't use cardview, recyclerview, and such in the UI designer and you're forced to go back to editing the UI by hand. Why do I have a UI then?
Seriously - I know this is just bitching and probably the last thing that the people who worked hard on 2.0 need but this feels like adding cupholder to a car without breaks.
Peter.
Probably because incremental builds are something quite different from code hop swapping.
Sounds like they *still* haven't managed to get a true offline version working yet.
Previous versions were horribly network dependent. Gradle would pull megs and megs of data whenever you started a new project (and at various other times). If you have a _fast_ network, it isn't too bad. If the end point is slow, or your ISP is typical American sloth service, expect to wait.
The less bad news was that their *offline* switch (which is actually a cached switch) will minimize those occurrences (usually) *after* you've waited through the initial construction.
The sad part is that there is *nothing* inherent in gradle that requires that behaviour. The devs could have chosen to package it to include the needed base libraries and default to a local gradle build.
Just my $0.02 (Canadian, before taxes)