Android Development Retrospective, Part 1

After wrapping up development on the Android version of Lens•Lab last night, I though I should sit down and write a retrospective of my experiences.

I’ve been developing apps for iOS for a few years now. Before that I had *some* programming experience (creating desktop apps in VB.Net and C#) and really no formal education in programming or computer science (or anything for that matter.)

6 months ago I got hired to work for a really cool company on some neat iOS projects. Some of the iOS stuff relied on back-end services written in Java. So I got to learn a little Java.

It sounds like my team at work is going to be taking over some Android projects so I figured now would be a good time to get my Android learn on!

I started building the Android version of Lens•Lab a few months ago. I got bogged down in coming up with the UI (that took far longer than it should have) and really accelerated the development within the last few weeks. So really, the bulk of the development time has been spent in my free time and weekends over the past couple of weeks.

So I’m going to look at building Android apps from an iOS developer perspective. I’m by no means an expert on Android or Java so bear with me. Some of my criticisms of Android might be coming from a place of ignorance. If there’s anything that I’ve got wrong, tell me so I can change my wrongness!

One of the major pain points when starting to develop software for Android is the fragmentation in the software and hardware ecosystem. There are (according to Google Play) over 2,200 different devices that can run Lens•Lab. Since version 2.2 of the Android OS there have been 8 updates (both major and minor) with 8 different API levels. There are 4 different screen density tiers. There are countless third party “themes” and skins that affect the appearance and behavior of Android devices. There are a multitude of display resolutions and CPU performance levels.

One person’s “diversity” is another person’s “fragmentation.” I suppose the vast differences in hardware and software can be seen as a plus but from the beginning developer’s perspective it’s a little intimidating. Where do you start? What types of devices will you target? What is going to be your minimum OS version?

Operating system uptake in Android land is far different than in iOS land. With iOS, *any* device that can run the newest operating system tends to within a month or two. Right now, iOS 5 covers 95% of the iOS installed base and it’s only 1 version behind.

In Android land, the decision to update OS versions is, most of the time, left up to the carriers and hardware manufacturers. You might get lucky and have a carrier or hardware manufacturer who bestows an operating system update on you but most of the time most people won’t be so lucky.

So there’s that.

Personally, I didn’t run into any major API issues (Lens•Lab doesn’t use too many whiz-bang API features) but I was a little concerned about CPU performance. Blurring bitmaps in realtime (even with a fast box blur) is no trivial task. Not knowing anything about the hardware you’re running on makes it hard to make performance tradeoff decisions at runtime. More about how I solved this later.

Language:

Java compared to Objective-C is more simple and straightforward but it also seems much more pedestrian. I’ve come to love Objective-C’s syntax and named parameters so fucking much. It just makes code more easy to read and understand, and also helps the code convey more meaning.

Where Objective-C is lousy with brackets, Java is riddled with parentheses. Keeping track of all the parentheses is a full time job.

IDE:

Xcode, for all its faults, is a very beautiful IDE. Once you get it nailed down, it’s a great environment in which to build great applications. I’ve really gotten used to Xcode 4 and all the niceties it provides. Using the iOS simulator is just fantastic. Since iOS API and code is compiled to x86, it ends up running faster in the simulator than id does on any real device. Compare this with Android land where running in the emulator is an exercise in frustration.

Eclipse has some really cool refactoring tools but that’s about all I can say for developing Android apps in that IDE. Everything from autocomplete to the severely broken GUI building tools feels, well, just wonky and janky. I don’t know how else to describe it.

Oh, and don’t get me started on all the XML editing you’re going to be doing when you make an Android app.

Hardware:

To develop Lens•Lab for Android I relied on two pieces of hardware: a Nexus 7 running Android 4.2.1 and an older Motorola Droid running Android 2.2.3. The Nexus 7 is hard to beat price wise (only $199) and the Droid was a friend’s that was just sitting around. I felt it was important to experience the app on as wide a range of hardware as possible and I also thought it was important to support older versions of the operating system to a reasonable extent. Supporting down to 2.2 (API level 8) covers around 95% of the installed base so that’s pretty good.

Post navigation

One Response to Android Development Retrospective, Part 1

Interesting retrospective!
I have experimented with Android development a little bit, and ran into the same issues as you did with the simulator and with Eclipse. Congratulations on overcoming your frustrations and shipping an app!