PhoneGap for Enterprise: Master the art of building secure enterprise mobile applications using PhoneGap

Cordova is a natural fit for the enterprise environment for many reasons, some of which are listed as follows:

Initially, PhoneGap was owned by Nitobi Software. In earlier versions, it was distributed in the form of project templates that could be used in Xcode or Eclipse to create hybrid apps. While it was easy to develop single-platform apps, it was more difficult to develop cross-platform apps (one had to create copies of the web-specific code and keep those copies synchronized across projects). Even so, many production apps were developed and hosted on app stores, and many more were developed and distributed internally within enterprises.

In 2011, Adobe purchased Nitobi Software. As part of the acquisition, the PhoneGap code was contributed to Apache and made open source. The project was ultimately renamed as Apache Cordova. Adobe kept the PhoneGap name and began maintaining a fork of Apache Cordova's code. As such, the version was changed to 2.x. Generally, the two were largely identical (with only minor variations). Since the project templates of the prior 1.x era were often problematic, the project creation transitioned to a command-line interface (CLI). Cross-platform development was now somewhat easier, though not yet ideal.

Apache Cordova 3.x was released in July 2013. It provided a new CLI that dramatically simplified cross-platform development while also making plugin installation easier and less problematic than before. It also decoupled many of the core features and distributed them as core plugins instead. This allowed developers to pick and choose which plugins they needed rather than taking them out later (which was often difficult). This means that apps written with 3.x only need to ask for the permissions they actually use, whereas under 2.x, an app would often ask for permissions it never needed.

Since writing a native app will require an app to be rebuilt from scratch for each additional platform, in Cordova, the largest portion of the app is built on web technologies that are inherently cross-platform. Only the native wrapper and native plugins are specific to each particular platform.

In the 1.x version of PhoneGap, the developer was required to compile the project on their own development machine. The developer needed a machine capable of supporting the specific development environment for each of the supported platforms. When 2.x was released, Adobe made it possible to build projects in the cloud, and recently, they also enabled on-device testing with no build requirement at all.

This means that the developer has many different environments that they can use and none of these environments are mutually exclusive (many are used together). The environments are shown in the following diagram:

Many developers still prefer the local development environment, even though it often requires a good deal of setup and maintenance. The local build environment offers the greatest degree of control because the entire build process takes place on the developer's machine. It's also the most secure: the files and assets remain completely within the enterprise's network unless deploying the app externally.

The PhoneGap build environment allows developers to write their apps on their machine using a text editor and then upload these apps to the cloud for compilation. This means that there is no need to set up and maintain a full development environment—a good text editor is sufficient (though an editor that understands web development is a good idea). There are some platforms that require additional steps before the results can be tested or deployed. However, Apple for example, requires various certificates and provisioning prior to it being tested and deployed on real devices.

Recently, PhoneGap also released the PhoneGap Developer App—this app is downloadable from several app stores and provides one more way to test apps on real devices. The app is itself a PhoneGap app that can connect to your development machine to load HTML, CSS, and JavaScript code. Furthermore, it includes all the core plugins, and if these are all that an app requires, the app can be tested on a physical device without any compilation at all. (Of course, if third-party or custom plugins are necessary, this is no longer entirely possible.) Furthermore, any changes to the code are automatically reflected on the device, eliminating the tedious build and deploy cycle. (This app also works with the Cordova CLI without automatic reloading.) From the security perspective, the app works only on a local network, and unlike PhoneGap Build, no files or assets are transmitted externally.

