Hybrid Applications: A Marriage of Mobile Application Architectures

Most people think of two types of mobile applications: the mobile web and native applications.  The mobile web is obviously web sites that are optimized for mobile devices, like feature phones, smartphones, and now media tablets.  Their strength is that many developers are fluent in web-based development languages and tools.  Their weakness is you don’t have access to most hardware features (camera, accelerometer, sensors, etc.).  Native applications are developed for a specific OS platform using the associated software development kit (SDK).  Their strength is that you can leverage those hardware features previously mentioned.  Their downside is that you have to write different code for each mobile OS (like Objective-C for iOS devices and Java for Android).

Another application type which is growing in popularity is known as a hybrid mobile application.  The idea is that you can leverage common web technologies (HTML, CSS, and JavaScript) but get the experience of a native application.  This is accomplished is by leveraging a framework which is designed to access the native APIs of the mobile OS while offering APIs to developers using web-based technologies (such as JavaScript).  The application behaves just like a native app which can be placed in an app store and downloaded and installed on the mobile device.  Some popular frameworks include PhoneGap and Appcelerator Titanium, although there are a number of others.

Another version of hybrid apps uses a slightly different model that I think of as the ‘container’ model.  In this environment, there are two separate components: the client and the application.

• The client is an native application installed on the device that has access to the OS-specific APIs.  Each OS platform has its own client.  However, each client exposes a common set of APIs across the different platforms.  These APIs are usually proprietary.
• The application is usually an XML-based program that communicates through the proprietary APIs provided by the client.  The same application can then be streamed to different OS platforms without modification as long as the client is installed.

The client acts as a container for the applications.  As an example, for the application to take a picture, the developer writes the app to call the proprietary API for the camera.  In turn, each client will take that API request and convert it to the native OS API for the camera.  This model also has the potential for updates without going through a mobile application store, since the XML can be streamed similar to a web page.  Some examples of tools that user a container model for all or part of their solution include Antenna Software, Pyxis Mobile, and Sybase Unwired Platform.

It should be noted that W3C, an international standards organization for the web, has a Device APIs and Policy Working Group whose mission is to create client-side APIs that enable web apps to access device features such as calendar, contacts, and camera in a common and secure fashion.  Their goal is to have the recommendations completed by 2nd quarter of 2011.  Even if completed on schedule, it will take some time for OEMs to integrate this into their platforms (if they choose to).

As you can see, hybrid apps can be implemented in different ways.  Since there is no standard definition, there are different perspectives on what constitutes a hybrid app.  The key is that mobile hybrid apps marry (pun intended) the common web-based development environments with the power of native applications.  This winning combination will cause many enterprises to say ‘I Do’ to hybrid mobile applications.

Explore posts in the same categories: Hybrid Mobile Applications, Mobile Applications, mobile thick client, mobile thin client

Tags: hybrid, mobile applications, mobile thick client, mobile thin client, smartphone

Both comments and pings are currently closed.