1. Introduction to PhoneGap

PhoneGap is an open source framework for building cross-platform native applications using standard web technologies such as HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript. This type of mobile application is called a hybrid application. A group of developers created PhoneGap as a way to simplify mobile development, and adoption of the framework has grown significantly over time.

As described on the PhoneGap web site (www.phonegap.com), “PhoneGap is an open source implementation of open standards.” The project’s development teams work to implement relevant web development standards (from the World Wide Web Consortium [W3C] and others) into the PhoneGap framework. There are a robust suite of application programming interfaces (APIs) included in the framework today, and there’s a solid road map for implementing additional capabilities over time. There’s much more detail about what PhoneGap is and what makes a PhoneGap application in this and the following chapter.

PhoneGap currently supports the following mobile device operating system platforms:

• Apple iOS (both iPhone and iPad): http://developer.apple.com

• Google Android: http://developer.android.com

• HP/Palm webOS: http://developer.palm.com

• Microsoft Windows Phone 7: http://create.msdn.com/en-us/home/getting_started

• Nokia Symbian: www.developer.nokia.com/Devices/Symbian

• RIM BlackBerry (devices running BlackBerry Device Software 4.6 and newer): www.blackberry.com/developers

• Samsung bada: http://developer.bada.com

The PhoneGap project has plans for adding other platforms as they become popular in the market (and popular with mobile developers). With Hewlett-Packard’s announcement of its discontinued support for webOS, development for that platform, although supported by PhoneGap, will not be covered in this book. With Nokia’s announcement that it is adopting Windows Phone over its own Symbian OS, it’s possible that PhoneGap will drop support for Symbian in the future, but the Symbian OS is still covered in this book.

The framework is available under an open source license; as a user of PhoneGap, you can choose to use either the modified BSD license or the MIT license. The software is free to use, and the PhoneGap team will not accept any external contributions that are incompatible with either license (either through inclusion of proprietary code or license under a more restrictive license). As the project finishes the process of migrating to the Apache Software Foundation community, the license will change to an Apache license. To contribute code to the project, you will need to sign a contributor agreement.

A Little PhoneGap History

PhoneGap was started at the 2008 iPhoneDevCamp by Nitobi (www.nitobi.com), which started the project as a way to simplify cross-platform mobile development. The project began with a team of developers working through a weekend to create the skeleton of the framework; the core functionality plus the native application container needed to render web application content on the iPhone. After the initial build of the framework, the PhoneGap project team quickly added support for Android, with BlackBerry following a short time thereafter.

In 2009, PhoneGap won the People’s Choice award at the Web 2.0 Expo LaunchPad competition. Of course, being a project for geeks, the conference attendees voted for the winner by Short Message Service (SMS) from their mobile phones.

Over time, PhoneGap has added support for additional hardware platforms and worked to ensure parity of API features across platforms. The project team continues to add support for new devices and APIs over time and has a very robust road map for future versions of the framework.

IBM has recently become more involved in the project. You can now find IBM’s copyright alongside Nitobi’s in the source code for new PhoneGap projects. When IBM got involved in the Eclipse project (an open source integrated development environment [IDE]; www.eclipse.org), Eclipse quickly became integral to IBM’s product strategy and became the core of several IBM projects. It’s likely that IBM’s involvement in the PhoneGap project indicates where IBM could be taking its mobile development or mobile product strategy.

After this section of the chapter had been written, PhoneGap applied to become part of the open source Apache project (www.apache.org), first as Apache Callback and later (beginning with version 1.4) as Apache Cordova (the name of the street where the Nitobi offices are located). At the same time, Nitobi announced that it had been acquired by Adobe (www.adobe.com).

Right before the book went to press, the PhoneGap project team changed the name of the PhoneGap JavaScript file (phonegap.js) to cordova.js. Throughout all of this, the commercial name for PhoneGap should remain PhoneGap, so all references in the book will refer to its commercial name, not the Apache project name. Sample project source code included herein will be updated with the correct file name and posted to the book’s web site at www.phonegapessentials.com.

The move to the Apache Software Foundation helps to reassure companies wishing to use PhoneGap that the framework will remain a stable, available tool to use. The acquisition of Nitobi by Adobe (and Adobe’s subsequent announcement that they’re discontinuing support for Adobe Flash on mobile devices) clearly indicates that Adobe sees PhoneGap as an important part of their product portfolio. The folks at Nitobi who were working on PhoneGap in their spare time as a labor of love should now find themselves in a position where they can work full-time on the project. Expect regular and frequent updates to the framework.

