Some time back, I wrote a post about the consumer hazards of the Android platform. I believe those issues continue to plague the platform, but I’m not here to repeat myself. Instead, I’m offering a bit of insight as a skeptical developer whose market demands expansion into the Android space. There is a clear opportunity in the mobile phone and tablet space with very few vendors operating and none who can do what we do. We’ve had an iPad app in alpha testing for a month now, and we’re expanding that offering to include iPhone, iPod, and Android phones and tablets. Now that I’ve spent a week doing some experimental coding, attempting to determine the level of effort required to achieve my goal of a major national product launch in six weeks, I feel at least minimally competent to make this assessment.
Steep learning curve
For those who have been coding in Java for ten years, including detailed user interface development on the web, desktop, and mobile, familiarizing yourself with the Android design patterns is a bit challenging. For the beginner, good fucking luck. If you’re not a seasoned professional architect or systems engineer with at least a few published web and/or desktop apps, I strongly encourage you to find a mentor who can guide you. There’s a very good chance you won’t be able to learn this in a college class, either, so find an industry expert and pepper them with questions via email or skype.
Java is awesome, but Android lacks infrastructure
We can all agree Java is a powerful, high performance, industry standard language. It offers a lot of great features, both in user interactivity and data manipulation. For all its wonder, though, it seriously falls short in some areas. One of the greatest value-adds included in Apple’s excellent iOS SDK is all the helper methods, tools designed to make things easy for the developer. This means more time focusing on the “what” and less on the “how.” If I want to download an image from a URL using the iOS SDK, it’s one line of code. On the Android 2.1 platform, it’s ten times that.
Concurrency limited to application level
Since iOS 4, developers have been taking advantage of thread management with Grand Central Dispatch (GCD), which offers intuitive functions for directing the operations of the program. GCD also offers the ability to take advantage of multiple cores if the device supports that, and it does everything for you. All the developer needs to do is specify what to do and whether it’s a background or foreground task. The operating system does the rest.
The Android system allocates a unique virtual machine to each app, which offers a layer of protection to the developer, but in doing so, it also eliminates any chance that the system could optimize threads outside the context of a single app. This ultimately means the concurrency tools do great things to improve your app’s performance, but do nothing to prevent other apps from hogging system resources.
Nagging little things
The documentation describing how to build an app that does anything other than display a static string is lackluster at best. At worst, you’ll run into issues like the barely documented permissions issue. I spent an hour trying to figure out why the web client was returning “permission denied,” only to discover I had failed to include the appropriate setting in the app manifest.
Ending on a positive note
I don’t want to give the impression that I hate Android or that I have no substantial reason for my remarks. I’m looking at this from the perspective of someone who left the Java corporate software world to get away from all of this shit. In short, Google is dragging ass, playing catch-up to the beacon of elegance that is Apple. Java developers are still waking up to the realities of social coding and open sourcery. Ruby and ObjC developers are cashing in on the benefits of git workflows and global village collaboration. It is equal parts frustrating and exciting, frustrating because of a lack of available tools, and exciting because of the opportunity for leadership and innovation.