The History of Cordova (aka PhoneGap)

Developers are often confused by the difference between Apache Cordova and PhoneGap. In an attempt to clear up this confusion, we need to understand the origins of this project. In late 2008, several engineers from Nitobi attended an iPhone development camp at the Adobe offices in San Francisco. They explored the idea of using the native web view as a shell to run their web applications in a native environment. The experiment worked. Over the next few months, they expanded their efforts and were able to leverage this solution to create a framework. They named the project PhoneGap, since it allowed web developers the ability to bridge the gap between their web apps and the device’s native capabilities. The project continued to mature, and more plugins were created, enabling more functionality to be accessed on the phone. Other contributors joined the effort, expanding the number of mobile platforms it supported.

In 2011, Adobe bought Nitobi, and the PhoneGap framework was donated to the Apache Foundation. The project was eventually renamed Cordova (which is actually the street name of Nitobi’s office in Vancouver, Canada).

Apache Cordova versus Adobe PhoneGap

Since there is both Apache Cordova and Adobe PhoneGap, it is quite easy to confuse the projects. This naming issue can be a source of frustration when researching an issue during development and having to search using both Cordova and PhoneGap as keywords to find the solutions, or even reading the proper documentation, as the two projects are so intertwined.

A good way to understand the difference is to think about how Apple has its Safari browser, but it is based on the open source WebKit engine. The same is true here: Cordova is the open source version of the framework, while PhoneGap is the Adobe-branded version. But in the end, there is little difference between the two efforts. There are some slight differences in the command-line interfaces, but the functionality is the same. The only thing you cannot do is mix the two projects in the same application. While not as dangerous as when the Ghostbusters crossed their streams, using both Cordova and PhoneGap in the same project will produce nothing but trouble.

The main difference between the projects is that Adobe has some paid services under the PhoneGap brand, most notably the PhoneGap Build service. This is a hosted service that enables you to have your application compiled into native binaries remotely, eliminating the need to install each mobile platform’s SDKs locally. The PhoneGap CLI has the ability utilize this service, while the Cordova CLI does not.

The other difference is the PhoneGap CLI can be used in tandem with the PhoneGap developer app. This free mobile app allows for your app to run on-device without the need to first compile it. This provides a very easy method to test and debug your application on-device. Don’t worry, there is an Ionic equivalent for us to leverage, and we will be using it during our development cycle.

In this book, we will be using the Cordova command-line tool when we are not using the Ionic command-line tool. This is in part due to the fact the Ionic CLI is based on the Cordova CLI, not the PhoneGap CLI.

A Deep Dive into Cordova

In the past, configuring a Cordova project was a difficult task. It meant first creating a native application project in each platform’s IDE, then modifying it to support the interfaces for Cordova. With the release of the command-line tool, this process became easier. The CLI scaffolds a basic project and configures it to work with any supported mobile platform you can use. The Cordova CLI also allows us to have easy integration and management of the plugins for our project. Finally, the CLI enables us to quickly compile our app to run in a simulator or on an actual device. We will be exploring these commands further as we work through our sample applications.

Configuring Your Cordova App

Each Cordova application is defined by its config.xml file. This global configuration file controls many of the aspects of the application, from app icons, plugins, and range of platform-specific settings. It is based on the W3C’s Packaged Web Apps (Widgets) specification. The Ionic CLI will generate a starter config.xml file during its scaffolding process.

As you develop your Ionic application, you will need to update this file with new elements. Some common examples of this are adjusting the app name, the app ID string, or adding a platform-specific setting like android-minSdkVersion.

A deeper exploration of the config.xml can be found in Appendix A.

Device Access (aka Plugins)

Some of the real power of Cordova comes from its extensive plugin library. At the time of this writing, there were over 1,250 plugins. But what is a Cordova plugin? Here is how the Cordova website defines them:

