The enterprise has always focused on providing solutions that enable its users to access important data in a variety of ways. With smartphones being the norm, the enterprise can leverage the mobility of its users and deliver real-time data in a timely fashion. Of course, the smartphone environment is a quickly changing and rapidly evolving environment; as such, solutions need to be equally agile.
PhoneGap/Cordova is a framework that enables the enterprise to target multiple smartphone platforms with a single code base using technologies the enterprise is already largely familiar with. It's a perfect fit for the enterprise, as it doesn't require duplication of effort to build multiple native applications that must essentially be rewritten for each supported platform. Users like choice in their mobile devices, and PhoneGap/Cordova allows the enterprise to offer just that.
Furthermore, since PhoneGap/Cordova provides developers with access to the native features of the user's mobile device, it also provides the necessary technologies to interact with the enterprise's systems over a variety of networks. This means that users can be highly mobile without losing access to highly valuable and timely enterprise data.
It is this ability of PhoneGap/Cordova to display both content using web-based technologies, and interface with the mobile device using native technologies that gives rise to the term hybrid. This simply means that PhoneGap/Cordova apps are neither purely web-based (as a web app would be), nor are they purely native-based (as a native iOS app would be); they are a blend of the two. This allows PhoneGap/Cordova apps to be written using technologies already established within the enterprise while also allowing immense flexibility.
In this chapter, we'll cover the following sections:
Some history behind PhoneGap/Cordova
Reasons why it makes perfect sense in an enterprise development
How PhoneGap/Cordova enables fast cross-platform development
The application structure and the technology stack
This book assumes that the reader has a good working knowledge of PhoneGap/Cordova from a personal perspective, and is also someone who is now tasked with taking that knowledge into the enterprise. As such, we won't cover the installation of PhoneGap/Cordova, neither will we cover the installation of native platform SDKs.
Cordova is a natural fit for the enterprise environment for many reasons, some of which are listed as follows:
Quickly create cross-platform hybrid apps with little duplication of work and high code reuse
Leverage technologies already known by most developers familiar with web, multi-tier, and backend development
Access native features on mobile hardware—including network information, device location, camera, and more
Where necessary, create custom plugins to extend PhoneGap/Cordova for specific needs
Embed PhoneGap/Cordova into existing native apps as a component
A very active development community (nearly 22,000 members in the Google group for PhoneGap), including a good deal of third-party plugin development (as of this writing, 1,168 plugins are made available by 797 different authors); core development is supported by Adobe (PhoneGap) and Apache (Cordova)
Ability to deploy apps internally or to app stores
Open source (Apache license)
Enterprise-grade support options available
Additional features offered for PhoneGap by Adobe for the enterprise (http://enterprise.phonegap.com)
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:
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.
