1. The What, How, Why, and More of Apache Cordova

This chapter is your introduction to the Apache Cordova framework: what it is, how developers use it to develop mobile applications, how it differs from Adobe PhoneGap, why it was created, how it has changed over time, where it’s going, and more. You could skip this chapter and dig into the more technical (and fun) stuff in the chapters that follow, but it’s important to understand the heart of what you’re working with before getting to all of the details.

As I read through support forum posts, it’s clear from many of them that the developers just getting started with Apache Cordova don’t really “get” what they’re working with. This chapter should answer many of the initial what, how, and why questions related to Apache Cordova and Adobe PhoneGap.

The initial benefit of Apache Cordova is the native capabilities above and beyond what is normally supported in the browser. At the time all of this started, the best way to build a mobile application that worked on multiple mobile devices was to build it using HTML. Unfortunately for mobile developers, though, many mobile applications needed to do more than HTML and web browsers could support, and building a web application that interacted with the device camera or the local contacts application simply wasn’t possible. To get around this limitation, Cordova implements a suite of APIs that extend native device capabilities (such as the camera, accelerometer, Contacts application, and so on) to a web application running within the native container.

Apache Cordova consists of the following components:

Source code for a native application container for each of the supported mobile device platforms. The container renders the HTML5 application on the device (more on what this means later, I promise).

A suite of APIs that provide a web application running within the container access to native device capabilities (and APIs) not normally supported by a mobile web browser.

A set of tools used to manage the process of creating application projects, managing plugins, building (using native SDKs) native applications, and testing applications on mobile device simulators and emulators.

To build a Cordova application, you create a web application, package the web application into the native container, test and debug the application, then distribute it to users (typically through an app store). That’s all there is to it. The packaging process is illustrated in Figure 1.1; we talk more about how you package applications later in the chapter.