A plugin is a bit of add-on code that provides JavaScript interface to native components. They allow your app to use native device capabilities beyond what is available to pure web apps.

As mentioned earlier, there are two sets of plugins: core and third-party. Time for another brief history lesson. Up to version 3.0 of PhoneGap (pre-Cordova), the code base contained both the code to use the WebView and its communication to the native app, along with some of the “key” device plugins. Starting with version 3.0, all the plugins were separated out as individual elements. That change means that each plugin can be updated as needed, without having to update the entire code base. These initial plugins are known as the “core” plugins.

But what about the other 1,220 or so plugins—what do they provide? An incredibly wide range of things: Bluetooth connectivity, push notifications, TouchID, and 3D Touch, just to name a few.

Interface Components: The Missing Piece

While Cordova provides a lot of functionality to the developer in terms of being able to leverage code across multiple platforms, extend beyond the web, and use native device features, it is missing one critical component: user interface elements. Beyond just the basic controls that HTML provides by default, Cordova does not offer any components like those found in a native SDK. If you want to have a tab bar component, you are either going to have to create the HTML structure, write the needed CSS, and develop the JavaScript to manage the views, or use a third-party framework, like Ionic.

This lack of a UI layer has often been one of the difficulties in working with Cordova. With the release of the Ionic Framework, developers now have a first-rate interface toolkit with which they can author their mobile applications. There are other solutions available for a Cordova application, but this book is focused on Ionic. If you would like to look at some other options, you might look at OnsenUI, Framework7, or ReactJS as an option. For me, I have been very pleased with what I have been able to build with the Ionic framework and its services.

Why Not Cordova?

Although Cordova is an incredibly powerful solution for building mobile applications, it is not always the right choice. Understanding the advantages and disadvantages of the framework is critical in how well your application will perform. Our Cordova application is several layers away from the actual native layer. So, great care must be taken to develop a performant Cordova application. This was very true during the early days of PhoneGap, when devices were relatively low powered. Current mobile devices have much more computing power that can be used.

With that said, you are not going to develop the next Angry Birds or Temple Run using Cordova. But you might be able to build the next Quiz Up, Untappd, or Trivia Crack.

Understanding Web Standards

Another thing to consider is what the WebView is actually capable of. Although most mobile WebViews are fairly current with recognized web standards, it is always worthwhile to understand there might be issues or quirks. If you have been doing any modern web development, there is a good chance you have used http://caniuse.com.

This is an excellent resource to check if a particular HTML5 feature is available, or if a CSS property is supported. For example, if we wanted to use scalable vector graphics (SVGs) in our application to assist in dealing with a range of screen sizes and densities, we can go to http://caniuse.com and see when each mobile platform began supporting it (Figure 5-2).

Figure 5-2. SVG support across various browsers

In this case, we can see that while iOS has had support for several versions, the Android platform only recently enabled support for this format.

It is worth noting exactly where the WebView that Cordova uses comes from. When you compile your application, Cordova does not actually include a WebView into the application. Instead, it will use the WebView that is included on the device as part of its OS. That means current iOS devices get a version of WebKit, while certain Android devices will be using Chromium, and others might still be using WebKit.

Although, recently active development was halted, the Crosswalk Project is still an worthwhile solution if you need to release your application for older Android devices. This plugin replaces the default WebView in your Cordova project with the latest version of Google Chromium, thus giving you the latest browser support. Although using this solution will increase the size of your application, it can help in normalizing the web features that you can use. If your application will be used by older Android devices, using Crosswalk can great resolve some of the browser issues that exist.

Summary

Now you should have a better understanding of how Apache Cordova works and how it enables you to use your web technology skills to create mobile applications. In this chapter, we looked at how Cordova bridges between the native layer and the web technology layer. It’s plugin architecture was introduced, which will allow us to access native device features in our hybrid applications. We touched on whether this solution was the right choice for your development needs. Finally, we covered why there is a need for a framework like Ionic.