1. The What, How, Why, and More of Apache Cordova
This chapter is your introduction to Apache Cordova. I’ll cover what it is, how developers use it to develop mobile applications, how it differs from Adobe PhoneGap, why it was created, how it’s changed over time, where it’s going, and more. You could skip this chapter if you wanted 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 many support forum posts, it seems clear to me that the developers who are just getting started with Apache Cordova don’t really “get” what they’re working with. This chapter should answer many of the initial who, what, where, when, how, and why questions you have related to Apache Cordova and Adobe PhoneGap.
An Introduction to Apache Cordova
Apache Cordova (http://cordova.apache.org) is a free, open-source framework for building cross-platform native applications using HTML5. The creators of Apache Cordova wanted a simpler way of building cross-platform mobile applications and decided the best approach was to use a combination of native and web technologies. This type of mobile application is called a hybrid application.
To build a Cordova application, you create a web application (using whatever tools and user interface [UI] frameworks you want), then use some tools provided by the Cordova team and the software development kit (SDK) from one or more mobile device manufacturers to package the web application into a native application runtime container for each target platform. That’s all there is to it.
Within the native application, the application’s user interface consists of a single screen that contains nothing but a single native WebView object that consumes the available screen space on the device. When the application launches, it loads the packaged web application’s startup page (typically index.html, but the developer can easily change this to something else) into the WebView, then passes control to the WebView 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 the application or can reach out to the network and pull content down from a web or application server.
You can also skip the packaging process and simply have the Cordova application load a remote web site if you want, although Apple doesn’t like that type of application very much. You may find that Apple will reject a Cordova application that operates this way.
The Cordova application packaging process is illustrated in Figure 1.1.
When many developers first learn about this technology, they immediately assume that the web application code is somehow translated into the native language for each supported mobile device platform—converted into Objective-C for iOS or Java for Android, for example—but that’s not what’s happening here. There are some mobile application frameworks that take that approach, but for Cordova, the web application simply runs unmodified within a native application shell.
For some mobile device platforms such as Firefox OS, 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 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, loading, hiding, or unhiding content as needed within a page, playing media files, opening new pages, performing calculations, 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 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.
What Is Adobe PhoneGap?
Adobe PhoneGap is simply a distribution of Apache Cordova with some extra stuff added to it. The PhoneGap developers are essentially the same folks from Adobe who work on the Cordova project. At its core are the Cordova container, application programming interface (API) plugins, and tools described throughout this book. As Adobe’s primary business is selling tools and services, the PhoneGap implementation of Cordova more tightly integrates the framework with Adobe’s other products.
The primary differences between Cordova and PhoneGap are the command-line tools, the PhoneGap Build service, and the recently released PhoneGap Developer App. The PhoneGap command-line tools provide a command-line interface into the PhoneGap Build service; I’ll cover the Adobe PhoneGap Build service in Chapter 12, “Using PhoneGap Build.” You’ll find the PhoneGap command-line interface (CLI) commands described in Chapter 13, “Using the PhoneGap CLI,” and the PhoneGap Developer App in Chapter 5, “The Mechanics of Cordova Development.”
Throughout the remainder of the book (except in the history section that follows), 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.
A Little PhoneGap/Cordova History
PhoneGap was started at the 2008 iPhoneDevCamp by Nitobi, who 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, the PhoneGap developers have 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, the next day as a matter of fact, 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, then briefly as Apache DeviceReady, and finally later (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 where they can work full-time on the project. The result of this is that Cordova is one of the, if not the, most frequently updated Apache projects. The Cordova team was delivering new releases monthly, which is pretty amazing considering the complexity of the code involved, but the pace has slowed somewhat recently.
Cordova Components
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 web application content on the device. On platforms where the native application is a web application, no container exists.
A suite of APIs, implemented as plugins, that provide a web application running within the container access to native device capabilities (and APIs). More on this in the next section.
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. The available tools are described in detail in many of the later chapters in the book.
Documentation for each of the tools and APIs.
Access to Native APIs
At this point, you’re probably thinking that this is no big deal; you can already create a web application and save a link to that web application on a mobile device’s home screen for easy access. The difference here is in what the web application can do when it is running inside the Cordova container: access native APIs not available in the mobile 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, though, for mobile developers, many mobile applications needed to do more than HTML and web browsers could support; building a web application that interacted with the device camera or the local contacts application, for example, simply wasn’t possible. To get around this, Cordova implements a suite of APIs that extend native device capabilities to a web application running within the native container.
A typical mobile web browser application does not usually have access to device-side applications, hardware, and native APIs. For example, the contacts application is not accessible to web applications, nor can a web application typically interact with the accelerometer, camera, compass, microphone, and more or determine the status of the device’s network connection. The typical native mobile application, on the other hand, makes frequent use of those capabilities. To be an interesting mobile application (interesting to prospective application users anyway), a mobile application 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. Essentially these APIs are 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. JavaScript access to native APIs is made available through the JavaScript to native bridge built into the Cordova container.
In versions of Apache Cordova prior to Cordova 3.0, all of the Cordova APIs were built into the Cordova container and were automatically available to any application running in the container. Beginning with Cordova 3.0, each of the Cordova APIs was broken into separate plugins; you can use the Cordova CLI or Plugman, the Cordova plugin manager, to add and remove plugins from your Cordova projects. We’ll talk more about plugins and the Cordova tools later in this chapter and throughout the book.
The Cordova plugin architecture is illustrated in Figure 1.2—an application with discrete code for each plugin and where only the needed plugins are packaged with the application.
Cordova currently provides the following core APIs:
Battery Status
Camera
Contacts
Device
Device Motion
Device Orientation
Dialogs
FileSystem
File Transfer
Geolocation
Globalization
InAppBrowser
Media
Media Capture
Network Information
Splashscreen
StatusBar
Vibration
The Device Motion API is commonly referred to as the Accelerometer API, the Device Orientation API is called the Compass API, and the Network Information API is the Connection API. Most of these APIs are described and demonstrated in Chapter 14, “Working with the Cordova APIs”; more complete coverage of each of the Cordova APIs (about 300 pages’ worth) can be found in this book’s companion: the Apache Cordova API Cookbook (www.cordovacookbook.com).
When a developer implements a feature in an application that uses one of the Cordova APIs, the application calls the API using JavaScript, and then 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 an Android device is different from how it’s done for iOS, so this common API layer allows a developer to implement a single interface that is translated behind the scenes (within the container application or the plugin’s code) 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:
navigator.camera.getPicture(successCallback, errorCallback);
As parameters, the application passes in the names of two callback functions, successCallback and errorCallback, which are called once a picture has been captured or when an error is encountered.
On Android the code being executed by the function might look something like this:
camera.takePicture( shutterCallback, rawCallback, jpegCallback );
However, on iOS, the code might look like this:
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 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 something appropriate for each target platform. This eliminates the need for developers to have intimate knowledge of the underlying technologies, instead allowing them to focus on their application and their application’s capabilities rather than how to accomplish the same task across multiple device types.
As with any developer tool, there are times when the base functionality provided by the solution just isn’t enough for your particular needs. Every developer, it seems, wants that one thing that’s not already in there. Even though Cordova provided a solid set of API capabilities through plugins, the Cordova project team published a solid specification for plugins so developers could build their own.
With that in place, developers started creating all sorts of plugins. There’s a Facebook plugin (https://github.com/phonegap/phonegap-facebook-plugin), an Urban Airship plugin for push notifications (http://docs.urbanairship.com/build/phonegap.html), and one of the most popular plugins, ChildBrowser, eventually became a part of the core Cordova API as InAppBrowser.
To help developers find plugins, the Cordova team published a Cordova Plugin Registry at http://plugins.cordova.io/. Developers can browse the catalog to locate useful plugins for their applications. They can easily publish plugins to the registry using Plugman; I’ll show you how in Chapter 16. Figure 1.3 shows the Plugin Registry web site.
Notice that there aren’t many plugins in the registry—only 325 on the day this screen was captured; I expect the list to continue to grow over time. There’s also a third-party plugin registry called PlugReg available at www.plugreg.com.
Cordova User Interface Capabilities
One of the things I’ve noticed from trolling the Cordova and PhoneGap support forums and reading the Cordova dev list is that, from time to time, developers working with Apache Cordova seem to expect the Cordova framework to deliver some sort of UI capability on top of what it already delivers. They seem to be missing the point that Cordova is simply all about web applications running in a native context with access to native capabilities—nothing more.
The UI capabilities provided by Cordova? None . . . mostly.
Here’s the deal. If you’re a developer, you should already know that developers are pretty picky. They all have their own approach to writing code and what tools and frameworks they like to use. For every tool or framework a developer likes, there are many more that are loathed. When it comes to web application UIs, the public face of the application, developers can be even more critical—they tend to settle on one approach (using a single framework or possibly a collection of tools) and scorn all others. Any UI capabilities implemented by the Cordova team might be used by some developers, but many would ignore them and use whatever other approach they were comfortable with.
For that reason (mostly), the Cordova team focuses its efforts on the container, APIs, and tools and leaves the UI to others.
A Cordova application is a web application, so the UI for the application will be rendered using the application’s HTML, CSS, and JavaScript code. The application’s UI comes from whatever features of HTML you use, what CSS elements you add, and what capabilities your JavaScript code implements.
As an illustration of this, take a look at Listing 1.1. The listing shows a simple, uncomplicated web application.
<!DOCTYPE HTML>
<html>
<head>
<title>Example 1.1</title>
</head>
<body>
<h1>Example 1.1</h1>
<p>This is a sample Apache Cordova application. Notice how the application's UI is
pretty boring. This is because I didn't do anything to make the UI special. Instead,
this application consists of a very simple HTML page with no embellishments.</p>
<p>The application UI is implemented using the default settings for the mobile
device's webView.</p>
</body>
</html>
When you run the application on a mobile device, you will see something similar to what is shown in Figure 1.4 (in this case the application is running on an Android emulator).
In this example, the look-and-feel of the application has not been specified, so the browser simply renders it using its standard settings for headings and paragraphs. Not very pretty, right? That’s because I’ve done no work to make the application pretty. This example actually looks much worse on a desktop browser; at least the mobile device browsers have pleasant default fonts and styles.
If I added some CSS to the page, I could dramatically change the look-and-feel of the application. For your applications, you won’t want to stick with what the browser gives you; instead, use the UI framework that makes the most sense for you and your application’s requirements. There are a ton of them out there to choose from; find one you like and put it to good use since Cordova is not going to do it for you.
In Chapter 17, “Using Third-Party UI Frameworks with Cordova,” I’ll show you how to use some popular HTML5 frameworks for your Cordova applications and will even highlight some that are especially made for hybrid application development. I’ve used jQuery Mobile (www.jquerymobile.com) and Topcoat (www.topcoat.io) for application UIs in my previous Cordova books; for this one I’m going to add a few more just so you can easily see what’s possible (and to give myself more experience with other frameworks).
Where Cordova does add some UI capabilities is when a particular API needs to show the user something. For example, when using the Camera API to capture a photograph, the API simply invokes the device’s Camera application and uses its UI to perform the photo capture. Additionally, the Cordova Notification API (through the use of the Dialogs plugin) implements alert and prompt dialogs an application can use—the content of the dialogs is under programmatic control, but the dialog UI cannot be changed otherwise.
The only other place where I know that the Cordova team has implemented a UI is in the InAppBrowser plugin. InAppBrowser implements a browser sub-window you can use in your applications, and in order to enable certain features, the plugin in some cases renders its own browser chrome.
Supported Platforms
Apache Cordova currently supports the following mobile device operating system platforms:
Android (Google)—http://developer.android.com
BlackBerry 10 (BlackBerry)—https://developer.blackberry.com/
Firefox OS—https://developer.mozilla.org/en-US/Firefox_OS/
Fire OS (Amazon)—https://developer.amazon.com/appsandservices/solutions/platforms/android-fireos/
iOS (Apple)—https://developer.apple.com/devcenter/ios/index.action
Tizen (Linux Foundation)—https://developer.tizen.org
Ubuntu (Canonical)—http://developer.ubuntu.com/
Windows Phone 8 (Microsoft)—http://developer.windowsphone.com/en-us
Windows (Microsoft)—http://msdn.microsoft.com
You can find the complete list of supported operating systems plus the specific capabilities that are supported at http://goo.gl/wKqoZL. Additional platforms are available as well. Cordova has in the past supported WebOS, Samsung bada, and other target platforms; the code for those platforms is still available, usually on GitHub. It seems as if new platforms are constantly being added—I know there is a team working on Google Glass support, and another team is working on implementing Cordova on Sugar Learning Platform (www.sugarlabs.org).
For this book, I’m going to cover what are considered the most popular platforms, Android and iOS, plus some others that I find interesting such as Firefox OS, Windows (including Windows Phone 8), and Ubuntu.
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 to run on the devices he or she was working on. Over time, as Cordova became more popular and mainstream, the mobile device vendors got on board and helped with the implementation of Cordova on their platforms. The folks at BlackBerry are heavily involved with the BlackBerry implementation of Cordova, Google has a large team working on a bunch of stuff, Intel is involved in the Tizen implementation, and I know that 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.
Cordova License
Apache Cordova has been released under the Apache License, Version 2.0. You can find more information about the license at www.apache.org/licenses/LICENSE-2.0.
Working with Cordova
Now that you know a little bit about Cordova, let’s dig into how to build mobile applications using the framework. In this section, I’ll describe how to design your web application so it will run in the container, then describe how to use the available tools to package your web application into a native mobile application.
In subsequent chapters, I’ll give you a detailed analysis of the anatomy of a Cordova application (Chapter 2, “Anatomy of a Cordova Application”), information on how to use third-party frameworks with Apache Cordova (Chapter 17), the mechanics of Apache Cordova development (Chapter 5), and a walk-through of the complete, end-to-end development process (Chapter 15, “Cordova Development End to End”).
Designing for the Container
Cordova applications are web applications running inside a client-side native application container. Because of this, web applications running within a Cordova application leverage an HTML5 offline application structure rather than that of a traditional server-based web application.
In 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, 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; 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). With HTML5, 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, HTML5 supports the addition of a manifest file that lists all of the files that constitute the web application. When the web application’s index file loads, the browser will read the manifest file, 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, and the files listed in the manifest are available on-device, the application can continue working—using any data that might be stored locally.
Hybrid applications don’t leverage the manifest file I spoke of in the previous paragraph; the reason I brought it up was that typically hybrid applications expect all of their web application assets to be available within the container, similarly to what is enabled in the browser with the manifest file.
To run within a hybrid container like Apache Cordova, a web application should be written so it is able to run completely within the 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. Cordova applications don’t have to be written this way; it’s just how it’s typically done today.
Web applications coded in PHP, ASP.NET, JSP, and the like will not run unmodified in the Cordova container. Those applications are designed to run on a web server, and the application’s pages are preprocessed by special software running on the web server before output (typically HTML) is sent to the browser.
I see a lot of support forum posts where developers ask how to get a server-based web application built with one of those technologies to run in the Cordova container. There’s no processor for PHP, ASP.NET, and the other files available in the container, so it simply won’t work. Those applications must be rewritten so that there’s a stand-alone web application running in the Cordova container that then reaches back to the web server for the dynamic content generated by the server using one of those technologies (PHP, ASP.NET, and so on).
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 to work, the resources the app needs to start have to be located within the container.
There are some Cordova developers who 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, watch Lyza Danger Gardner’s presentation from PhoneGap Day 2013 entitled “PhoneGap Self-defense for Web Devs” (www.youtube.com/watch?v=J0aQoor3OGE)—it was amazing. She did an excellent job of describing the approach one must take to craft a mobile web application that “works” in the Cordova container.
Coding Cordova Applications
As mentioned previously, Cordova 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 Cordova application. Cordova applications can do more than standard web applications, through the specialized plugins provided by the framework and third-party developers that I discussed earlier.
The Cordova project doesn’t currently offer or support any special editor for writing 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 integrated development environment (IDE) (www.eclipse.org).
For my previous Cordova books, I coded all of the sample applications using the open-source Aptana Studio (www.aptana.com); it’s an Eclipse-based IDE tailored for web development. It’s a little lighter-weight than Eclipse and allowed me to easily format the project source code for easy importing into this manuscript (two spaces instead of tabs, all code properly aligned, and so on).
Adobe 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 web applications. As it’s an Adobe product, there are both Cordova and PhoneGap plugins for it. It is a relatively new tool, and it already has a robust set of plugins available for it. For this book, I did all of my web application coding using Brackets. I’ll show you how to use Brackets in Chapter 18, “Using Third-Party Tools with Cordova.”
Building Cordova Applications
Once you have a completed web application, whether it uses any of the Cordova 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 Cordova project has its own proprietary tools for packaging or building native applications. To build a Cordova application for each supported mobile platform, the application’s web content (the HTML, CSS, JavaScript, and other files that constitute the application) must be added to an application project appropriate for each mobile platform, then built using the platform’s proprietary tools. What’s challenging about this process is that each mobile platform uses completely different tools, and application projects use different configuration files and most likely a different project folder structure.
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 (there are several) run on Linux, Microsoft Windows, and Macintosh OS X.
The iOS SDK runs only on Macintosh OS X (no surprise there).
The Ubuntu SDK runs only on Linux, most likely only Ubuntu (no surprise there either, I hope).
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 and Windows Phone are popular), you’re going to have to have at a minimum development systems running both Windows and Macintosh OS X. This process is highlighted in Figure 1.5.
For my Cordova development work, I use a loaded Macintosh Mini (Intel I7 Quad Core, 16GB memory, 1TB hard drive) running VMware Fusion (http://goo.gl/cd720d); this configuration allows me to easily run both Windows-based and Macintosh-based SDKs and seamlessly share files between both operating systems. I installed the software development kits for Macintosh on the machine’s OS X partition: Xcode, Ant, NodeJS, Android Developer Tools (ADT), Firefox (for Firefox OS development), and so on. Next, I configured a virtual machine (VM) for Windows 7 and Windows 8 (using legal, licensed copies of each, of course) and installed the compatible tools and SDKs for Windows as well. Fusion allows me to easily share OS X folders with the Windows VMs, so I could quickly share project files across all of the systems. For Ubuntu development, I installed Ubuntu and the SDK on a dedicated Linux system I have in my office, but I could very easily have loaded it all in a VM on my Mac Mini.
In the old days of Cordova development (back in the PhoneGap 1.0 time frame—back when I wrote PhoneGap Essentials), you would use IDE plugins (on Android, iOS, and Windows Phone) or command-line tools (on Android and BlackBerry) or start by copying 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.
To make things easier, in later versions of the framework, the Cordova development team scrapped the IDE plugins and implemented a consistent command-line interface for projects across a wider range of supported mobile device platforms. 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 Interfaces.” 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 which will package the application into a PhoneGap container for several mobile device platforms simultaneously. The PhoneGap Build service is a commercial offering from Adobe; it’s free for open-source projects, but there are paid subscription plans for developers building private applications. I will cover PhoneGap Build in Chapter 12.
Putting Cordova to Best Use
There are people who try to categorize the types of apps you should or should not build with a hybrid container. I really don’t approve of that approach. The hybrid application approach used by Cordova has strengths and weaknesses—and you have to assess your particular mobile application needs against them and decide on a case-by-case basis whether the Cordova approach is the right one for your application.
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://goo.gl/Am4X2s), but then you can read how Sencha was able to build a suitably fast web version of the Facebook application using its HTML5 framework (http://goo.gl/ezXGaH).
Hybrid applications may be slower than a native mobile application in most cases; it’s just the nature of the technology being used. On the other hand, there are many games that have been created using Cordova, so if Cordova performs well enough for games, it should be OK for many of the applications you need to write. In the past, both Android and iOS used a different engine in the WebView than they did for their mobile browsers. With the latest Android (Version 4.4.x) and iOS (iOS 8), the WebView used by Cordova uses the same rendering engine, and therefore has the same performance, as the default, built-in browser on the device.
There are a lot of commercial applications available today that were built using Cordova; you can find a list of many of the applications on the PhoneGap web site at www.phonegap.com/app. 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 proofs of concept of your application’s most critical and complicated features to make sure you can implement them in HTML and you’ll get the performance you need from the framework.
The issues I see are
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—although 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 is a SQLite plugin for Android, iOS, and Windows Phone at http://goo.gl/SnihFb.
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, Cordova might not be the best choice, but you’ll have to try it first and see.
Getting Support
One of the things corporations worry about is getting support for the software products they use for their business applications. An open-source project such as Linux wouldn’t be as popular with companies if there weren’t support options available to them. Since commercial support for Linux is provided by a wide range of companies including Red Hat, Canonical, SUSE, and others, organizations are much more willing to run their businesses on open-source software products. Cordova is no different.
While 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://goo.gl/MTNZIk. 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 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.
Recently, the Cordova development team has started pointing support requests to Stack Overflow (http://stackoverflow.com/questions/tagged/cordova). They’ve created a special tag for Cordova questions and even map PhoneGap to the Cordova tag as well. Going forward this will be the primary source for Cordova and PhoneGap support.
Nitobi, and later Adobe, used to offer commercial support options for PhoneGap, but that option seems to be no longer available. Adobe recently announced PhoneGap Enterprise (http://enterprise.phonegap.com/), which is supposed to include a support offering, but months after the announcement there is still no information available for the offering.
Resources
There are many places online where you can find information about how to work with the Cordova and PhoneGap frameworks. Table 1.1 lists the different web sites where you can find information about Apache Cordova and Adobe PhoneGap.
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. It 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.
Warning
Please don’t use the dev list to ask questions about Cordova development; use Google Groups or Stack Overflow instead. The dev lists are for the developers building Cordova to discuss feature implementation and so on, while the other options are set up specifically to provide Cordova and PhoneGap developers with answers to their questions.
You’ll spend the majority of your time on the Apache Cordova Documentation site, which is shown in Figure 1.6. The site contains a complete reference to all of the Cordova APIs plus additional guides you’ll need as you work with the framework.
While you’re looking at the Documentation site, if you scroll down within either the left or the 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 importantly the getting-started guides for each of the supported mobile device platforms.
The API reference shown in Figure 1.7 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 in your applications.
The documentation is so much better than it was when I wrote PhoneGap Essentials, so it’s probably a good place to start for anything Cordova related. Of course, my Apache Cordova API Cookbook (www.cordovacookbook.com) provides more thorough coverage of the APIs (with complete sample applications and detailed descriptions, with examples, of how each of the APIs actually works).
Cordova Going Forward
When you look at the project’s description on its Apache project home page (http://cordova.apache.org/#about), you’ll see that the project team describes itself almost entirely by the APIs Cordova implements.
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.
In 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 planned on adding more new APIs to the framework soon after the 3.0 release but hasn’t done so.
In May 2012, Brian LeRoux (http://brian.io) from Adobe published an article entitled “PhoneGap Beliefs, Goals, and Philosophy” (http://goo.gl/EmqtjA) where he talked 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 all mobile browsers support these APIs, there won’t be a need for the capabilities Cordova provides and essentially the project will just disappear. A good example of this is how modern browsers are starting to add support for the camera as described in Ray Camden’s blog post “Capturing Camera/Picture Data without PhoneGap” (http://goo.gl/RPnD3E).
However, one of the things I noticed as I finished PhoneGap Essentials 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 that the market will expose native APIs to the browser in a consistent enough way to keep cross-platform development viable.
Hybrid Application Frameworks
The hybrid application approach Cordova uses is not unique to the market. The Cordova project may have started the trend, but there are many other products on the market that use a similar approach. Here is a list of some of the products that use a hybrid application approach. Some are like Cordova and others are built with Cordova inside. This is only a subset of the available options in the hybrid mobile application space:
Appcelerator Titanium
AppGyver
AT&T WorkBench and Antenna Software Volt (they’re the same product)
BlackBerry WebWorks
IBM Worklight
Oracle Application Development Framework (ADF) Mobile
Salesforce Touch
SAP Mobile Platform Hybrid SDK (Kapsel)
Strobe (formerly SproutCore and now part of Facebook)
Tiggr
Wrap-Up
In this chapter, I’ve given you a thorough (I think) overview of what Apache Cordova and Adobe PhoneGap are and how to work with the framework and the tools that are available. You now know a little bit of the history of the framework, where to get support, and what the future looks like for Cordova. Throughout the rest of the book, I’ll start digging into the technical details of how all of this works—I’ll dig into the tools and how to use them, talk about developing for some of the most popular mobile platforms, and even build an application or two.