Android Studio - a frustrating experience in usability

Lately Eclipse has become excessively slow and unstable. So I decided its time to take a look at Android Studio.

I downloaded, and installed with the default settings - mistake number one, as I found out later. Startup took forever, just like Eclipse. I created a new project, choosing the Settings Template, as I know I'm going to need a Settings page for this app, which also took forever. When it eventually finished, there was an error about gradle failing to sync...so basic operations like editing and compiling will not work. WTF! So about half an hour of poking around and searching the net later, I find that my proxy got set when I installed, but today I'm working from home. Apparently some of the other slowness is attributable to that too, as it seems much more responsive when I have disabled the proxy.

Advice #1: When designing software, use the system proxy settings, don't introduce your own. People move between networks, and they shouldn't have to reconfigure a dozen separate places when they do.

So now I have a project, and gradle seems to be happy for now. I'm going to be using websockets, so I add in autobahn, and its dependencies jackson-core and jackson-mapper. But before adding any code that actually uses them, maybe I should make sure the basic boilerplate that was generated compiles and runs.
Compiling goes OK. So now to run on my emulator. I am targeting a specific device here, so I don't really want to run it on the Android-L emulator that was installed by default, so time for some more downloading. Start SDK manager from the Tools menu. A dialog comes up, shows a progress bar goes across the screen showing me that SDK manager is taking a long time to start, 10 seconds later it disappears. Nothing happens. Start checking the paths in config - is there something missing. 5 minutes later, the SDK manager appears on the screen. Check RAM and CPU usage for an explanation - 5GB free, nothing taking more than 4% CPU. Kill SDK Manager, and check again while it is starting. The same. So its not a CPU or memory problem. 5 minutes, maybe a network timeout. Maybe its getting its proxy settings from yet another place that I haven't yet discovered and is waiting for the timeout.

Advice #2: Pop up a window, or at least a splash screen as soon as you can, to let users know that your program is starting. And don't do network stuff on the main thread. Preferably put a message somewhere saying what you are doing when something might take a long time, so users know what to troubleshoot.

Once SDK Manager has started, I select the SDK I need to download, and start the process. It fails. Why? Because it does not have permission to write temporary files. Since Vista, Windows has had this policy that programs have no business writing into the Program Files directory.  This stops viruses and trojans from overwriting perfectly good programs. It's a good thing, and Linux and Solaris have similar policies.  Temporary files go in the system TEMP directory (/tmp, /var/tmp, %USERPROFILE%\Temporary Files, whatever). Files that need to be updated by a program go into a directory for that purpose (/var/cache/..., %USERPROFILE%\Application Data\..., whereever).  This isn't an unusual or unreasonable requirement.  But applications like Android Studio, and Eclipse, choose to ignore it, which causes headaches to users on all platforms.

Advice #3: Follow platform conventions about where to put your files. It's understandable in 2005, when Vista has just come out, that some software has not had time to mend the error of its ways. In 2014, it is inexcusable, especially for cross platform software that also runs on platforms that have had the convention of separating programs and data since at least the 1980's.

To resolve this, I managed to set the SDK to point to my old copy from the Eclipse days. I think I'd already gone through this problem in the early days with Eclipse, so I had an SDK already in a separate directory. The latest SDK in there is Kit Kat, not Android L, but the bonus was that it already had the even older SDK I need for my emulator. A bit of patching of project files to set the compiler and target to android-19 instead of android-L, and I'm back at the point I was before with the older SDK installation. I could have just updated the SDK now, but I don't fancy waiting around for the 500MB download to complete.
So now to launch the emulator. The custom device I created long ago is now visible, but it isn't working. Eventually I ended up deleting it and recreating. It still didn't work. Unknown to me, the fact that I've installed the Intel HAXM acceleration through SDK manager has made the Intel target visible (which I chose, as it is supposed to be faster, and I don't really care about ARM vs Intel differences for this Java only project), but the HAXM accelerator is not actually installed, only downloaded by the SDK manager. Some messing around at the command-line and a web search later, I find this info, and manually install the HAXM accelerator. But this isn't the only thing stopping my emulator from starting. Another web search, and I find that Hardware Graphics acceleration is only available in Android 4.3 and later, something that wasn't at all obvious when I checked the box. In both cases, there was no obvious error message. The emulator just failed to start, and only by going to the command line and trying the command where I could see the output was I able to diagnose the problem.

Advice #4: When you install things, install them properly. Or at least give a prominent warning to the user when you find it is not properly installed, telling them what manual steps they need to do. And if you have options that only work in certain situations, say so, right there next to the checkbox, so users don't waste their time selecting options that won't work. When users don't heed your warnings, don't just fail silently, tell them what went wrong so they can quickly fix it.

What should have been a five minute session getting the initial boilerplate for my program set up and working turned out to be a four hour mission. I'm tired, so I'm putting it away for now. When I come back, I'll probably be doing most of the work in Emacs to avoid the hassle. Development tools should not be like this. When you have a download that tops 2GB when you add up all the parts, at least some of that code bloat should be going into usability, especially for that first setup experience. I've never used IDEA before, and to be fair, most of the problems seem to be with the Android specific portions, but still, I don't think I'd consider paying for the commercial version IDEA based on my experience today. It may not be fair, but that is how association with a mess like this affects peoples' perceptions. And Android Studio is still a beta product you say? It's been in beta for over a year now. It's had plenty of time to improve, and like every Google product by the time it comes out of beta, it either won't be relevant any more, or you'll have missed the boat if you aren't already using it.