Home > Articles

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Leveraging Cordova Debugging Capabilities

As you test your Cordova applications, you’re likely to run into issues that you must resolve. The purpose of this section is to highlight some of the debugging capabilities that are available to you outside of an IDE.

Using Alert()

One of the simplest, and most annoying, ways to debug a Cordova application is to use the JavaScript alert() function to let you know what part of the code you’re running or to quickly display the contents of a variable. I’ve always called this approach the “poor man’s debugger,” but it works quite well for certain types of application debugging tasks. If you see an event that’s not firing within your application or some variable that’s not being set or read correctly, you can simply insert an alert() that displays a relevant message and use that to see what’s going on.

As I started working with PhoneGap and PhoneGap Build, I noticed that there were many times when the deviceready event wasn’t firing in my applications. I would write my application and start testing it only to find that none of the PhoneGap APIs were working. In some cases, it was because the PhoneGap Build service wasn’t packaging the phonegap.js file with the application (that’s what happens when you use a beta product). In other cases, it was simply because I had some stupid typo in the application that I couldn’t see.

What I started doing in my then PhoneGap, now Cordova, applications was to add a call to alert() in the onBodyLoad and onDeviceReady functions of all of my applications during development. In Chapter 5, I provided a listing for the HelloWorld3 application, but the real HelloWorld3 application code is shown in Listing 6.1. In this version of the application, you can see the calls to alert in the onBodyLoad and onDeviceReady. Once I was certain that the application worked correctly, I would remove the alerts.

Listing 6.1 The “Real” HelloWorld3 application

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-type" content="text/html;
      charset=utf-8">
    <meta name="viewport" content="user-scalable=no,
      initial-scale=1, maximum-scale=1, minimum-scale=1,
      width=device-width;" />
    <script type="text/javascript" charset="utf-8"
      src="Cordova.js"></script>
    <script type="text/javascript" charset="utf-8">
      function onBodyLoad() {
        alert("onBodyLoad!");
        document.addEventListener("deviceready", onDeviceReady,
        false);
      }
      function onDeviceReady() {
        alert("onDeviceReady!");
        br = "<br />";
        //Get the appInfo DOM element
        var element = document.getElementById("appInfo");
        //Replace it with specific information about the device
        //running the application
        element.innerHTML = 'Cordova Version: ' +
          device.cordova + br +
          'Platform: ' + device.platform + br +
         'Model: ' + device.model + br +
         'OS Version: ' + device.version;
       }
    </script>

  </head>
  <body onload="onBodyLoad()">
    <h1>HelloWorld3</h1>
    <p>This is a Cordova application that makes calls to the
    Cordova APIs.</p>
    <p id="appInfo">Waiting for Cordova Initialization to
    complete</p>
  </body>
</html>

When I was writing all of the sample applications for PhoneGap Essentials, I even go as far as to put an alert at the beginning of every function in the application. As I learned how and when each event fired, I used the alerts to help me tell what was going on. Now, there are easier ways to do that, which I show you in the next section, but this was just a simple approach to help me as I got started with each API.

Writing to the Console

The problem with using the approach described in the previous section is that when you fill your buggy code with alerts, you’re constantly interrupting the application flow to dismiss the alerts as they come up. For a simple problem, this approach works pretty well, but when debugging more troublesome errors, you need an approach that allows you to let the application run then analyze what is happening in real time or after the application or a process within the application has completed, without interrupting the application. Cordova applications can do this through the JavaScript console object implemented by the WebKit browser-rendering engine.

Using the console object, developers can write messages to the browser’s console that can be viewed outside of the running program through capabilities provided by the native SDKs or device simulators. The console object has scope at the window level, so it’s essentially a global object accessible by any JavaScript code within the application. WebKit supports several options; the most common ones used are listed here:

  • console.log("message");
  • console.warn("message");
  • console.error("message");

Beginning with Cordova 3.0, the console has been removed from the core Cordova APIs and is instead available as a plugin. To add console capabilities to your Cordova project, you must open a terminal window, navigate to the project folder, and issue the following command:

cordova plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-console.git

Now, let’s take a look at a sample application that illustrates the use of this feature, as shown in Listing 6.2

Listing 6.2 Example Application That Writes to the Console

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,
      height=device-height, initial-scale=1.0,
      maximum-scale=1.0, user-scalable=no;" />
    <meta http-equiv="Content-type" content="text/html;
      charset=utf-8">
    <script type="text/javascript" charset="utf-8"
      src="cordova.js"></script>

    <script type="text/javascript" charset="utf-8">

      function onBodyLoad() {
        document.addEventListener("deviceready", onDeviceReady,
          false);
      }
      function onDeviceReady() {
        //Just writing some console messages
        console.warn("This is a warning message!");
        console.log("This is a log message!");
        console.error("And this is an error message!");
      }

    </script>
  </head>
  <body onload="onBodyLoad()">
    <h1>Debug Example</h1>
    <p>Look at the console to see the messages the application
    has outputted</p>
  </body>
</html>

As you can see from the code, all the application has to do is call the appropriate method and pass in the text of the message that is supposed to be written to the console.

Figure 6.6 shows the messages highlighted in the Xcode console window. This window is accessible while the program is running on an iOS simulator, so you can debug applications in real time.

Figure 6.6

Figure 6.6 Cordova iOS Application Output Log in Xcode

On some platforms, the console will display log, warning, or error messages differently, making it easier for developers to identify a warning versus an error message. To illustrate this, Figure 6.7 shows the contents of the Android LogCat (described in Chapter 7, “Android Development with Cordova”). Notice that the different console message types are color coded, making it easier for you to spot a particular type of message.

Figure 6.7

Figure 6.7 Cordova Android Application LogCat Output in Eclipse

Remember I mentioned in the previous section that the JavaScript code in a Cordova application fails silently? Well, you can also wrap the code in a try/catch block so your application will at least have the chance to write its error to the console, as shown in the following example:

try {
  console.log("Validating the meaning of life");
  someBogusFunction("42");
} catch (e) {
  console.error("Hmmm, not sure why this happened here: " +
    e.message);
}

Notice that in Figure 6.7, the Android LogCat shows you the line number where the console message was generated. This helps you identify information about where the application is failing. You could also use an alert here, but that’s slightly less elegant.

  • + Share This
  • 🔖 Save To Your Account