Why Use PhoneGap?

You would use PhoneGap to build mobile application for several reasons:

• Your mobile application was already built using web technologies, and you want to be able to deploy the application through one or more mobile application stores (such as the Android Market, the Apple App Store, or BlackBerry App World).

• You want to build a mobile application leveraging your web development skills but need to leverage device-side features (such as the camera or the calendar), which are not supported by the mobile browser.

• You want to build a quick prototype of a mobile application and don’t have time to learn Java or Objective-C.

• You think PhoneGap is cool.

A lot of commercial applications are available today that were built using PhoneGap; you can find a list of many of the applications on the PhoneGap web site at www.phonegap.com/apps. The framework is used primarily for consumer applications (games, social media applications, utilities, productivity applications, and more) today, but more and more enterprises are looking at PhoneGap for their employee-facing applications as well.

How PhoneGap Works

As mentioned previously, PhoneGap allows a developer to build native applications for mobile devices (both smartphones and tablets) using web technologies such as HTML, CSS, and JavaScript. A developer builds a web application for the mobile device, and special tools provided by PhoneGap package the web application into a native application for each supported mobile platform. Figure 1-1 illustrates the packaging process, which will be described in greater detail later in the chapter.

Figure 1-1 PhoneGap application architecture

Within the native application, the application’s user interface consists of essentially a single screen that contains nothing but a single web view that consumes all of the available space on the device’s screen. When the application launches, it loads the web application’s startup page (typically index.html but easily changed by the developer to something else) into the web view and then passes control to the web view to allow the user to interact with the web application. As the user interacts with the application’s content (the web application), links or JavaScript code within the application can load other content from within the resource files packaged with this application or can reach out to the network and pull content down from a web or application server.

For some mobile device platforms such as bada, Symbian, and webOS, a native application is a web application; there’s no concept of a compiled native application that is deployed to devices. Instead, a specially packaged web application is what is executed as an application on the device. You’ll learn more about this in subsequent chapters.

The web application running within the container is just like any other web application that would run within a mobile web browser. It can open other HTML pages (either locally or from a web server sitting somewhere on the network); JavaScript embedded within the application’s source files implements needed application logic, hiding or unhiding content as needed within a page, playing media files, opening new pages, performing calculations, and retrieving content from or sending content to a server. The application’s look and feel is determined by any font settings, lines, spacing, coloring, or shading attributes added directly to HTML elements or implemented through CSS. Graphical elements applied to pages can also help provide a theme for the application. Anything a developer can do in a web application hosted on a server can be done within a PhoneGap application.

A typical mobile web browser does not have access to device-side components such as any of the other applications running on the device (such as the Contacts application) plus device-specific hardware (accelerometer, camera, compass, microphone, and more). The typical native mobile application, on the other hand, may make frequent use of those components. To be able to build an interesting mobile application (interesting to prospective application users anyway), a mobile application may need access to those native device components outside of the typical web container. PhoneGap accommodates this need by providing a suite of JavaScript APIs that a developer can use to allow a web application running within the PhoneGap application container to access device components that are outside of the web context. Figure 1-2 illustrates how this works at a high level.

Figure 1-2 PhoneGap application: device interaction

When a developer implements a feature in an application that uses one of the PhoneGap APIs, the application calls the API using JavaScript, and then a special layer within the application translates the PhoneGap API call into the appropriate native API for the particular feature. As an example, the way the camera is accessed on a BlackBerry is different from how it’s done on Android, so this API common layer allows a developer to implement a single interface that is translated behind the scenes (within the container application) into the appropriate native API for each supported mobile platform. To take a picture in a mobile application using PhoneGap, the JavaScript code would look like this:

Click here to view code image

navigator.camera.getPicture( onSuccess, onFail );

As parameters, the application passes in the names of two callback functions: onSuccess and onFail (callback functions will be described in detail in subsequent chapters).

On BlackBerry, the code being executed behind the scenes might look like this:

Click here to view code image

Player player = Manager.createPlayer("capture://video");
player.realize(); 
player.start(); 
VideoControl vc = (VideoControl) player.getControl( 
  "VideoControl");   
viewFinder = (Field)vc.initDisplayMode( 
  VideoControl.USE_GUI_PRIMITIVE,   
  "net.rim.device.api.ui.Field");   