Ultimately, the result of the Cordova/PhoneGap CLI and the various build environments is to make cross-platform development easier, and enable faster and more agile development (this in turn enables the enterprise to become far more mobile than ever before). Although there is still some native code available that is specific to each platform (including the wrapper around the app's HTML, CSS, and JavaScript and any additional plugins), the CLI makes managing these bits simple, and lets the developer focus on writing the truly cross-platform HTML, CSS, and JavaScript code.

The following diagram shows a simplified view of how this looks:

The WWW or web code is inherently cross-platform (assuming web standards are followed) and should be the same on all platforms. Where necessary, different code paths can be built for specific devices, though this is usually only necessary when talking to certain third-party plugins that are specific to certain platforms.

This cross-platform web code is wrapped by native code. This code is specific to each platform the app supports (and so the app can only run on platforms supported by Cordova). This native code serves to bootstrap the app and instantiate a single full-screen system browser in which the web code is executed.

The native code initializes any native plugins as well; these can be core plugins provided by the Cordova team, third-party plugins developed by other members in the community, or custom plugins developed internally by the enterprise. This is a major benefit of using Cordova; if a particular feature isn't best handled or possible using web technologies, there can be a plugin developed by someone else that implements this feature. If there isn't such a plugin available, it's usually pretty easy to create such a plugin internally.

The native code also provides a bridge, or interface, between the native plugins and platform, and the web code. This bridge provides the mechanism by which the web code can access native device features by providing a simple and consistent API. This enables a web code to talk to specific plugins in order to perform native device functions.

The following diagram provides a bird's-eye view of how each layer talks to one another:

Cordova app structure

A typical Cordova app has the following structure on the filesystem:

A typical Cordova project has a config.xml file in the root directory of the project that specifies the name, description, and other attributes for the project. There can be other files (such as a build script or a readme file, indicated by an asterisk in the previous diagram) that are also project-specific and internally developed by the enterprise to support the project. (If you want to see examples of these additional files, feel free to look at the code package for this book.)

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

All of the web code is put in the root www directory. There are other www directories in other various subdirectories (in the platforms directory); however, these are all duplicates and should be considered build artifacts (they are overwritten each time the project is built). As such, don't commit the platforms directory to your Version Control System (VCS).

The structure of the root www directory is specific to the project under development, and the various frameworks and libraries being used. The example in the preceding diagram is a portion of my typical directory structure within the www directory. Ultimately, there is neither a preferred nor mandated structure within this directory.

The hooks directory might not exist, and it should only be used if you need to perform custom actions when specific events occur in the project. For example, you might need to create a hook that notifies an external build system that the app's build was successful; such a hook will be created in this directory.

Note

Hooks are beyond the scope of this book as they are highly specific to each enterprise and app. However, there is a lot of information available online. The documentation at https://github.com/apache/cordova-lib/blob/master/cordova-lib/templates/hooks-README.md would be a good starting point.

The merges directory is another directory that might not exist and it should be avoided if at all possible. The original intent was to provide a way to override code in the www directory with platform-specific www code. If this code is correctly written according to the various web standards, then it is rarely necessary to use this functionality. If your app needs to behave differently on different devices, it is better to detect the device and branch appropriately.

The platforms directory includes every platform added to the project. As new platforms are added, native wrappers are created within this folder, and the www directory gets duplicated within these wrappers. Essentially, one should consider this directory a build artifact and it should never be checked into VCS.

The plugins directory includes every plugin added to the project. Similar to the platforms directory, it should be considered a build artifact and should never be checked into your VCS. The plugin management should instead be managed using the CLI or a shell script. If you want a good example, please check out the code package for this book.

None of this details how the www code should be structured or what architecture it should use. Cordova is not prescriptive in this regard—you can leverage your knowledge of the existing web frameworks (such as jQuery, Sencha Touch, and so on) and other libraries (such as Underscore, Backbone.js, and so on).

In this chapter, we introduced you to PhoneGap/Cordova and a little bit of its history. We covered the various environments you can use to develop a Cordova app. We also briefly touched upon the application's architecture. Finally, we covered the typical application structure used to create Cordova apps. Before moving on, you might want to visit Appendix A, More about PhoneGap/Cordova, which lists many sites that contain more information regarding PhoneGap and Cordova.

In the next chapter, we'll cover designing and implementing the business logic for your enterprise app built in PhoneGap/Cordova.