This chapter is from the book
This chapter is from the book
This chapter is from the book
Building Cordova Applications
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 appropriate application project for each platform and 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 tools (there are 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).
In the old days of Cordova development, you would use IDE plugins (on Android, iOS, and Windows Phone), 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 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, build, and then test applications using the device emulators and simulators. You can still do all of this by hand if you want to, but the command-line tools make it much easier.
Now, as this is a book about the Cordova APIs, I’m not going to spend too much time talking about the CLI and the development process. That particular topic is covered in great detail (about 200 pages’ worth) in Apache Cordova 3 Programming (www.cordovaprogramming.com), but you can also find details in the Cordova Command-line Interface guide on the Cordova documentation site at http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface and in the Platform Guides at http://cordova.apache.org/docs/en/3.0.0/guide_platforms_index.md.html#Platform%20Guides.
If you are building an app for Android and iOS, you would open a terminal window and execute the following:
cordova create lunch_menu cd lunch_menu cordova platform add android ios
At this point, what you’d have is a new Cordova project folder called lunch_menu with a bunch of subfolders, as shown in Figure 1.3. There’s a platforms folder that contains native application projects for Android and iOS. Additionally, there’s a folder called www that contains the application’s core web content files, the content files that will be shared across the Android and iOS projects (or whatever platforms you want to use for your application).
)
Figure 1.3 Cordova Application Project Folder Structure
For your application, you will edit the web content stored in the www folder. When the web application content in that folder is ready for testing, you will use the CLI to copy the code into the platforms subfolders shown in the figure.
What I do while working on a Cordova project is keep my web content files open in an HTML editor like Adobe Brackets (www.brackets.io) or Aptana Studio (www.aptana.com) and then use the CLI to manage my mobile device platform projects for me. As I edit the files, I add the web content to the .html file and my application’s code to the application’s .js files; when I’m ready to test (and debug) the application, I switch over to a terminal window that I keep open and pointed to the Cordova project’s root folder (the lunch_menu folder I created a while back) and issue some commands. If I want to switch to the Android IDE and test the Android application, I issue the following command:
cordova prepare android
Or, if I will be testing and debugging both the Android and iOS versions of the application, I issue the following command:
cordova prepare android ios
I could just prepare all target operating systems for the project using the following:
cordova prepare
What this command does is copy all of the project files from the www folder into the appropriate place for each platform project folder as shown in Figure 1.4. In this example, it copies the web content folder (www) to the Android project’s assets/www folder and the iOS project’s www folder.
)
Figure 1.4 Copying Web Content to the Platform Projects Folders
With the project’s files prepared, you can use the CLI to launch the application in an emulator or on a physical device for testing. You can also open the appropriate IDE and test/debug the application directly in the IDE. You can learn a lot more about the testing and debugging process in Apache Cordova 3 Programming (www.cordovaprogramming.com), Chapters 6 through 10.