scrnMain.add(viewFinder); 
vc.setDisplayFullScreen(true); 
String imageType = 
  "encoding=jpeg&width=1024&height=768&quality=fine";   
byte[] theImageBytes = vc.getSnapshot(imageType);
Bitmap image = Bitmap.createBitmapFromBytes( 
  imageBytes, 0, imageBytes.length, 5);   
BitmapField bitmapField = new BitmapField(); 
bitmapField.setBitmap(image); 
scrnMain.add(bitmapField); 

On Android, the code being executed by the function might look like this:

Click here to view code image

camera.takePicture( shutterCallback, rawCallback, 
  jpegCallback );   

And on iOS, the code might look like this:

Click here to view code image

UIImagePickerController *imgPckr = 
  [[UIImagePickerController alloc] init];   
imgPckr.sourceType = UIImagePickerControllerSourceTypeCamera; 
imgPckr.delegate = self; 
imgPckr.allowsImageEditing = NO; 
[self presentModalViewController:imgPckr animated:YES]; 

The code samples listed here don’t cover all aspects of the process of taking a picture (such as dealing with errors or processing the resulting image), but the examples illustrate how PhoneGap simplifies cross-platform mobile development. A developer makes a single call to a common API available across all supported mobile platforms, and PhoneGap translates the call into something appropriate for each target platform. This eliminates the need for the developer to have intimate knowledge of the underlying technologies, instead allowing them to focus on their application rather than how to accomplish something on multiple devices.

PhoneGap currently supports the following APIs:

• Accelerometer

• Camera

• Capture

• Compass

• Connection

• Contacts

• Device

• Events

• File

• Geolocation

• Media

• Notification

• Storage

Additional APIs are added as the PhoneGap project team gets to them and as new standards evolve. The PhoneGap project’s efforts around API implementation are partially guided by the W3C’s Device APIs and Policy (DAP) Working Group (www.w3.org/2009/dap/). This group is working to “create client-side APIs that enable the development of Web Applications and Web Widgets that interact with device services such as Calendar, Contacts, Camera, etc.” You’ll find that the PhoneGap project will implement the DAP APIs as they become standardized.

Over time, as mobile device browsers implement the DAP APIs in a consistent manner, PhoneGap will find itself obsolete. When mobile browsers all support these APIs, there won’t be a need for the capabilities PhoneGap provides, and essentially the project will just disappear.

Designing for the Container

PhoneGap applications are web applications running inside a client-side native application container. Because of this, web applications running within a PhoneGap application leverage an HTML 5 application structure rather than that of a traditional server-based web application. Let’s talk about the different options.

The Traditional Web Server (Web 1.0) Approach

With old-school, traditional web applications, a web server serves up either static HTML pages or dynamic pages to the requesting user agent (the browser). With dynamic pages, a server-side language or scripting language is used to retrieve dynamic content (from a database, for example) and format it all into HTML before sending it to the browser. When the browser makes a request, the server retrieves the containing page and content, massages it all into HTML (or some variant such as XHTML), and sends it to the browser to be displayed.

In this example, the browser doesn’t need any intelligence with regard to the content; it merely requests a page, and the server does most of the work to deliver the requested content. On the browser, the application can leverage client-side Java-Script code to allow the user to interact with the content on the page, but in general, most of the work is done by the server.

The Web 2.0 Approach

With the advent of Web 2.0, a reduced load is placed on the web server; instead, JavaScript code running within the browser is responsible for requesting and presenting data. The web server delivers an HTML-based wrapper for the web application, and JavaScript code delivered with the page dynamically manages the content areas of the page, moving data in and out of sections of the page as needed.

What allowed Web 2.0 applications to be successful was the addition of the XMLHTTPRequest (XHR) API in JavaScript. This API allowed a web application to submit asynchronous requests to a server and process the data whenever it returns from the server, without interrupting the user’s activity within the application. You’ll find that many PhoneGap applications make heavy use of XHR to interact with a remote server.

