So in the middle of what was essentially a bad week the newKindle Cloud Reader was released. On its surface that might notseem like a big deal but the implications of this little Webapplication are huge. It is groundbreaking on a number of frontsand just may be pointing the way to the future of mobilecomputing.

Just aim a supported browser (Google's Chrome and Apple'sSafari) at the URL—https://read.amazon.com/ and allow your browserto install a small footprint plug-in. Abracadabra—you have fullaccess to all your Kindle eBooks. The Cloud Reader provides theability to create bookmarks and synchronize your purchases withyour other devices (I already have six devices I use to access myKindle library). It also provides a quick link to the Kindle storeso you can purchase new Kindle books in the application itself.

Books purchased on the Cloud Reader synch and download to yourother devices. Bottom line: I am able to read my library on(almost) any device connected to the Internet. I don't even need tohave admin rights on the client machine (no need to install aKindle application). Oh yeah, did I mention that the Cloud Readereven works without an Internet connection (after you havedownloaded some of your purchased content).

eBook Neutrality

Just so you know, I am not a shill for Amazon. More people in myfamily use Nooks than Kindle devices—in fact, I'm the only Kindleperson. The really cool thing about the Cloud Reader is that usingHTML5, JavaScript and a Web browser, Amazon has replaced a host offat-client applications. Not only that but it has managed to dancearound the Apple restriction that all applications must passthrough the app store.

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

This is True

As we muddle our way through the second decade of the 21stcentury there are two absolute certainties in informationtechnology: The cloud and mobile devices are here to stay and areforces to be reckoned with and embraced. Make no mistake, the cloudis not dead. We are all suffering from an excess of cloud hype inthe media and from advertising and marketing nonsense. But if weunderstand the cloud to be a model for ubiquity, always availableon demand computing resources accessed via a network, then thecloud has been here for at least a decade (SalesForce.com) and willcontinue to be around for the foreseeable future. It doesn't matterif we are talking private cloud or public cloud, secured cloud oropen access cloud; the cloud has fulfilled the idea of the networkas the computer.

Mobile devices are harder to escape than flieson road kill. I live in a small rural town. The place where I getmy hair cut is a cross between Floyd's barbershop on the AndyGriffith Show and Truvy's Beauty Parlor from SteelMagnolias. The patrons are straightforward, hard-workingpeople. Yet on a recent visit everyone hanging out there was doingsomething with some sort of smartphone or other mobile device. Andapplications for mobile devices are becoming ever moresophisticated. Using your smartphone instead of a printed boardingpass is now old hat. I was looking at a mobile app for a majorretailer. It provides the ability to scan a stock-keeping unit atthe 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 itleads the way to the path we should be following to creatingdevice-independent applications for mobile computing. Even if wedon't now support mobile applications we will in the future.Laptops and notebooks are nothing more than expensive portabledesktop systems. The laptop paradigm is the desktop paradigm. Themachine is essentially a container with a substantial data store onwhich we can run fat-client applications. Connectivity to thenetwork is only required when we need to share some information orwhen we need to connect with a back-office system.

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

I am currently sitting at a desk banging this out on areasonably high-end laptop. Using a laptop as a typewriter withauto-erase and spell check is a complete waste of computingresources, but that's the way we do things. Silicon and plastic arecheap (even though they are not eco-friendly) and electricity onlyseems expensive when you pay the bill for air conditioning in aGeorgia August.

I could be using a portable device with a lightweight computingfootprint but I'm not. And that is because we are still tied to theQWERTY keyboard paradigm. The virtual keyboards provided with mostportable devices are only useful for brief email messages andoccasional note taking. But that isn't important because theprimary use of mobile devices is to consume information, not createit. That's not to say that mobile devices can't be used efficientlyto capture form information or runtime information for engineeringdevices, it's just that the mobile device paradigm is better suitedto consuming information that is provided elsewhere (like thecloud).

So Many OS's…So LittleTime

Given that mobile devices inhabit a different niche in computingdoes it make any sense to create the same sort of applications formobile devices that we use for desktop computing? No, but that isexactly what we have been doing. Virtually all mobile applicationsare written using native code—code that is compiled to run on aparticular operating system—whether that be iOS (Apple's MobileOperating System), Android (Google's mobile OS), Windows Mobile orsomething else. That means that if I am going to distribute mobileapplications for my customers to use I need to maintain multiplecode bases and probably multiple development teams. It most likelymeans that releases for different mobile OS's will occur atdifferent times and that dictates that the cloud systems theseapplications consume must be versioned on a different schedule thanthe client applications.

Keep it Simple

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

So just what is it that we are asking all of our downloaded appsto do? All that a mobile app really needs to do is displayinformation and accept small amounts of user input via clicking ortapping 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 regionalmanager and you need to track all claims settled through youroffices. You also require a visual representation (dashboard) ofhow your offices compare to each other and how your region comparesto the others in the organization. The OLAP cubes that build thedata for that information are in one of your data centers. The Webservers that consume those cubes and create the tables and chartsto represent that data are also in a data center and are exposed tothe Internet. The pages that your mobile application needs toconsume are built on those Web servers. All you need on your mobiledevice is a Web browser and a URL. The only conceivable reason Ican imagine for requiring a compiled code download for this BIapplication is if there is a need for enhanced security which theapplication must provide (public key encryption or something likethat).

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

Clean Up Your OS

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

There do exist cross-platform application frameworks that couldbe used for cross-platform coding. The problem with applicationframeworks, though, is they layer another level of abstraction (andcomputing requirements) on top of the operating system. There ismore to the Flash/iPad issue than personal animosity. Not only isFlash open to a number of security exploits it isn't particularlyefficient 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 commonruntime is terribly inefficient. It reminds me of the old VBruntime frameworks—you might as well run a virtual machine on thehost OS. VM's are great for commodity-server hardware; not so greatfor mobile.

Zzzzz

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

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

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