One of my weekend projects lately has involved hacking around on my shiny new Motorola Droid, which has proven to be some excellent fun. Despite the fact that I'm compelled to suffer through Java and (shudder) Eclipse, there's a lot of enjoyment to be had in fooling around on a new platform.
Android is really a damned powerful little OS, and the libraries are consistently proving to be fairly well planned and executed, at least as of the 2.1 SDK. As with any platform it has its quirks you have to learn to deal with, but honestly it's a lot less eccentric than I would have expected - especially for a mobile platform. My experience in the past with PalmOS and Windows CE had me concerned that development would be a painful process of trial, error, and wanting to throw the handset out the window, but thus far the only real frustrations I've had involved Eclipse wanting to vomit at random times.
My first serious project for the Droid is a simple app to send text messages to multiple contacts at once. Basically it's just an automated layer on top of the existing Messaging app, offering a simple list of contacts with a tick box for each one. You check off who you want to spam, optionally pop up a list of alternate phone numbers for contacts with multiple ways to be reached, type your message, and away you go.
So far things are looking pretty good. The app works, provides a functional but somewhat hackish UI, and generally everything is stable and handles all the weird little edge cases like contacts with no phone numbers and so on. Most of the exploration involved has been related to the UI implementation.
My usual approach to learning a new platform is to get enough tools to build something via a naive, simple method, and make a list of all the inconveniences and roadblocks I encounter. Armed with that list, I can then go research the solutions to each problem, which almost always ends up revealing better ways to solve the original problem in the first place. This is an iterative process - sometimes it takes three or four attempts to get a really solid implementation, but it converges towards good code very quickly. I learned UI development on OS X in around a week and a half with this approach, and I picked up the fundamentals of Android's UI systems in a couple of days.
This project has been no exception. My current UI implementation builds a massive list of controls, averaging five or six widgets per contact. This isn't problematic per se, but it does perform rather sluggishly with large contact lists, especially on the device emulator (although the emulator's performance just seems to suck in general). It also means I find myself lacking a lot of the little polished details of Android's UIs.
For instance, in the Contacts app, when you touch someone's name, the entry highlights orange. If you long-touch the entry (the Android equivalent of a right-click), the entry slowly fades up to white and then flashes before popping up the context menu.
I really dig little details like that in UIs, and I want my app to fit in seamlessly with the Android experience, down to the pixel. If the app doesn't feel like it could have shipped with the phone, the UI design is a failure IMHO.
I got the highlighting working, and even properly found a way to support the various methods for focusing and selecting controls on Android (there's basically a tab-like navigation system for devices that don't have touchscreens, there's at least theoretical trackball support, etc.). However, the little white-flash animation eludes me, and I dread the thought of investing a couple precious Sunday afternoon hours in an animation that'll look out of place next time Google releases a platform update with a new visual style.
That means it's time to dig deep, get dirty, and steal the code to some of the built-in apps so I can figure out how to do things in a "correct" manner. Again, I want this thing to look like it came from the same shop as the rest of the phone's software.
Fortunately, Google has been very generous with their Android development resources, and code and techniques are easy to find. The solution is simple: there's a ListView widget which can be given an adapter class that populates the scrolling list with sub-widgets. Done carefully, this means you can do some pretty slick stuff with nested controls and whatnot. Exactly what I wanted... perhaps I could have saved a couple of hours if I'd discovered this thing sooner, but doing the implementation by hand gives me a much better understanding of how the UI system works in general, and how to get the most out of the ListView itself.
So for now, I'm off to go rewrite my UI to use ListViews, and then hopefully I'll be happy enough with MassText to go ahead and release it for public consumption.
I plan to provide the code for free via Google Code, and will likely make the final app available on the Market for free as well.