Seeing the JavaScript console when writing PhoneGap applications in Eclipse

Recently I’ve been doing some work with writing PhoneGap/Dojo Mobile applications for Android, using Eclipse as the IDE. These work just fine with the Android emulator, but it took me a while to find where I could see the output of the JavaScript console. To show it, select Window -> Show View -> Other… in Eclipse. Then select the LogCat view (under the Android section). This will show all log messages for the emulator, but it can be further filtered to show only errors from the JavaScript console. Simply click on the green cross to add a Filter, then give the filter a name and enter “Web Console” for the Log Tag. Click OK and you’ll see only errors related to the browser (including JavaScript errors).

Constructing a Lightweight Generic Function Trace Mechanism for Javascript

(I’ve brought together the ideas for this concept from various places – thanks to this answer on Stack Overflow and in turn this page for information about arguments.callee).

Oftentimes, when you’re constructing a complex Javascript application, it can be very useful to add tracing to it so that you can track the execution flow – when methods are called, and with which arguments. This is especially important when trying to debug later on. The Javascript arguments array can be used to help do this. However, the arguments array isn’t a real array – it has some quirks. I’ve spent some time experimenting, and I’ve come up with a generic tracing function that you can use. Crucially, the line to invoke it is just copy and paste, no modification is needed. This means you can easily paste it throughout your code without tiresome pasting in of function names or arguments.

The generic trace function looks like this:

function trace(argumentsArray, calleeItem) {
    var functionName = calleeItem.match(/function\s+(\w+)\s*\(/)[1];
    console.debug("Entered function " + functionName + " with arguments", argumentsArray);

You can use it simply by inserting the following line into the header of each function you write:

trace(, arguments.callee.toString());

That line looks complex, but it does not need to be modified for each function you write. The first parameter copies the arguments array into a real, mutable array that can be passed into the trace function. The second takes the callee (i.e. the function being traced) and passes it into the trace function (which then strips off the function prefix).

For example, you might write some code like this:

function sayHello(firstname, surname) {
    trace(, arguments.callee.toString());"Hello, " + firstname + " " + surname + "!");

sayHello("John", "Smith");

That would produce output in your console that looks like:

Entered function sayHello with arguments ["John", "Smith"]
Hello, John Smith!

Any suggestions for improvements to this idea gladly welcomed!

“use strict” support coming in Firefox 4

One of the bugbears in JavaScript until recently has been that there’s no support to check for undeclared variables explicitly and call them out at interpret time. This can make it somewhat easy to slip up and mis-type an identifier. However, obviously borrowing from Perl, support for a use strict pragma is coming in ECMAScript 5.

What does this mean in practice? Well, I tried a few tests with this quick script I whipped up (the use of Dojo was optional, of course, but I just love using it as a framework):

        <div id="showMe">
    <script type="text/javascript" src="" djConfig="parseOnLoad: true"/></script>
	"use strict";

        dojo.addOnLoad(function() {
		dojo.byId("showMe").innerHTML = "Test passed - use strict works!";
		invalidVariable = 3;
		dojo.byId("showMe").innerHTML = "Test failed - use strict doesn't work!";

The test fails in Chromium 7.0.517.44 and Firefox 3.6.2. However, in the latest Firefox 4 beta 8, it passes – and Firebug very clearly shows the error that’s thrown:

This is great news, and means that you’ll soon be able to start using this pragma as it finds its way into the latest browsers. It’s probably unwise to start including it now – unless you plan to test all your code on a browser that supports it – because of the risk of undetected side effects (for example, a mis-typed variable that also happens to be dead code). But when, for example, Firefox 4 is released, it will hopefully become a standard best practice for web development.