Mobile protocols just might be the missing link for a successful way to deploy Windows applications to mobile...
People embark upon desktop virtualization projects to achieve many goals and, like it or not, one of the most common goals is to deliver Windows apps to mobile devices. It's probably something you already have in place; there are clients for just about everything, so it's a quick and easy solution.
There are challenges to desktop virtualization on mobile devices that some people put up with so they can exist in an untethered, mobile world, but most of us decide after a short time that pinch-zooming and virtual keyboards aren't worth the effort. You can solve that with Bluetooth keyboards and the like, but, let's face it, the biggest benefit of running Windows apps on an iPad is that it's justification for IT people to get the company to buy them iPads.
Nonetheless, running Windows apps on mobile devices is a big deal. At BriForum 2013, I caught up with Framehawk Inc. to learn how the company deals with the challenge.
Solving the remote protocol problem
Until recently, I thought Framehawk was an app refactoring solution -- one that reformats Windows applications for mobile devices on the fly. There are some tools out there that do this, most notably the Citrix Mobile SDK. With app refactoring, a Windows app goes into the tool, and a mobile app comes out.
Framehawk, on the other hand, isn't all that dissimilar from other remote desktop or remote application products, at least from an end-user perspective. You provision applications and desktops to your users, and they're accessed in a similar way to what they are used to.
The biggest difference with Framehawk is that it has created a graphics remoting protocol from the ground up -- just for the purpose of delivering desktops and applications via mobile networks. This mobile protocol, called Lightweight Framebuffer Protocol (LFP) was developed by a team led by a former NASA physicist used to dealing with high-latency, low-reliability connections to spacecraft.
I viewed a demo of Visio running over a 4G connection on an iPad. I use Visio regularly (probably my most-used Windows application), and I've found it to be a less-than-desirable experience using traditional protocols, especially on mobile devices.
Part of the problem with Visio is that to create good-looking documents, you need to have precise object placement. This is challenging to do with a fingertip, even if you are pinch-zoomed in all the way. Just about every remote desktop client for the iPad has a solution for more precise aiming of the mouse pointer, and Framehawk is no exception.
The other downside of Visio is that, since there are so many objects on a screen at any given time, the graphical performance can suffer, especially when moving objects around. Both of these aspects performed quite well in the demo I saw.
How Framehawk works
What differentiates Framehawk from other desktop virtualization platforms on the back end is that it operates alongside your existing software. The key to the software is called a Secure App Client Container, which establishes connections to applications before re-encoding them into the LFP protocol. That means you can continue to use your existing platform for desktops and laptops via the native protocol.
In a way, this is similar to Oracle Sun Ray or Secure Global Desktop -- apps come in one way and go out another. The Secure App Client Container can be used with Linux, VDI or Remote Desktop Services.
More on desktop virtualization and mobility
Q&A: The issue of full desktop access
How to print from desktops on mobile devices
More desktop virtualization companies focus on mobile
Delivering desktops on Apple iPads
You can deploy Framehawk two ways. It offers a cloud service that connects to applications before remoting them in addition to an on-premises offering that you can manage yourself. This choice is not as complicated as choosing between hosting your desktops with a DaaS provider or in-house. With Framehawk, the applications and data still live within your data center walls. Only the remoted application is sent to Framehawk's cloud via whatever native protocol you use. From there it's re-encoded to LFP and sent to your users.
Granted, Framehawk can't do anything to eliminate the need for a keyboard to make mobile Windows applications useable on a tablet (that is, after all, an unsolvable problem) or the need to pinch-zoom on occasion. Still, it's hard to ignore the benefits of delivering applications via a protocol tailor-made for mobile connections from a platform that exists alongside your existing one.