One day, the dreaded message comes. It might come from your immediate boss, it might come from his boss, or even the Senior Vice-President In Charge Of North American Operations, West, but the message is still the same, and still just as anxiety-inducing:
"We need a mobile app."
If you're one of the hapless few "in charge" of a development team, this is about on par with the fear and excitement that accompanied the phrase "We need a web app," more than ten years ago. The same questions, the same insecurities around your development staff, and if you were actually a part of the development world more than ten years ago, you probably remember the on-the-fly discoveries and after-the-fact realizations about what you didn't know that you didn't know.
Relax. While no 900-word essay can cover the entirety of the mobile development space, a few things about Android--and your team's relationship to it, even before they pick up their first Android book--are pretty easy to cover.
It’s just Java
One of Android's greatest "pluses," from a Java team manager's view, is that 90% of the tooling, ecosystem, and experience is one that is familiar to the Java development team. This is because at its heart, Android is "just Java." Development teams write code in the Java language, extending and using other Java classes, calling Java methods and using Java IDEs.
This means, then, that it becomes rather painless for a
It's Not just Java
On the other hand, Android is not Java -- in some cases, deceptively so. Android isn't actually a Java Virtual Machine; it's the Dalvik Virtual Machine. After Java classes are compiled there's a separate tool to convert JVM code into Dalvik code. Nor is the entirety of the JVM's behavior going to remain identical to how Dalvik behaves; ClassLoaders, for example, may be subtly different, or certain libraries present in a Java5 VM may be missing.
Normally this won't be something that the Java developer has to worry about, but some projects, particularly those that want to manipulate Java byte code on the fly (Seam, for example) or those that want to emit byte code on the fly (some Aspect-oriented toolkits) will have issues here.
It's just a phone
Many things are being said about the Android devices and their kin, using adjectives like "revolutionary" and "game-changing", but one thing needs to be kept clear during the development experience: after all is said and done, it's just a phone. It has limited screen real estate (320 by 480 pixels is common), very finite processing capabilities, and very very finite working memory and/or storage, on the order of "megs", not "gigs".
Nor does Android use traditional Java APIs to bring the UI to the user--instead of Swing or AWT (the traditional Java desktop APIs), or servlets/JSPs/JSFs (the traditional Web APIs), Android brings its own UI metaphors--the Activity, the Service, and the Intent, just for starters--that development teams will need to spend some time with.
Designing an app for this device requires a fresh perspective and careful re-examination of expectations and implementation approaches. User interface and user experience are not going to follow the same styles and approach as the canonical "forms over data" Web application. You don't have the screen space to do that, and, moreover, users could've used the phone's browser to hit your Web app if that was all that was necessary. With the smaller profile comes a new set of opportunities and technical features to explore, like Geolocation, camera, sounds, and 2D/3D animation, features that just weren't really "there" in a Web app.
Performance problems can't just be whisked away by installing a cache and another couple of gigs of memory on the server, or installing another server, for example. In fact, Android keeps a very close eye on applications running on the device, aggressively reclaiming resources as it needs to, and if it appears that an application is getting a little carried away, Android has no qualms about killing it off (the dreaded "Force Close" dialog) to make sure the device is always responsive--and always able to take a phone call.
It should also be apparent that the network latency here will be critical: not only is the phone not going to be in the data center with the server, but it will quite likely be executing on a much slower network (3G or 4G) than the traditional broadband connection. Thus, traditional tricks like lazy-loading data from the database are not nearly as effective as they might otherwise have been in a traditional Web app.
In many ways, this whole story could be subtitled, "The Revenge of the Client-Server".
It's Not just a phone
But at the end of the day, the amazing thing about this device is that while it is a phone, it is so much more than that: it's a general-purpose computing platform that can bring so many good things, including your business and their goods and services, right to the user's eyes in a much more intimate and personal way than even the home computer Web browser could.
People carry their phones everywhere: to work, to play, into the shower (!), and even to bed. If you can brave the challenges that the new platform brings, you have an opportunity to gain an important edge on your competitors--and maybe have a little fun doing it in the meantime.
Ted Neward is a consultant, instructor, speaker and writer on Java, .NET, XML Services and other technology issues.
This was first published in December 2010