Sorry for not updating recently – it has been hectic with the holidays, grad school applications, and surviving hoards of New York shoppers.

Currently my chief project is becoming reacquainted with my old nemesis Java and its many idiosyncrasies.  As I told a colleague yesterday who was considering trying to learn Java, it may be the worst non-binary language for a first-time programmer to learn.  It is certainly quite powerful and feature-rich, but the level of minutiae and class hierarchies can be daunting for even seasoned programmers.  While I have yet to find a great Java book (probably because the aforementioned eccentricities are difficult to convey in coherent prose), Sun does have a nice online reference system – which seemingly hasn’t changed since the last time I used it in 2002 – and I have found a couple of nice example sites via stumbleupon.

(*Quick tangent – stumbleupon is probably the most addicting add-on I have ever used while browsing the web, and ranks up there as one of the best sneaky-useful programs around.  I have “stumbled” upon useful websites for web development, cooking, running, and even dog training.  Just an amazing tool).

Now, the reason I am trying to relearn Java is because I am focusing on creating applications for the Android OS.  That is a major reason why I rushed out to purchase a Motorola Droid (well, that and the fact I accidentally washed and dried my old phone) – I wanted to begin developing for the platform.  When I was then asked to port Dan Bricklin’s Note Taker for the the iPhone to Android, I knew I had to buckle down and start studying.

First impressions of Android development

My first impressions of developing for the Android OS is that the uncertainty about the hardware capabilities of the device running your app can prove bothersome at least initially.  Whereas with an iPhone or iPod Touch you have a relatively standard device (with obvious exceptions for different processors and the like), with Android the devices vary quite significantly.  The Droid, for example, runs Android 2.0 and features a tangible keyboard along with a touch screen and one of the fastest processors on the market, while the Droid Eris runs Android 1.6, is touch screen-only, and has a much slower processor.  This argument, of course, mirrors the one that has waged between PC and Mac users for years – the PC market provides the potential for more powerful and full-featured systems, but Macs are a consistent and known platform with solid performance for most common usages.

Now, I have two options:  (1) limit my development to devices running Android 2.0 (which presumably should have better hardware), or (2) try to make the program backward-compatible with 1.6, which should remain viable in the market for at least a couple more years.  Pick option 1 and I limit my available audience but cut down on time-consuming “optimization” for the slower devices, or pick option 2 and have a more popular program but one that would show significant performance differences across platforms.  Right now, I am leaning toward option 1 because more powerful devices are winding their way through the pipeline, and legacy support/backward compatibility in the handheld world seems less important than in other tech fields.  At the same time, though, I will still try to make the program as usable on 1.6 devices as possible, even if it might require some tweaks in functionality.

I will post updates on my progress, and I welcome any suggestions or insights about this endeavor.

No Comments »

Comments are closed.