This chapter is from the book
This chapter is from the book
This chapter is from the book
Cordova Initialization
Now let’s take the previous example application and add some Cordova-specific stuff to it.
Even though the Cordova container exposes native APIs to the web application running within it, in general (there are a few exceptions) those APIs are not available until the plugin that exposes the API has been added to the project. Additionally, the Cordova container has to do some prep work before any of its APIs can be utilized. To make it easy for developers to know when they can start using APIs exposed by the Cordova container, Cordova fires a specific event, the deviceready event, once it has finished its initialization and it’s ready to go. Any application processing that requires the use of the Cordova APIs should be executed by the application only after it has received its notification that the Cordova container is available through the deviceready event.
The Hello World #2 application shown in Listing 2.2 has been updated to include code that uses a deviceready event listener to determine when the Cordova container application has completed its initialization. In this simple example, the application just displays an alert dialog when the event fires.
Listing 2.2 Hello World #2 Application
<!DOCTYPE html>
<html>
<head>
<title>Hello World #2</title>
<meta charset="utf-8" />
<meta name="format-detection" content="telephone=no" />
<meta name="viewport" content="user-scalable=no, initial-scale=1,
maximum-scale=1, minimum-scale=1, width=device-width,
height=device-height" />
<script src="cordova.js"></script>
<script>
function onBodyLoad() {
console.log("Entering onBodyLoad");
alert("Body Load");
document.addEventListener("deviceready", onDeviceReady, false);
}
function onDeviceReady() {
console.log("Cordova is ready");
navigator.notification.alert("Cordova is ready!");
}
</script>
</head>
<body onload="onBodyLoad()">
<h1>Hello World #2</h1>
<p>This is a sample Cordova application.</p>
</body>
</html>
On the iPhone simulator, the application will display the screen shown in Figure 2.3.
)
Figure 2.3 Hello World #2 Application Running on an iOS Simulator
Let’s take a look at the sample application as there’s a lot of new stuff in this example.
Within the <head> section of the web page are a few new entries, some meta tags that describe the content type for the application, and some other settings. For the most part, I pulled these meta tags from the default Cordova HelloCordova application described later in the chapter.
The charset tag identifies the character encoding used for the HTML document. What I’ve shown here is the default option; you would change this only if you were using a different character set for the HTML page.
<meta charset="utf-8" />
The next tag disables the embedded web browser’s automatic processing of telephone numbers. With this option disabled, as shown below, the browser won’t automatically turn phone numbers on the page into clickable links. You would need to change telephone=no to telephone=yes to enable this option.
<meta name="format-detection" content="telephone=no" />
Honestly, I’m really not sure why the Cordova team did this in their sample application; you would probably assume the user was running the application on a smartphone and would want phone numbers to be automatically enabled as links.
The viewport settings shown in the following tell the embedded web browser rendering the content how much of the available screen real estate should be used for the application and how to scale the content on the screen:
<meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width, height=device-height" />
In this case, the HTML page is configured to use the maximum height and width of the screen (through the width=device-width and height=device-height attributes) and to scale the content at 100% and not allow the user to change that in any way (through the initial-scale=1, maximum-scale=1, and user-scalable=no attributes).
There’s also a new script tag in the code that loads the Cordova JavaScript library:
<script src="cordova.js"></script>
This loads the core Cordova API library and makes any core Cordova APIs available to the program. This file is also responsible for loading and initializing all of the plugins you have added to your Cordova application. You don’t have to add the cordova.js file to your project; this is done for you automatically by the Cordova CLI (described in Chapter 4, “Using the Cordova Command-Line Interfaces”), but you do need to add this reference to your application.
To set up the deviceready event listener we need for Cordova, the application adds an onload event function to the application’s body tag using the following:
<body onload="onBodyLoad()">
Within the onBodyLoad function, the code registers an event listener that instructs the application to call the onDeviceReady function when the Cordova container is ready, when the Cordova application container has finished its initialization routines and fired its deviceready event:
function onBodyLoad() {
document.addEventListener("deviceready", onDeviceReady, false);
}
In this example application the onDeviceReady function simply displays a Cordova alert dialog (which is different from a JavaScript alert dialog) letting the user know everything’s OK:
navigator.notification.alert("Cordova is ready!")
In production applications this function could update the UI with content created through API calls or do whatever other processing is required by the application. (You’ll see an example of this in Listing 2.4.)
One of the things I do during testing is use the web browser console to display status messages as the application runs using code similar to the following:
console.log("Entering onBodyLoad");
I’ll show you how this works in Chapter 5, “The Mechanics of Cordova Development.”
In the onBodyLoad function, I also make sure to make a call to the JavaScript alert function so I can easily tell that the onload event has fired:
alert("Body Load");
As I mentioned earlier, the Cordova container fails silently when it encounters an error with the web application’s source code. So, if I have this alert in the code and it doesn’t fire, I know very quickly (in the very first code the application executes) that something is wrong with the application.
In the deviceready event handler, I always add a call to navigator.notification.alert as shown in the example code. This allows me to confirm visually that the deviceready event has actually fired, plus it allows me to confirm that the Cordova Dialogs plugin has been added to the project and that any other debug alerts I put into the code will be operational. I use the Cordova alert instead of the JavaScript alert because it’s better looking (I can set the title of the dialog, for example, although I didn’t do that here); it also gives me access to callback functions I can use to perform extra steps when something interesting happens.
Remember, most of the Cordova APIs have been removed from the container and implemented as plugins. So, to utilize the Cordova alert method, you must add the Dialogs plugin to your application by opening a terminal window to your Cordova project folder and issuing the following command:
cordova plugin add org.apache.cordova.dialogs
You’ll learn all about how to use the cordova command in Chapter 4. You’ll learn more about the Dialogs plugin in Chapter 14, “Working with the Cordova APIs.”
The deviceready event will fire when the Cordova container finishes initializing, but it will also fire any time a new deviceready event listener is added by the application. Listing 2.3 shows this in action.
Listing 2.3 Hello World #3 Application
<!DOCTYPE html>
<html>
<head>
<title>Hello World #3</title>
<meta charset="utf-8" />
<meta name="format-detection" content="telephone=no" />
<meta name="viewport" content="user-scalable=no, initial-scale=1,
maximum-scale=1, minimum-scale=1, width=device-width,
height=device-height" />
<script src="cordova.js"></script>
<script>
function onBodyLoad() {
console.log("Entering onBodyLoad");
alert("Body Load");
document.addEventListener("deviceready", onDeviceReady, false);
}
function onDeviceReady() {
console.log("Entering onDeviceReady");
navigator.notification.alert("Cordova is ready!");
}
function addSecondDeviceReadyListener() {
console.log("Entering addSecondDeviceReadyListener");
document.addEventListener("deviceready", someOtherFunction, false);
}
function someOtherFunction() {
console.log("Entering someOtherFunction");
navigator.notification.alert("Second deviceready Function Fired.");
}
</script>
</head>
<body onload="onBodyLoad()">
<h1>Hello World #3</h1>
<p>This is a sample Cordova application.</p>
<button onclick="addSecondDeviceReadyListener()">Add deviceready Event Listener</ button>
</body>
</html>
In this example, I’ve added a button to the application’s main page. When the button is tapped, an additional deviceready event listener is defined, and then the callback function for the new listener is immediately executed by the Cordova container. In this case, the onDeviceReady function executes once the container completes its initialization, and then the someOtherFunction function executes only after the second deviceready event listener has been added.