Within the native application, the application’s user interface consists of a single screen that contains nothing but a single web view that consumes the available screen space on the device. 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, 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 just 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.

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 font settings, lines, spacing, coloring, or shading attributes added directly to HTML elements or implemented through Cascading Style Sheets (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 also be done within a Cordova application.

A mobile web browser application does not typically have access to device-side applications, hardware, and native APIs. For example, a web application typically cannot access the Contacts application or interact with the accelerometer, camera, compass, microphone, and other features, nor can it determine the status of the device’s network connection. A native mobile application, on the other hand, makes frequent use of those capabilities. For a mobile application to be interesting (interesting to prospective application users, anyway), it will likely need access to those native device capabilities.

Cordova accommodates that need by providing a suite of JavaScript APIs that a developer can leverage to allow a web application running within the Cordova container to access device capabilities outside of the web context. These APIs were implemented in two parts: a JavaScript library that exposes the native capabilities to the web application and the corresponding native code running in the container that implements the native part of the API. The project team would essentially have one JavaScript library but separate native implementations on each supported mobile device platform.

Prior to Cordova 3.0, these APIs were implemented as shown in Figure 1.2—a single JavaScript interface that exposed the web application to all of the supported native APIs.

The result, however, was that your Cordova application included JavaScript and native code for every Cordova API. If your application didn’t leverage all of the available APIs, you still had the code in your application for the APIs you weren’t using. You could strip unused APIs from the JavaScript library and the native container, but that was not fun.

Beginning with Cordova 3.0, each of the Cordova APIs has been broken out into separate plugins; you can use the Cordova plugin manager (plugman) to add and remove plugins from your Cordova project. We talk more about plugins and the Cordova tools later in this chapter and throughout the book. This approach provides the architecture illustrated in Figure 1.3—an application with discrete code for each plugin and that is packaged with only the needed plugins.

Cordova currently provides the following APIs:

Accelerometer

Camera

Capture

Compass

Connection

Contacts

Device

Events

File

Geolocation

Globalization

InAppBrowser

MediaNotification

Splashscreen

Storage

Most of these APIs are described in detail in Chapters 10 through 22 of PhoneGap Essentials (www.phonegapessentials.com), but only for PhoneGap and Cordova 2.x.

When a developer implements a feature in an application that uses one of the Cordova APIs, the application calls the API using JavaScript. A special layer within the application translates the Cordova 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 Cordova and the default options for the API, 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, which are called once a picture has been captured or if an error is encountered.

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 they illustrate how Cordova simplifies cross-platform mobile development. A developer makes a single call to a common API available across all supported mobile platforms, and Cordova translates the call into the appropriate code for each target platform. Cordova eliminates the need for developers to have intimate knowledge of the underlying technologies, allowing them to focus on their application rather than on how to accomplish the same task on multiple devices.

The primary differences between Cordova and PhoneGap are the command-line tools and the PhoneGap Build service (described later in the chapter). The PhoneGap command-line tools provide a command-line interface into the PhoneGap Build service; the Adobe PhoneGap Build service is covered in Chapter 11, “Using PhoneGap Build.”

Throughout the remainder of the book (except in the following “PhoneGap History” section), when I refer to PhoneGap, I’m talking about a specific capability that is available only in the PhoneGap version of Cordova. Both versions are free; PhoneGap simply adds some additional capabilities to Cordova.

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. During this period, IBM started contributing to the project, as did many other companies.

In late 2011, Nitobi announced that it was donating PhoneGap to the Apache Foundation. Very quickly thereafter, Adobe announced that it was acquiring Nitobi. PhoneGap joined the open source Apache project (www.apache.org) as an incubator project, first as Apache Callback, briefly as Apache DeviceReady, and finally (beginning with version 1.4) as Apache Cordova (the name of the street where the Nitobi offices were located when PhoneGap was created).

The acquisition of Nitobi by Adobe (and Adobe’s subsequent announcement that it would discontinue support for Adobe Flash on mobile devices) clearly indicates that Adobe saw PhoneGap as an important part of its product portfolio. The folks at Nitobi who were working on PhoneGap in their spare time as a labor of love are now in a position to work full time on the project. The result is that Cordova is one of, if not the, most frequently updated Apache projects. The Cordova team delivers new releases monthly, which is pretty amazing considering the complexity of the code involved.

The Cordova project’s efforts around API implementation were initially guided by the World Wide Web Consortium (W3C) 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.” The plan was for additional APIs to be added as the Cordova project team gets to them and as new standards evolve, but that’s not what’s happened lately.

From the middle of the Cordova 1.x code stream through the end of the 2.x releases, the project team started working on tightening up the framework. They focused primarily on fixing bugs and cleaning up the project’s code. Where there were previously separate JavaScript libraries for each mobile platform, they worked toward consolidating them into a single file (cordova.js) and migrating everything from the PhoneGap to the Cordova namespace. For the 3.0 release, the project team focused on stripping the APIs out of the core container and migrating them into separate plugins, then creating some cool new command-line tools to use to manage application projects. The project team should start adding more new APIs to the framework soon after 3.0 is released.

In May 2012, Brian LeRoux (brian.io) from Adobe published “PhoneGap Beliefs, Goals, and Philosophy” (http://phonegap.com/2012/05/09/phonegap-beliefs-goals-and-philosophy) in which he talks about what was (then) driving the project’s direction. At the time, as mobile device browsers implemented the DAP APIs in a consistent manner, the plan was for Cordova to obsolete itself. The expectation was that when mobile browsers all support these APIs, there would be no need for the capabilities Cordova provides and the project would just disappear. A good example of this is how modern browsers are starting to add support for the camera, as described in Raymond Camden’s blog post “Capturing camera/picture data without PhoneGap” (www.raymondcamden.com/index.cfm/2013/5/20/Capturing-camerapicture-data-without-PhoneGap).

However, one of the things I noticed as I finished PhoneGap Essentials (www.phonegapessentials.com) was that plugins were gaining in prominence in the Cordova space. The APIs provided by Cordova were interesting and helpful to developers, but developers wanted more. Where there were first only a few Cordova plugins available, now there are many, and the core APIs are plugins as well. So, Cordova becomes at its core just a hybrid container, and everything else is done in plugins.

As the browsers implement additional APIs, the core Cordova APIs will become obsolete, but the Cordova container may live on. Cordova could still obsolete itself, but only in a time when the popular mobile browsers provide a standard interface to native APIs. As each platform’s OS and API suite are different, I’m not sure how that would work out. It’s the cross-platform development capabilities of Cordova that make it most interesting to the market; there’s limited chance the market will expose native APIs to the browser in a consistent enough way to keep cross-platform development viable.

Android (Google)—http://developer.android.com/index.html

bada (Samsung)—http://developer.bada.com

BlackBerry 10 (BlackBerry)—https://developer.blackberry.com/

iOS (Apple)—https://developer.apple.com/devcenter/ios/index.action

Firefox OS—https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS

Tizen (originally Samsung, now the Linux Foundation)—https://developer.tizen.org

Windows Phone 7 and Windows Phone 8 (Microsoft)—http://developer.windowsphone.com/en-us

Windows 8 (Microsoft)—http://msdn.microsoft.com

You can find the complete list of supported operating systems plus the specific capabilities that are supported at http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview. For this book, I cover what are considered the most popular smartphone platforms, Android and iOS, plus some others that I find interesting, such as BlackBerry 10 and Windows Phone 8: BlackBerry because I love BlackBerry and it still has a chance, and Windows Phone because, while it’s not extremely popular, it’s cool and different enough that I think it’s interesting.

You’ll notice that Windows 8 as well as Windows Phone 7 and Windows Phone 8 are all listed; as this book is focused on mobile development, desktop operating systems are not addressed here.

It is important to note that when the Cordova project started, support for different mobile platforms was added primarily by an independent developer who was interested in the framework and wanted it running on the devices he or she was working on. Over time, as Cordova became more popular and mainstream, the mobile device vendors got onboard and helped with the implementation of Cordova on their platforms. The folks at BlackBerry are heavily involved with the BlackBerry implementation of Cordova, Intel is involved in the Tizen implementation, and Microsoft has been involved in the Windows implementation as well. What this means for developers is that even though Cordova is an open source project, the device OS companies are heavily involved and have a vested interest in making this project successful. Sadly, only Apple has chosen not to support the framework directly.

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 JavaScript 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.

With the advent of Web 2.0, a reduced load is placed on the web server and instead, JavaScript code running within the browser manages the requesting and presentation of 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 allows 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.

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 (maps.google.com) and Google Gmail (mail.google.com) are good examples of Web 2.0 applications available today.

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.

With HTML5, 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), and they can use a client-side database to store application data. This functionality makes it easier for mobile devices to operate as they go in and out of wireless coverage. Additionally, HTML5 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 reads the manifest file, retrieves all of the files listed in the manifest, and downloads them to the client device. If a mobile device were to lose network connectivity, then as long as the files listed in the manifest were available on-device, the application could continue working—using any data that might be stored locally.

To leverage these HTML5 capabilities, though, a web application must be written so it is able to run completely within the browser container (or, in the case of Cordova applications, within the Cordova 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 by the application. HTML5 applications will still reach out to a server for data as needed, using XHR to request data asynchronously and store it locally.

Web developers must rethink their approach to web development to leverage these capabilities. Instead of retrieving a web application from a web server, the HTML5 application running in the Cordova container must be self-contained, making sure it has the files and data it needs to at least launch and display a UI before optionally reaching out to a remote server for additional content and data. As mentioned earlier, when a Cordova application launches, it loads the web application’s startup page (typically index.html) and associated content (CSS files, JavaScript files) before passing control to the web app. In order for this method to work, the resources the app needs to start have to be located within the container.

Some Cordova developers load as little as possible within the container and, immediately after startup, run off to a server to get the “real” content for the application; I see their questions on the support forums all the time. This approach works, but it’s not the best experience for users and may cause you problems with app store submissions—some smartphone platforms (Apple iOS, for example) don’t like it when your app doesn’t contain content and is merely a shell for a web application being hosted by a web server.

For a great presentation on how to write a web application for Apache Cordova, see if you can track down Lyza Danger Gardner’s presentation from PhoneGap Day 2013—it was amazing. The videos and presentations haven’t been posted yet; otherwise I’d provide a link for you here. She did a really good job of describing the approach you must take to craft a mobile web application that “works” in the Cordova container.

The Cordova project doesn’t currently offer or support any special editor for writing your Cordova applications; you simply need to dig out your web content editor of choice and start coding. To keep things simple, you could use default tools like Notepad on Microsoft Windows or TextEdit on a Macintosh. You could even use something more sophisticated, such as Adobe Dreamweaver (www.adobe.com/products/dreamweaver.html) or the Eclipse IDE (www.eclipse.org).

Adobe, however, offers a free, open source code editor called Brackets (http://brackets.io) that I’ve been playing around with. It provides a nice, clean interface for coding your web applications. As it’s an Adobe product, I expect that you’ll see Cordova and/or PhoneGap integration capabilities in it before long.

For this book, I primarily coded using the open source Aptana studio (www.aptana.com); it’s an open source Eclipse-based IDE tailored for web development. It’s lighter-weight than Eclipse and allowed me to easily format the project source code for importing into this manuscript (two spaces instead of tabs).

Additionally, some of the supported mobile platform development tools will run only on certain desktop operating systems. For example:

The Android SDK runs on Linux, Microsoft Windows, and Macintosh OS X.

The BlackBerry SDKs (they have several) run on Microsoft Windows and Macintosh OS X.

The iOS SDK runs only on Macintosh OS X (no surprise there).

The Windows Phone SDK runs only on Microsoft Windows (no surprise there either).

What this means for developers is that to work with the most popular smartphones (you can argue with me later about whether BlackBerry or Windows Phone are popular), you have to have, at a minimum, development systems running both Windows and Macintosh OS X. For my Cordova development work, I use a loaded Macintosh Mini (Intel I7 quad core, 8GB memory, 500GB hard drive) running VMware Fusion (www.vmware.com/products/fusion/overview.html); this allows me to easily run both Windows-based and Macintosh-based SDKs and seamlessly share files between both OSs.

In the old days of Cordova development (back in the PhoneGap 1.0 timeframe—back when I started my previous book), you would use IDE plugins (on Android, iOS, and Windows Phone) and command-line tools (on Android and BlackBerry), or you would copy a sample application (on bada, Symbian and webOS) to create a new project. You would start with one of the supported platforms, write the appropriate web content, then package and test the application using the selected platform’s SDK. Once you had it all working correctly, you would copy the web content over to a new project for one of the supported platforms and repeat the process. There was little consistency in project folder structure, framework JavaScript files (they had different file names on some platforms and were markedly different for each), and build process across mobile device platforms. This process is highlighted in Figure 1.4.

To make things easier, in later versions of the framework, the Cordova development team scrapped the IDE plugins and implemented a command-line interface for projects across a wider range of supported mobile device platforms. For some of the mobile platforms (Symbian and webOS, for example), you may still need to copy a sample project to get started, but the process is simpler and more consistent now. You use the command-line tools to create new projects, manage (add, remove, list, update) plugins, and build then test applications using the device emulators and simulators. The Cordova command-line tools are described in detail in Chapter 4, “Using the Cordova Command-Line Interface.” You can still do it by hand, but the command-line tools make it much easier.

Adobe also offers a cloud-based packaging service for PhoneGap applications called PhoneGap Build. This service allows you to upload a web application to the Build service servers, and it packages the application into a PhoneGap container for the following mobile device platforms:

Android

BlackBerry

iOS

Symbian

webOS

Windows Phone

The PhoneGap Build service is a commercial offering from Adobe; it’s free for open source projects, but paid subscription plans are available for developers building private applications. PhoneGap Build is covered in Chapter 11.

With that in place, developers started creating all sorts of plugins. There’s a Facebook plugin (https://github.com/phonegap/phonegap-facebook-plugin), Urban Airship plugin for push notifications (http://docs.urbanairship.com/build/phonegap.html), and one of the most popular plugins, ChildBrowser, actually became a part of the core Cordova API as inAppBrowser. The Cordova development team eventually even migrated all the core Cordova APIs into plugins. I’ll show you how to create your own Cordova plugin in Chapter 13, “Creating Cordova Plugins,” but for now you can browse a repository of Cordova plugins here: https://github.com/phonegap/phonegap-plugins.

Web applications are likely going to be slower than native applications, but an inexperienced developer can easily build a native application that performs poorly (without even trying very hard, it seems). You can read about Facebook ditching HTML5 and switching to native for performance reasons (http://techcrunch.com/2012/12/13/facebook-android-faster), but then you can read how Sencha was able to build a suitably fast web version of the Facebook application using its HTML5 framework (www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story).

Hybrid applications may be slower than native mobile applications in most cases; it’s just the nature of the technology being used. There are reports out there indicating that in more recent versions of iOS, Apple limited the performance of JavaScript running in a web view (instead of in the browser). On the other hand, many games have been created using Cordova, so if Cordova performs well enough for games, it should be okay for many of the applications you need to write.

A lot of commercial applications available today were built using Cordova; you can find a list of many of the applications on the PhoneGap website 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 Cordova for their employee-facing applications as well. There are many commercial mobile development tools with Cordova inside and likely more in the works.

So where should you use Cordova? Use it anywhere you feel comfortable using it. Do some proof-of-concepts of your application’s most critical and complicated features to make sure you can implement it in HTML and get the performance you need from the framework.

The issues I see are these:

Can you implement the app you want using HTML?—There are so many JavaScript and CSS frameworks out there to help simplify mobile web development that most things a developer wants to do in an application can be done in HTML.

Can you get the performance you need from a hybrid application?—That you’ll have to prove with some testing.

So where does it fail?

Early on, Cordova would fail when you wanted to build an application that needed access to a native API that wasn’t already exposed through the container. Nowadays, with all of the plugins available, you’re likely to find one that suits your application’s requirements—if not, write your own plugin and donate it to the community. Cordova doesn’t (today) have access to the Calendar or email client running on the device, so if your application has requirements for those features, you may be out of luck—but don’t forget about plugins.

If your application needs to interface with a particular piece of hardware (either inside the device or outside), Cordova might not be the best choice for you unless there’s a plugin for the hardware.

If your application requires heavy-duty offline capabilities such as a large database and offline synchronization, you could run into issues. However, there are several HTML5-based sync engines that should work within a Cordova container, and there are SQLite plugins for Android (https://github.com/pgsqlite/PG-SQLitePlugin-Android) and iOS (https://github.com/pgsqlite/PG-SQLitePlugin-iOS).

Try it out with some common use cases for your application and see what happens. If you are building an application with a large database and a bunch of heavy data-entry forms, this might not be the best choice for Cordova, but you’ll have to try it first and see.

Although there is no Cordova support area, the best place I’ve found for getting support for the framework is the PhoneGap area in Google Groups (http://groups.google.com/group/phonegap). A lot of experienced developers monitor the list of questions, and you can usually get an answer there pretty quickly. You can even find me up there from time to time answering questions that I can.

There’s also a support forum for PhoneGap Build located at http://community.phonegap.com/nitobi/products/nitobi_phonegap_build. The forums are supposed to be for questions related to the PhoneGap Build service, but a lot of developers incorrectly use the forum for general PhoneGap development questions as well. Please do me a favor and use the Build forums for PhoneGap Build–related questions and the Google Groups area for questions on any other PhoneGap-related questions. In my experience, you’ll get a faster and sometimes better response to a PhoneGap development question in Google Groups.

In early 2011, Nitobi announced availability of commercial support options for PhoneGap, and Adobe has continued the offering after the acquisition. Support is offered at different levels (from Basic, currently at $249US per year, to Corporate, at $20,000US per year). There’s even an Enterprise support option available, pricing for which is not publically available, so you will need to contact Adobe for pricing. Information on the available support options for PhoneGap can be found at www.phonegap.com/support.

To stay informed about what’s going on with the project, you can sign up for the mailing lists at http://cordova.apache.org/#mailing-list. If you have some extra time, it is fun to read through the emails as the development team discusses the implementation of a new feature or tracks down a bug. The dev mailing list is used by the developers of the Cordova framework to discuss issues and make decisions about the Cordova implementation. The Commits mailing list is for tracking commit logs for the Cordova repositories when new or updated code is added to a version of the framework. The Issues mailing list is for conversations around bug and feature requests submitted to the Cordova Jira issue and bug tracking system at http://issues.apache.org/jira/browse/CB.

Where you’ll spend the majority of your time will be on the Apache Cordova Documentation site, which is shown in Figure 1.5. The site contains a complete reference to all of the Cordova APIs plus additional guides you’ll need as you work with the framework.

The documentation is far better than it was when I wrote PhoneGap Essentials, so it’s probably a good place to start for anything Cordova related.

The API reference shown in Figure 1.5 includes a complete reference for all of the methods, properties, and events for each of the Cordova APIs. On the API pages, you’ll also find sample source code and additional information you will need to make use of the APIs.

While you’re looking at the Documentation site, if you scroll down within either the left or right side of the page, you will see the list of guides shown in Figure 1.6. These guides contain a lot of useful information a developer needs to work with the framework, including how to create plugins, using the command-line tools, and most important, the getting-started guides for each of the supported mobile device platforms.

Appcelerator Titanium

AT&T WorkBench and Antenna Software Volt

BlackBerry WebWorks

IBM Worklight

Oracle Application Development Framework (ADF) Mobile

Salesforce Touch

SAP Mobile Platform (this is the product I work on)

Strobe (formerly SproutCore and now part of Facebook)

Tiggr