Open Source Framework Fills Gaps for Mobile HTML Development

Posted on: November 25th, 2012 - Written by: Stephen Marshall

References: Kevin Whinnery, Appcelerator Network

PhoneGap is a free and open source framework that allows developers to create mobile apps using standardized web APIs for specific platforms.

Originally produced by Nitobi and later purchased by Adobe Systems, PhoneGap enables software programmers to build applications for mobile devices using JavaScript, HTML5 and CSS3, instead of device specific languages such as Objective-C. The resulting applications are hybrid – meaning that they are neither truly native nor purely web-based.

With truly native apps, all layout rendering is done via web views instead of the platform’s native UI framework. Web-based are not just web apps but are packaged as apps for distribution and have access to native device APIs.

The Goal for PhoneGap
PhoneGap’s reason for being is to allow HTML-based web applications to be deployed and installed as native mobile applications.
PhoneGap web applications are wrapped in a native application shell, and can be installed via the native app stores for multiple platforms. PhoneGap also tries to provide a common native API set which is typically unavailable to web applications, such as basic camera access, device contacts, and sensors not already exposed in the browser.

As a visionary leader, PhoneGap might be considered the vanguard of emerging W3C Device API standards, as they attempt to bring the future of HTML deployment to web developers in the present. Today, no platform makes web applications first class citizens. There are strives being made – as in Mozilla’s Boot To Gecko platform and Microsoft Windows 8 in regards to first-class API access to web applications. With PhoneGap, developers can seize a subset of these rights for web applications today.


End User Workflow, Tooling and Interface for PhoneGap
To develop PhoneGap applications, developers create HTML, CSS, and JavaScript files in a local directory, much like developing a static website. In fact, some PhoneGap developers cite as a bonus of the tool that they can develop in a desktop web browser most of the time, without needing the native toolchain at all.
To run a PhoneGap application on a native emulator/simulator, developers generate a project for each of the native platforms they wish to support, configure that project’s “web root” directory in Xcode, Eclipse, or whatever native toolchain is needed, and then run the project using that tool. The precise steps are outlined in their getting started guides, per platform. Often, symbolic links are used to route the “www” folder across multiple native projects to a common directory location.

Installing a native-wrapped PhoneGap application to a device requires a similar workflow. However, to augment that process and alleviate the need to have native SDKs installed locally, developers use PhoneGap Build, which generates installable applications in the cloud. Functionality to support PhoneGap build deployment is now integrated into Adobe’s Dreamweaver tool.

The tools used with PhoneGap are the standard tools of web development, such as Firebug, Web Inspector, and whatever text editor is preferred. There is also an emerging tool for remote debugging known as Weinre that is becoming more commonly used. The fact that developers are creating a native application at all is mostly abstract during the development process.

How PhoneGap Works
PhoneGap application is a “native-wrapped” web application. So exactly how is the web application “wrapped”?

Many native mobile development SDKs provide a web browser widget (a “web view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls, and displays the resulting HTML as the UI when the application is launched.

If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to asynchronously communicate with JavaScript code running inside of the web view in a way that correlates to the platform used. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture.

PhoneGap takes advantage of the bridge to create a JavaScript API inside a web view which is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is different for each platform, but on iOS – when you call for a list of contacts – your native method invocation goes into a queue of requests to be sent over the bridge.

PhoneGap will then create an iframe which loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by evaluating a string of JavaScript in the context of the web view from native code.

There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.

Extending PhoneGap
Writing native extensions for PhoneGap requires that you do three things:
1.     Write a JavaScript interface for your extension which will use PhoneGap’s API to queue up messages to be sent to native code.
2.     Register your extension with the native project in some way – on iOS this is done in the Cordova.plist file.
3.     Write native code that PhoneGap will route requests to from the web view, and implement any native code needed
Basically, developers can participate in the same asynchronous messaging system which powers the core PhoneGap native APIs.

Strengths of the PhoneGap Approach – Small & Simple
PhoneGap’s primary architectural strength is its simplicity. It does what it does, and it does that well. The PhoneGap team has intentionally implemented only the lowest common denominator of native APIs for the web browser-based app. Because the native API set is so small, it has been relatively easy to port PhoneGap to many different environments. Basically any native platform that supports a web view or web runtime can be a PhoneGap platform.
Non-visual native extensions in PhoneGap are also very simple. The requirements for registering native code to receive messages from the web view are very modest. Simple native extensions can be developed rapidly. This plug-in architecture was also well executed in my opinion.

There is another strength in the fact that native APIs and native app development are almost completely abstract to the end developer. Anyone who can write HTML, CSS, and even a small bit of JavaScript can wrap up a web page in a native app and distribute it as such. The barrier to entry in using PhoneGap to package web pages as native apps is extremely low.

Weaknesses of the PhoneGap Approach
The quality of the user interface in a PhoneGap application varies based on the quality of the web view and rendering engine on the platform. The Webkit-based rendering engine on iOS is strong, and provides the best performance. The Android web view is functional, but has some notable limitations. On other platforms, the web view performance can be suspect depending on the OS version.

There are also the standard cross-browser issues web developers have had to deal with – even before PhoneGap. UIs need to employ progressive enhancement, media queries, and that entire bag of tricks to remain usable on multiple platforms. It helps that many mobile platforms are adopting Webkit, but there are still significant differences even in Webkit based environments. Constant improvements in mobile browsers help mitigate these problems but approaching native-quality UI performance in the browser is not a trivial task. Even so, on most platforms, in most browsers today, reaching native-quality UI performance and responsiveness is simply not possible, even with a advanced frameworks. Whether the browser already “good enough” depends on your requirements and sensibilities, but it is unquestionably not as good as native UI and is actually much worse – depending on the browser being used.

PhoneGap also cannot be extended with native user interface. The end developer’s application its self lives inside a web view, and user interface is rendered in HTML. One can message to native code and create native UI that goes on, over, above, or adjacent to the web view, but it’s difficult or impossible to integrate a dynamic, HTML DOM-based UI with native UI components. Appcelerator would know – we tried to associate native UI with DOM elements early on, and needed to scrap that effort as the results were unpredictable and of insufficient quality.

Also with the lowest common denominator, very few native APIs are exposed to PhoneGap applications by default, which makes platform integration limited. There are a variety of plug-ins that exist to fill some of these gaps, but they vary in quality and maintenance. These variances could very well continue to improve over time because of the strong community around PhoneGap.

Tags: , , , , ,

Leave a Reply