The phenomenal growth of the tablet market has left many industry analysts scrambling to reassess sales forecasts for both tablets and PCs. Last week Gartner was forced to acknowledge that its previous forecasts were way off the mark when it issued a revised 2011 sales forecast that reduced its November 2011 PC sales growth estimate by a staggering 25%. Gartner research director, Ranjit Atwal, said his company had not fully appreciated the impact that tablet devices were having on the market, and the new figures “reflect marked reductions in expected near-term unit growth based on expectations of weaker consumer demand, due in no small part to growing user interest in media tablets such as the iPad.” Given that this is the same Gartner that in September 2010 instructed CIOs everywhere to go out and buy iPads, it shows just how badly it underestimated the tablet’s impact on the PC market. As tablet sales (and for the moment we can read that as being almost exclusively iPad sales) continue to cut in to sales of PCs and laptops, PC manufacturers are under pressure to offer their own alternatives and IT organizations are under similar pressure to provide ways to integrate tablets into their core service offerings.For many IT organizations, this means no more than offering support for browser access to web apps and installing a client such as the Citrix Receiver to provide access to server hosted virtual desktop and Remote Desktop Services (Terminal Services) environments. Others are looking more closely at the use of tablets and formally adopting them as a mainstream platform for some job roles (chiefly those where mobility is paramount and data entry is limited). Under these circumstances, the assessment of a tablet’s functional characteristics must go a long way beyond ticking the box that next to the question that asks “Is it an iPad?”. I have taken a number of calls recently from clients looking to understand more about the kind of questions they should be asking of tablet vendors when attempting to select an enterprise standard for tablet devices. Many of the most important requirements explore not the tablet itself but the application delivery systems that it supports, but there are areas that do require close attention especially when the tablet is to be used in conjunction with enterprise web apps as well as virtual desktops and applications hosted in a Remote Desktop Services (Terminal Services) environment.
Hardware characteristics such as screen size, resolution and responsiveness, as well as battery life, processor performance and the presence or otherwise of a keyboard are universally relevant and well understood. Similarly compatibility Internet Explorer 6, and the ability to display Flash or Silverlight based web content can be very important in enterprise environments but do not require any in depth understanding to develop or assess a tablet operating systems ability to support them. There are however, significant differences in the way that different operating systems implement support for multi-tasking that impact the suitability of one device over another when it comes to using it as remote desktop endpoint that does require further explanation. To explain these differences, lets consider how Apple’s iOS has evolved since its introduction with the launch of the iPhone.
When Apple first delivered the iPhone the iOS operating system offered no support for multitasking beyond allowing some of its own applications to run in the background, letting you listen to music or answer a phone call while another application ran in the foreground. Instead, Apple gave the appearance of multitasking through a process known as ‘tombstoning’; that is, copying application state to memory before shutting the app down and launching the new application. Then later when the original application is restarted it can restore whatever settings it needs to pick up where the user left off. As a means of delivering pseudo-multitasking there’s nothing wrong with tombstoning, it gives every appearance of multitasking, but without the complexity of creating a true multi-tasking OS. Provided the application is small enough to load quickly enough to make for painless switching between apps and provided the developer does a good job of identifying all the necessary application parameters needed to recover the previous session state, it works well enough for most circumstances. Clearly tombstoning has no ability to support background processing, applications can only do work in the foreground, because there is no real background for them to work in. Still given the nature of most of the applications designed for iPhone and iPad this was not a major concern, and by only supporting foreground processing battery life was not unwittingly sacrificed. Having said that, Apple did build in some level of support for multitasking right from the start. It has always been possible to listen to iTunes, or make a phone all at the same time as looking something up in the address book or browsing the Internet, but Apple restricted this capability to its own applications; third-party applications were always tombstoned.
Apple delivered a significant enhancement to iOS in iOS 4.0, so that now when you switch between apps in iOS 4 it no longer tombstones the first application. Instead, the first application is suspended, sitting inert in memory in the background. So when you re-launch an app, it opens almost instantly to pick up from where it left off before you “closed” it. This behavior enables rapid switching between apps, and creates a seamless experience even with applications that didn’t quite get tombstoning right. iOS 4 also extended multitasking support so that all applications could now perform some limited background processing. To be clear, this isn’t full multitasking as it doesn’t allow applications to run unrestricted in the background, but what it does do is allow an application to leave a single thread open and running in the background, not enough to keep an Angry Bird in flight (try it yourself); but enough to keep a VoIP application running once a connection is made.
The one thing that iOS doesn’t yet achieve is full multitasking so that all applications can continue working in the background. Apple argues both that this is of no value in a smartphone or tablet, and at the same time claims that to do so would be detrimental as it would shorten the battery life if an application had the ability to run unrestricted in the background. Internal inconsistencies aside (the forthcoming Mac OS X 10.7 Lion makes a Mac Book Air deliver an experience very close to that of a iPad with built-in keyboard), this argument does make some sense, battery life is of paramount importance in a mobile device.
With that introduction, how far up the ladder from tombstoning, to full multitasking does a mobile operating system need to be to make it a suitable platform for use as a remote desktop endpoint? The essential requirement of any remote display protocol is that a connection be maintained between the source and the endpoint. Once the connection drops, the user experience degrades rapidly. Aside from the obvious – no connection means no work; if a connection drops, depending on environment policy settings, the session could be terminated and work lost, or at best the endpoint must establish a new connection to the source, before the user can restart work.
From that perspective, tombstoning has obvious flaws. Terminating the remote client application inevitably disconnects the endpoint from the source, thus requiring a full reconnection/the authentication sequence before the endpoint can attempt to connect to the remote session, assuming it is still available. Hardly a satisfactory experience if all that was required was a 15 second interruption to look up a phone number in the address book. Suspending an application in memory provides an improvement over tombstoning for brief interruptions. If the remote client application is brought back into the foreground before any session disconnect watchdog timer expires, it should continue to operate uninterrupted. However, this is far from being an ideal situation. Looking next at the background processing capability Apple introduced with iOS 4, this now provides a significantly improved experience. The background processing capability should allow an application to respond to watchdog packets it receives from the remote desktop, maintaining the connection for as long as policy allows. Much still depends on the developer’s ability to provide support for background processing and further controls precisely what can be achieved here. While basic connectivity may be maintained without problem, this does not automatically mean that more advanced features such as printing support will continue to function unless the application is returned to foreground operation. That level of functionality is only assured where the mobile OS supports comprehensive multitasking.
Translating this into the context of today’s mobile operating systems; Windows Phone 7 today only offers support for tombstoning. iOS as indicated above supports both fast memory switching and some limited background processing; whereas Android, webOS, and QNX all support full multitasking. The bottom line needs to be interpreted therefore as follows, if support for connectivity to remote desktops and/or applications hosted in a Remote Desktop Services environment is critical, Windows Phone 7 is not today a viable mobile platform. Any off the other four platforms can deliver a satisfactory experience (provided of course that an appropriate remote client application is available), but of these Android, webOS, and QNX are likely to be the preferred choice, assuming no other overriding requirements exist.