Just so you know, I am not a shill for Amazon. More people in my family use Nooks than Kindle devices—in fact, I'm the only Kindle person. The really cool thing about the Cloud Reader is that using HTML5, JavaScript and a Web browser, Amazon has replaced a host of fat-client applications. Not only that but it has managed to dance around the Apple restriction that all applications must pass through the app store.

I'm able to use the built-in iPad Safari browser to access my Kindle purchases, effectively bypassing the app store and the Kindle app. The Cloud Reader can potentially replace three available physical readers, and Kindle for iPad, iPhone, PC, Mac, Android, BlackBerry and Windows Mobile 7. Now I don't anticipate that Amazon will suddenly stop distributing all of these eReader channels, but they live in a different world than I do. For those of us who create, distribute and support software for a living, limiting the number of channels we must maintain is a very attractive proposition.

This is True

As we muddle our way through the second decade of the 21st century there are two absolute certainties in information technology: The cloud and mobile devices are here to stay and are forces to be reckoned with and embraced. Make no mistake, the cloud is not dead. We are all suffering from an excess of cloud hype in the media and from advertising and marketing nonsense. But if we understand the cloud to be a model for ubiquity, always available on demand computing resources accessed via a network, then the cloud has been here for at least a decade (SalesForce.com) and will continue to be around for the foreseeable future. It doesn't matter if we are talking private cloud or public cloud, secured cloud or open access cloud; the cloud has fulfilled the idea of the network as the computer.

Mobile devices are harder to escape than flies on road kill. I live in a small rural town. The place where I get my hair cut is a cross between Floyd's barbershop on the Andy Griffith Show and Truvy's Beauty Parlor from Steel Magnolias. The patrons are straightforward, hard-working people. Yet on a recent visit everyone hanging out there was doing something with some sort of smartphone or other mobile device. And applications for mobile devices are becoming ever more sophisticated. Using your smartphone instead of a printed boarding pass is now old hat. I was looking at a mobile app for a major retailer. It provides the ability to scan a stock-keeping unit at the store. The application returns the price, quantity on hand, store location, and availability at other regional locations.

Paradigms

So why should I care about the Kindle Cloud Reader? Because it leads the way to the path we should be following to creating device-independent applications for mobile computing. Even if we don't now support mobile applications we will in the future. Laptops and notebooks are nothing more than expensive portable desktop systems. The laptop paradigm is the desktop paradigm. The machine is essentially a container with a substantial data store on which we can run fat-client applications. Connectivity to the network is only required when we need to share some information or when we need to connect with a back-office system.

Mobile devices—tablets, net books, smartphones, etc. are built on a new paradigm. Fat clients are out, disk space is limited, computing resources (CPU cycles) are limited. Mobile devices should be ergonomically sound, lightweight, extremely portable, energy-efficient devices. Mobile is green; desktop is not. They should be designed for use anywhere, anytime.

I am currently sitting at a desk banging this out on a reasonably high-end laptop. Using a laptop as a typewriter with auto-erase and spell check is a complete waste of computing resources, but that's the way we do things. Silicon and plastic are cheap (even though they are not eco-friendly) and electricity only seems expensive when you pay the bill for air conditioning in a Georgia August.

I could be using a portable device with a lightweight computing footprint but I'm not. And that is because we are still tied to the QWERTY keyboard paradigm. The virtual keyboards provided with most portable devices are only useful for brief email messages and occasional note taking. But that isn't important because the primary use of mobile devices is to consume information, not create it. That's not to say that mobile devices can't be used efficiently to capture form information or runtime information for engineering devices, it's just that the mobile device paradigm is better suited to consuming information that is provided elsewhere (like the cloud).

So Many OS's…So Little Time

Given that mobile devices inhabit a different niche in computing does it make any sense to create the same sort of applications for mobile devices that we use for desktop computing? No, but that is exactly what we have been doing. Virtually all mobile applications are written using native code—code that is compiled to run on a particular operating system—whether that be iOS (Apple's Mobile Operating System), Android (Google's mobile OS), Windows Mobile or something else. That means that if I am going to distribute mobile applications for my customers to use I need to maintain multiple code bases and probably multiple development teams. It most likely means that releases for different mobile OS's will occur at different times and that dictates that the cloud systems these applications consume must be versioned on a different schedule than the client applications.

Keep it Simple

Most mobile apps have a very small footprint if you examine the actual bits loaded onto the machine, but that does not necessarily equate to a small computing footprint. All data processing should be accomplished somewhere in the cloud for mobile applications.

So just what is it that we are asking all of our downloaded apps to do? All that a mobile app really needs to do is display information and accept small amounts of user input via clicking or tapping a screen area or entering data via some input device. Anything beyond that is a waste of mobile processing.

Consider a mobile BI ap-plication. Imagine you are a regional manager and you need to track all claims settled through your offices. You also require a visual representation (dashboard) of how your offices compare to each other and how your region compares to the others in the organization. The OLAP cubes that build the data for that information are in one of your data centers. The Web servers that consume those cubes and create the tables and charts to represent that data are also in a data center and are exposed to the Internet. The pages that your mobile application needs to consume are built on those Web servers. All you need on your mobile device is a Web browser and a URL. The only conceivable reason I can imagine for requiring a compiled code download for this BI application is if there is a need for enhanced security which the application must provide (public key encryption or something like that).

HTML(5), CSS and JavaScript should be able to provide just about everything a mobile application requires. And a properly written Web application should be able to deliver that application to the mobile browsers across multiple devices and OS's. I would much rather have a single team work twice as long to perfect a multiple platform Web application than have multiple teams attempt to replicate the same "fat" application across multiple OS's and code bases. I challenge others to use the Cloud Reader as an example of a mobile app done right.

Clean Up Your OS

This is also a challenge to the owners of the mobile operating systems to get their house in order. The Cloud Reader only supports Chrome and Safari. Do you really think that is because there is a conspiracy against Microsoft? Or could it be Microsoft browsers don't always comply with W3C standards? The current state of Microsoft Mobile browsers is a shambles. If Microsoft wants to really compete in the mobile market they need to take a look at their mobile framework browsers and browser controls.

There do exist cross-platform application frameworks that could be used for cross-platform coding. The problem with application frameworks, though, is they layer another level of abstraction (and computing requirements) on top of the operating system. There is more to the Flash/iPad issue than personal animosity. Not only is Flash open to a number of security exploits it isn't particularly efficient in terms of computing resource allocations.

Flash had its day in the sun and that day is drawing to a close. Cross-platform development frameworks are not the answer either. Forcing various mobile operating systems to interact with a common runtime is terribly inefficient. It reminds me of the old VB runtime frameworks—you might as well run a virtual machine on the host OS. VM's are great for commodity-server hardware; not so great for mobile.

Zzzzz

Mobile applications should consume common frameworks, but those frameworks should be universal common frameworks—things like HTML5, CSS, JavaScript, and Web Services. That is the model we should be looking at going forward.

Let's stay away from OS wars or browser wars for mobile computing. Let's do all the heavy lifting in the cloud and allow mobile devices to concentrate on the things that can't really be accomplished in the cloud. For now, the problem with mobile devices that keeps me awake at night is lack of security. If you really feel the need to write native code for mobile, do it to make the device, and by extension all its applications, more secure. Then maybe I can get a good night's sleep.  TD

Please address comments, complaints, and suggestions to the author at [email protected].