This approach allows for much more interesting web applications—applications that can easily look and feel like native desktop applications. The web server is still involved, serving up the pages and the content to the browser, but it does less direct manipulation of the data. Google Maps (http://maps.google.com) or Google Gmail (http://mail.google.com) are good examples of Web 2.0 applications available today.

The HTML 5 Approach

Mobile devices need a slightly different approach. Web 1.0 and 2.0 technologies work great on smartphones, but Web 1.0 apps caused a lot of data to be transmitted between server and device, and Web 2.0 apps were cooler but still required constant network connectivity to operate. Google even created a technology called Google Gears (http://gears.google.com), which included a client-side SQL database and other capabilities that web applications could use to allow an application to run, even if the web server was not available. They later stopped work on the project and instead shifted their efforts to helping craft the HTML 5 standard.

With HTML 5, web applications can make use of new capabilities that allow an application to operate more efficiently on a mobile device (or devices with limited connectivity). With HTML 5, web applications can make use of a client-side database to store application data. This makes it easier for mobile devices to operate as they go in and out of wireless coverage. Additionally, HTML 5 supports the addition of a manifest file that lists all of the files that comprise the web application. When the web application’s index file loads, the browser will read the manifest file and retrieve all of the files listed in the manifest and download them to the client device. If a mobile device were to lose network connectivity, if the files listed in the manifest were available on-device, then the application can continue working, using any data that may be stored locally.

To leverage these HTML 5 capabilities, though, a web application must be written so it is able to run completely within the browser container (or in the case of PhoneGap applications, within the PhoneGap application container). The index.html file is typically the only HTML file in the application, and the application’s different “screens” are actually just different <div> containers that are switched in and out as needed. HTML 5 applications will still reach out to a server for data as needed, using XHR to request data asynchronously and store it locally as needed.

Web developers must rethink their approach to web development to leverage these capabilities. Instead of having access to everything on the web server, the HTML 5 application running on a mobile device should try to be self-sufficient, making sure it has the files and data it needs to run whenever possible.

The web applications running within a PhoneGap application are HTML 5 applications.

Writing PhoneGap Applications

As mentioned previously, PhoneGap applications are built using normal, everyday web technologies such as HTML, CSS, and JavaScript. Whatever you want your application to do, if you can make it work using standard web technologies, you can make it work in a PhoneGap application. PhoneGap applications can do more than standard web applications, through the specialized JavaScript libraries provided with the framework.

To build PhoneGap applications, you’ll need to dig out your editor of choice and get coding. To keep things simple, you could use Notepad on Windows or TextEdit on a Macintosh. You could even use something more sophisticated such as Adobe Dreamweaver or Eclipse. Aptana Studio (www.aptana.com) is a good option for web developers; it’s an open source Eclipse-based IDE tailored for web development. The PhoneGap project doesn’t currently offer or support any special editor for coding your PhoneGap applications.

Building PhoneGap Applications

Once you have a completed web application, whether it uses any of the PhoneGap APIs or not, it has to be packaged into a native application that will run on-device. Each of the mobile device platforms supported by the PhoneGap project has its own proprietary tools for packaging or building native applications for its platform. To build a PhoneGap application for each supported mobile platform, the application’s web content (the HTML, CSS, JavaScript, and other files that comprise the application) must be added to an application project appropriate for each mobile platform and then be built using the platforms proprietary tools.

What’s challenging about this process is that each mobile platform uses completely different tools and the application projects for each use different configuration files and a different folder structure. To make it even worse, the PhoneGap JavaScript libraries are different for each mobile platform; the API calls are consistent across all platforms, but the internal JavaScript code used to interact with the native container differs depending on the platform (Android, BlackBerry, or iOS, for example).

As you can see, there is no direct way for developers to configure development system so they can create one project and use it to create PhoneGap applications for multiple platforms.

What happens is that a developer will create a project for one platform (Android, for example), write the appropriate web content, and then package and test the application using the tools Google provides for Android developers. Once the application is working correctly on Android, the web content is copied into a new Xcode project (for iOS applications) or a new BlackBerry WebWorks project, and the process repeats. Figure 1-3 illustrates the process; the figure doesn’t show all of the PhoneGap-supported platforms, but you should get the point.

Figure 1-3 PhoneGap application build process

If that weren’t bad enough, tools for creating new PhoneGap projects for each of the target platforms place the PhoneGap JavaScript libraries in a different location depending on the project type. For example, in a BlackBerry project, the PhoneGap JavaScript library is placed in the /JavaScript folder, where for iOS it’s placed at the root folder of the project. As an application’s web content is copied from one mobile platform’s project to another, the code may have to be adjusted since the JavaScript resource files may be in a different location on each.

Some platforms, such as webOS, require that their framework library (called mojo) be the first JavaScript library loaded in your web project. So, in this case, there’s special code that will be in only one flavor of your application: the version for webOS.

What this means is that for developers to be able to build mobile applications for multiple mobile platforms, they must install a complete development environment for each and manually copy and adjust the web source files between each project.

Part 2 of this book contains information on how to configure each of the supported development environments for PhoneGap.

You probably read the last few paragraphs and said to yourself that there must be a better way. Fortunately, there is. The PhoneGap project team has been hard at work building a cloud-based packaging service for PhoneGap applications called PhoneGap Build, shown in Figure 1-4. This service should dramatically decrease the complexity of maintaining a development environment for PhoneGap.

Figure 1-4 PhoneGap Build build process

With PhoneGap Build, a developer creates a configuration file called config.xml that describes settings for the mobile application. The format of the file is defined in the W3C widget specification (www.w3.org/TR/widgets). The configuration file and the application’s web content (the application’s HTML, CSS, and Java-Script files) are uploaded to the PhoneGap Build server and packaged into native mobile applications for each supported mobile device platform. A developer will interact with PhoneGap Build using a standard desktop web browser.

PhoneGap projects can be loaded into PhoneGap Build as a .zip file or pulled from a Git (http://git-scm.com) or svn (http://subversion.apache.org) repository. Developers can even store their PhoneGap projects in a Git repository hosted by the PhoneGap project. The PhoneGap build process is described in detail in Chapter 9.

PhoneGap Limitations

There are some limitations with using PhoneGap for your mobile application projects. As an open source project, its ability to deliver new features and bug fixes in a timely manner is controlled mostly by volunteers.

Even though the project has a robust road map, it can deliver on that road map only if it has enough resources, with relevant skills for each supported mobile platform, to do the work. What happens then is that features and bug fixes for more popular platforms (such as Android and iPhone) get more attention while less popular platforms languish. As an example, take a look at Figure 1-5, which shows the API documentation for the PhoneGap Device API. This API, described in more detail in Chapter 16, allows a PhoneGap application to access information about the device the application is running on. A developer would use this feature, for example, to enable or disable features or capabilities within an application based on the capabilities of the device.

Figure 1-5 PhoneGap API documentation example

As you can see from the figure, even though PhoneGap supports a wide range of mobile devices, this simple API to obtain the name of the device, device.name, is supported by only three platforms. As a developer working with PhoneGap, you’re going to have to constantly assess availability of a particular API against the target audience for your application and possibly adjust the features of your application accordingly.

That being said, I know that one of IBM’s goals is to help enforce a more consistent implementation of the supported APIs across all of the supported platforms. In this particular example, it’s a documentation omission; the device.name property is available on all PhoneGap-supported mobile platforms. Someone just needs to update the documentation to reflect the current supported devices for the API. The differences in implementation of a method or property of a particular API are listed in the PhoneGap documentation under a “Quirks” section of the document.

As with most open source software projects, a limited amount of documentation is available for many topics. Even though the API documentation is excellent and there are source code examples of most API functions (something that isn’t very common even for commercial software packages), a lot of things related to PhoneGap are just not documented or not documented in detail. When you go to the PhoneGap web site, you can very quickly get to the API documentation, but except for some quick-start guides for most of the supported mobile platforms, there’s very little information available about how to actually “use” PhoneGap or do cross-platform development using PhoneGap.

Fortunately for you, this book should fill in many of the gaps.

PhoneGap Plug-Ins

As with any developer tool, often there are times when the base functionality provided by the solution just isn’t enough for your particular needs. For those, cases, PhoneGap supports the ability to extend PhoneGap applications with additional functionality. You can find more information about plug-ins at http://wikiphonegap.com/w/page/36752779/PhoneGap%20Plugins.

The PhoneGap project has a very active developer community. When a developer sees a gap in a product, especially an open source project like PhoneGap, it doesn’t take long before someone builds an enhancement (whether it is a plug-in or some other mechanism) to “fix” the problem. Here are just a few examples of what’s available from the PhoneGap community:

• PhoneGap Facebook Platform Plug-in (www.phonegap.com/2011/08/30/get-the-new-phonegap-facebook-platform-plugin)

• PhoneGap Android development plug-in for Eclipse (www.mobiledevelopersolutions.com)

• PhoneGap iOS Plugin for Drupal (www.jefflinwood.com/2011/07/announcing-phonegap-ios-plugin-for-drupal-v0-1/)

Getting Support for PhoneGap

One of the things corporations worry about is getting support for the software products they use for their business applications. Open source products such as Open-Office.org (http://openoffice.org) and Linux wouldn’t be as popular with companies if there weren’t support options available to them. Since commercial support for OpenOffice.org is available from Oracle and Linux is supported by a wide range of companies including Red Hat, Canonical, SUSE, and others, organizations are much more willing to run their businesses on these open source software products.

The PhoneGap project is no different. As more and more companies look at PhoneGap for their mobilization needs, their willingness to select the platform is influenced partially by the availability of commercial support for the framework. In early 2011, Nitobi announced availability of commercial support options for PhoneGap. Support is offered at different levels (from Basic, currently at $249US per year, up to Corporate and Enterprise at $20,000US or more per year), and a wide range of support options are available at each level. You can find information on support options for PhoneGap at www.phonegap.com/support.

PhoneGap Resources

You can find detailed information about how to work with the PhoneGap framework in several places:

• PhoneGap web site: www.phonegap.com

• PhoneGap wiki: http://wiki.phonegap.com

• Google Groups: http://groups.google.com/group/phonegap

• Blogs: www.phonegap.com/blog

Hybrid Application Frameworks

The hybrid application approach PhoneGap uses is not unique to the market. The PhoneGap project may have started the trend, but now several other products on the market use a similar approach, as shown in the following sections. The following products are only a subset of the available options in the hybrid mobile application space.

Appcelerator Titanium

Titanium is another open source hybrid application framework. Appcelerator (www.appcelerator.com) launched Titanium right about the time that PhoneGap started to gain popularity with mobile developers. Titanium works very similarly to PhoneGap in that developers build mobile applications using web technologies, but with Titanium, applications are built entirely in JavaScript. The native application running on a mobile device is just a container executing JavaScript code, as shown in Figure 1-6. The application’s user interface and application logic are all coded entirely in JavaScript.

Figure 1-6 Appcelerator Titanium application structure

AT&T WorkBench and Antenna Volt

These two products provide managed containers for running multiple HTML 5 applications. The solution is implemented as a native application container that is provisioned remotely by a management server. When a user first launches the application, they must authenticate against the back-end infrastructure, and the web applications provisioned for the user are downloaded over the air into the container. What users see is a single application icon on their mobile device screen, but when they launch the application, the list of the provisioned applications appears on the screen, and the user can easily switch between the applications.

This solution is designed primarily for enterprise customers, but there are many use cases for consumer use as well.

Like Worklight, described shortly, WorkBench and Volt are part of an enterprise mobile application platform that includes additional server components (with management and reporting capabilities as well as the ability to provide connectors to back-end data sources).

You can find additional information on these solutions at www.wireless.att.com/businesscenter/built-for-business/AMEAP.jsp and www.antennasoftware.com/resource-center/volt.

BlackBerry WebWorks

The Research In Motion (RIM) developer community complained that it was too hard to build native mobile applications for the BlackBerry platform (in Java), so RIM responded with the BlackBerry WebWorks platform. WebWorks (originally called BlackBerry Widgets, which I think is a much better name) is a hybrid application framework for BlackBerry applications. Developers build mobile applications using HTML, CSS, and JavaScript and use tools from RIM to package the web application into a native Java application container just like PhoneGap does.

When you build a PhoneGap application for BlackBerry, you’re actually using the BlackBerry, a WebWorks SDK to package the web application into a BlackBerry native application. In essence, and there are certainly more technical details behind this, a BlackBerry PhoneGap application is simply a BlackBerry WebWorks application with the custom PhoneGap JavaScript libraries added in.

Strobe

Strobe (www.strobecorp.com) is a mobile application delivery network that utilizes PhoneGap Build (described in Chapter 9) to package native applications built using their frameworks. There’s a free test version of Strobe and additional paid options depending on the size of your development needs. The solution is currently in private beta.

Tiggr

Tiggr (www.gotiggr.com) is a web-based IDE for building mobile applications. It includes a visual editor and jQuery Mobile interface components that can just be dragged onto a web application. Tiggr integrates with PhoneGap to provide native mobile applications built with its IDE. Currently, the Tiggr Mobile Apps Builder is free for a 15-day trial but then costs $45US per month thereafter.

Worklight

Worklight (www.worklight.com) is a commercial mobile application platform built on top of PhoneGap. Worklight provides its own Eclipse-based IDE for building Worklight applications and special server infrastructure for connectivity to provide management and reporting capabilities as well as a mobile optimized conduit to back-end or external applications and application data. Worklight applications are simply PhoneGap applications with some additional capabilities provided by the Worklight platform (implemented through some additional JavaScript libraries). Worklight was acquired by IBM in early 2012.