I’ve been working my way through some lessons and examples, learning about writing apps for Android. Overall, I’m underwhelmed. The environment and API just isn’t as productive as working with iOS, and it doesn’t seem to be as polished. Where Android seems to suffer is the lack of a single, central unifying approach or philosophy to things like application interaction and user interaction. The home screen is a cluttered mess that offers both pages which you page between, or you can get a single view of all the apps on the device. While iOS isn’t perfect, it is at least a little more consistent (for a interesting take on iOS and Android from a usability standpoint, Don Norman and Jakob Nielsen offer some thoughts here). Android does have some concepts and features I do like, and it would be really nice if they appeared in iOS. Here are some of the highlights and lowlights so far with Android.
Bad: UI Appearance and Layout
The default controls are, for the most part, ugly. They clearly weren’t designed by someone with some kind of artistic talent or flair. They look like the kind of controls a technologist would create. It makes for apps that are not great to look at, and don’t invite you to actually use. Fortunately, you can apply a theme to an app to change the look of the controls, but this of course means each app could look completely different (meaning things like buttons look different from app to app).
Layout of controls is clumsy and awkward. Part of the challenge is, of course, having to deal with a plethora of screen sizes and resolutions. This does add a level of complication that Apple has removed by limited the devices available to iOS. However, the built-in layout managers make it hard to make good-looking apps.
What doesn’t help is that there isn’t a decent GUI editor to draw the layout. I tried an open source tool, called DroidDraw, with limited success. There is a new, experimental editor that came with the 2.3 toolkit, but it has a number of issues. First, because of the way that layout managers work (where you nest one within another), it is almost impossible to actually manage the nested layout managers through the new tool. As a result, you end up editing XML to lay out the UI components. Sure, this allows you a fine degree of control, but this is 2010, not 1995. I thought we would have moved beyond having to hand-edit XML layout files to design user interfaces. Interface Builder from Apple is far superior, since it offers both a GUI view of the interface, plus offers a nice, hierarchical view of the controls, views, etc so you can do some design operations that just can’t happen via a picture of the interface, like determining the order the controls appear on the screen.
Just from looking at a few apps I downloaded from the Android Market, some apps basically either design custom themes to try to make their apps look better, and a couple may actually use custom controls to do their thing. While it may be cool from a developer’s point of view, it can and will be confusing for users if they don’t really know what common controls like buttons, checkboxes, etc normally look like.
Mixed: The Development Environment
The recommended development environment uses Eclipse with some custom plug-ins. The good part is, of course, that you get all the stuff in Eclipse that most Java developers are already familiar with. You use the same interfaces for source control, Java project interaction and Java editing.
The downside is that you end up with all of the baggage of Eclipse, including its bloated size and the occasional “spinning wheel of death” as it tries to build lists of available options for contextual editing. That last one can be pretty frustrating when you know the method name you want, but Eclipse freezes up while it thinks for a bit about what to put in a menu you are going to ignore anyways.
The emulator that comes with the Android toolkit works well enough, but any sort of fine control of the emulator actually happens back in Eclipse through the DDMS perspective. You can’t set things like current GPS coordinates or emulate call activities via the emulator’s GUI. That has to be done from Eclipse. Creating virtual devices is pretty easy, but there is no way to edit them once you create them. If you want to change some aspect of the device, such as the OS version, you basically have to create a new device from scratch. I’ve created and destroyed a lot of virtual phones so far.
As with any emulator, it has limitations. Some things, like Bluetooth, USB and calling features don’t work. I haven’t had much luck in getting anything about of the simulated GPS yet. Some commands, like device rotation, are completely hidden (I only found about them via a Google search, and yes the commands are in the documentation. Something this common should be more obvious). Some of the limitations aren’t unique to the Android emulator (the iOS emulator has similar limitations for the most part, although it is a far richer interface and more self-contained).
Mixed: Android Multitasking
Android multitasking for the GUI/activity part of an app is very similar, conceptually, to the one used in iOS. One big difference is the ability to have services running in the background, and that can be started by the OS for you without user interaction. But GUI applications are basically set to “not running” if they are no longer in the foreground. Like iOS, you need to make sure you save your state at critical junctures to keep from losing state or information. One thing that is disturbing is that your app can be killed by the OS without any sort of warning. At least in iOS, you are given a chance before the app is simply stopped before resources are reclaimed.
Except for services, I’m not convinced that Android multitasking is any better or worse the iOS. In concept, they are similar, and I do believe both do an adequate job of balancing responsiveness with managing limited resources.
With services, though, it is good and bad. The good is that, unlike iOS, you can write something that does actually run all the time, even if the GUI isn’t available. But, these services are hidden, and if you had enough of them running, it would impact device responsiveness and battery life. There are ways, on the phone, to find and stop them, but the average person isn’t going to understand how to do that, since it involves digging through several menus in the settings to find them. That isn’t to say that the iOS approach to shutting down apps is immediately obvious (double click the home button, then touch and hold an app icon? I don’t think anyone would have thought of that in a million years without direction), but once you do know it, it is pretty simple to accomplish. The iOS learning curve on managing apps is a bit steep, but it is simple.
Good: Intents and Interprocess Communication
Android has a very slick way of allowing for interprocess communications, and to allow apps to take control of events that occur on the device. Android initiates all actions by sending out an Intent, which is basically a message that says “here is what I want someone to do”. When apps are installed, they include a list of all Intents that they are will to handle or react to. It is, in essence, a very simple but powerful publish-and-subscribe messaging system. As an example, when the user launches an app, the system broadcasts an Intent that says “start this activity/app”. Using data in the app manifest, the appropriate activity within an app is started, and the GUI appears. There are rules that the OS uses to determine what Intent is sent to what receiver, and when one is chosen, it is given an opportunity to either process and consume the Intent, or say “no thanks”, which means the next one in line gets its shot at the Intent.
This approach allows apps to interact with the device and other services in a fairly transparent manner. It allows many apps to receive and handle system events in a simple and straightforward way.
Mixed: Android API Flexibility
Most of the features and services in the Android API offer a high degree of flexibility, which is both good and bad. This sort of “try to accommodate everything” flexibility” is fairly standard in open source technologies, and seems to stem from a desire to try to allow people to do almost anything they want. While it does allow a developer some latitude, this approach tends to make things more complicated or even difficult when you want to do simple things.
Take, as an example, notification of the user something has happened. To do this “right”, you end up with about a dozen lines of code, as you first have to find the notification manager, get your application context, create 2 different message strings (one for the notification title, and one for the content), create an Intent, then create a PendingIntent, create the actual notification object, set the event info, then finally tell the notification manager to display the data. Except for 2 lines of code, the rest is all boilerplate necessary to get a single line of text displayed to the user to say something happened. If you want to add sound, vibration and blinking the LED, you need another dozen or so lines of code.
The upside, though, is that this flexibility means you can get exactly what you want, and aren’t limited to what the API says are acceptable options. In iOS, the notification is far simpler, but your options as an app developer are limited to the 2 or 3 different combination of options that iOS says you can have.
Bad: Android Training Books
I had hoped that, like I did with MacOS and iOS, I would be able to find a good book or two with a series of lessons that would teach me about writing Android apps. My ideal was a book that covered a major topic per chapter, and each chapter had example exercises you would work through, and that those examples would be complete working apps. I was trying to avoid having to sign up for a course, since I don’t really have the time to dedicate full days, and most courses don’t go deep enough in 3-5 days, they barely touch the surface. Working with a book (or tw0) would let me work at my own pace. I have learned other technologies like this in the past (VB, Visual C++, EJB, MacOS, iOS), and figured that with Android’s popularity, a good book should be easy to find.
Was I wrong. I started on one book, which had a single sample “hello, world!” type app at the beginning, and that was the end of the sample code. It had tons of code fragments, but not in the context of a larger app that you worked on as you went through the book. I abandoned that after getting about 1/3 of the way through it, and tried a second book. Both were from the same publisher of an iOS book I used for the same purpose. The second book was worse: not even a simple app to start with. Both will make excellent reference material for later, but were less than ideal as training books. The 3rd book, Professional Android 2 Application Development, was an improvement and is the book I”m using now.
However, the book itself has problems. The chapters aren’t in any particular sequence (for some reason, the author decided that knowing about location services was more important than learning about user notification first). A lot of the code samples, even the downloaded ones, don’t work as-is. I’ve been able to fix them up anyways, thanks to the message board that the publisher maintains for the book and other sources I found via Google. Near the beginning, the author claims you can cover a lot of the chapters in any order, but the apps that you work on are built up over the course of the book, so skipping chapters means skipping functionality in your project.
Uncertain: Local Android Community
In Calgary, there is a semi-regular gathering of iOS developers using the DevCamp approach. This is organized by Michael Sikorsky at Robots & Pencils, and has been a great way for iOS developers to connect. There are also several LinkedIn groups for iOS developers. Apple holds their annual Worldwide Developer Conference, which includes presentations and opportunities to work with Apple engineers over the course of 5 days.
I have yet to find a LinkedIn group dedicated to Android. I have had no luck finding any kind of regular or semi-regular get-together for Android developers in Calgary. Google apparently holds a 2-day conference about Android in May, but the chance to interact with Google engineers appears limited.
Okay, So What Does This Mean
So far, with some exceptions, there doesn’t seem to much to recommend Android as a development platform. However, despite some gripes, Android isn’t the worst platform I’ve encountered. Writing applications for Windows using C++ and the Microsoft Foundation Classes is comparable in some ways, worse in many others (particularly the variation between how MFC works vs. the underlying win32 functions). Writing applications in Java and Swing isn’t a lot of fun at times (hours and hours of typing, and dealing with layers and layers just to put up a scrolled list of items, yuck). Living with the restrictions that iOS does put around some parts of writing iOS apps (like not allowing serial communications over Bluetooth without being part of the Made for iPod program) can get frustrating. Working with Android can seem a bit of chore, but it isn’t exactly punishment.
If nothing else, keep in mind that any app that you build will be in an ecosystem that (as of today) contains about 200,000 apps and millions of handsets in use worldwide. There is plenty of potential for an app do to well. Also keep in mind that the state of Android and the development tools is constantly in flux, and that things are going to improve over time. The tools today are not necessarily the same tools you will use tomorrow.