Posts Tagged blackberry

Getting started with Weinre mobile debugging on Windows

Weinre (WEb INspector REmote) is a debugger for webpages that is designed to work remotely. This is especially helpful for debugging web pages that are running on mobile devices.

We are going to need several things to get weinre up and running. First we are going to install node.js, which will host the weinre webserver; next, we will install the node package manager (npm); then, finally we will install weinre.

Getting node.js

The easiest way to get node.js is to go to and download the windows installer (This has the added benefit of automatically installing npm. However, I preferred to skip the installer and get just the latest executable from the download site here: node.exe.


Getting npm

If you used the installer to get node.js, npm is already in node.js’s installation directory. Otherwise, head over to and grab the most recent version ( at time of writing. After downloading the file, unzip it to the same directory that contains the node.js executable.

Getting weinre

Next, open a command prompt and navigate to the directory that holds the node and npm executables. At this point, you have two options, you can use the weinre binary thats deployed on by issuing:

npm install weinre

Or you can provide a full url. Since, at time of writing, there are no official builds for weinre on the Apache mirrors, I would recommend just using the npmjs binaries as their location will not change as the transition to the incubator project continues. If you do want to specify a full url for installing weinre, you can get the up-to-date binary package locations from here.


Now that weinre is installed, you can run it by opening a command window to your node.js executable directory and running:

node.exe node_modules\weinre\weinre --boundHost -all-

This will start a new weinre instance at http://localhost:8080, and it will listen on all your computers interfaces, which will allow remote clients (the mobile device) to connect to the server.

If a Windows firewall dialog pops up, you should grant access to node.js. Once weinre starts up, it should display a message such as:

2012-07-20T00:39:40.998Z weinre: starting server at http://localhost:8080

In the console.

Enabling weinre on the mobile device

After weinre starts, navigate to http://localhost:8080 in a WebKit-based browser (Such as Google Chrome). You will be presented with a dashboard showing access points and target scripts.

One gotcha is if you go to http://localhost:8080, the target script is going to display a localhost IP for the script file. This won’t work if we are debugging on a mobile device – we need to use the IP of the computer’s interface that connects it to the network. This can be determined by running the ipconfig command in a console.

For example:

Windows IP Configuration
Ethernet adapter Local Area Connection 2:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
Ethernet adapter Local Area Connection:
   Connection-specific DNS Suffix  . : 
   Link-local IPv6 Address . . . . . : fe80::20cf:d407:7d2b:f8eb%10
   IPv4 Address. . . . . . . . . . . :
   Subnet Mask . . . . . . . . . . . :
   Default Gateway . . . . . . . . . :

By navigating to my IPv4 address (, I can be sure that the mobile devices on my network will be able to access the weinre server.

To enable the mobile device to connect to the weinre server, you must add the target script to the code of the webpage. I’m developing using PhoneGap, so I simply pasted the target script into the header of my index.html file, and rebuilt my application.

Debugging with weinre

After building and deploying the updated app to my device, I simply run it on the device, and navigate to the client access point (eg: Notice the url fragment anonymous. This must match on both the target script and on the client access point, as it provides a way to have multiple debug sessions, and to keep others from discovering your debug sessions if they are on the same network. More information can be found on the MultiUser page of the weinre site.

Debugging in Blackberry Webworks

Webworks doesn’t like the local weinre server – it’s expecting a publicly routable address. You can either open the appropriate ports on your router to let external devices access your winre instance, or you can use the public phonegap instance at

, , , , ,


Remote Debugging With Firebug and Cometd

While experimenting with mobile development on the Blackberry Webworks Platform I found that it was extremely difficult to get any debugging information out of the device simulator to help debug javascript errors.

The Webworks Eclipsed-based IDE does provide limited debugging support; however, I found the OS5 device support for javascript to be extremely lacking (Especially while using the Dojo library) and Webworks is currently unable to debug OS6 devices.

At a bare minimum I wanted my familiar firebug console.* calls to show up somewhere I would be able to see them. Although this is far short of a full remote debugging solution (such as the Firebug Crossfire Project), it would at least allow me to see what is going on under the hood.

Implementation Overview:

  1. A Small javascript file is included on the mobile page. This file adds additional console methods and, optionally replaces the default console.* debugging methods
  2. A CometD provides communication between the mobile page and the page that firebug is listening on
  3. A special listening page is setup where the debugging events coming over the cometd server are passed onto firebug


For my development environment I am using Eclipse 3.6 with the Maven tooling installed. Maven is used so the CometD API can be easily utilized. For more information about building CometD applications with Maven please see the CometD Primer. Maven is also nice as it will download the required dependencies (such as the Jetty Server).

Getting & Compiling the Source

  1. Please clone my GitHub Repository to obtain the source code. This can be found at
  2. Import the project into eclipse
    1. When you are cloning the repo it is most convenient to clone it into your eclipse workspace directory, this makes importing into eclipse easiest
    2. In Eclipse Choose File -> Import
    3. Scroll down and roll open the Maven import source
    4. Choose Existing Maven Projects
    5. Locate the cloned repository & Select the pom.xml file for import
  3. Maven will now download dependencies and attempt to build your project. This may take time so be patient

At this point, you should have a built remote-console project in your Eclipse workspace. You will find that there are two separate source directories: One contains the java source and the other contains HTML & Javascript.

The java source folder is uneciting: it contains the bare-minimum vanilla implementation necessary for the CometD server to pass messages between the mobile device and the firebug page.

The HTML / Javascript source folder contains some example pages + the remote-console.js file which, together, provide the remote-debugging functionality.

Running the Server

To run the Jetty server for the first time:

  1. Create a new Maven Build Run-Configuration
    1. Can be done by right clicking on the remote-console project and choosing Run As -> Run Configurations or by rolling out the run icon
    2. Ensure the base directory is set to the correct workspace directory. Mine is ${workspace_loc:/remote-console}
    3. For the Goals text box enter “jetty:run” this will start the jetty server
  2. Start the Jetty server by clicking Run in the configuration dialog
  3. You should see console output in the Eclipse window. Inspect this output to catch potential problems
  4. Visit http://localhost:8080/remote-console/ to view the remote-console application.

Remote Debugging

When you visit the remote-console application link you will be presented with the remote console connection page. This page allows you to connect to a remote console on a specific channel and have the debug messages appear in a firebug window.

There are two types of demo pages. The default one uses dojox.json.ref to serialize objects. This allows for the serialization of javascript objects that have circular references. The second demo page serializes objects using the default json serialization – be careful with those circular references with this one.

To Use remote debugging for the first time:

  1. Start the firebug listener:
    1. Visit the Remote console connection page with firefox
    2. Open The firebug console
    3. Click the connect button to connect to the default local cometd server
    4. You should start seeing the long-polling entries appearing in the firebug console
  2. Visit one of the demo pages, either in a new firefox window, or using another browser
    1. Use the console.log textbox and button to send a console.log message to your listening firebug console.
    2. You should see the logged textbox contents appear almost immediately in the firebug console log
  3. Next steps:
    1. On one of the demo pages, try a more complex debug expression, such as
      console.log("test", {foo: "bar"});
    2. You should see the message and object quickly appear in your listening firebug console.
      If you are using the dojox.json serialization you may see additional fields on the object when it is displayed in the firebug console.

Adding remote debugging to your own pages is as easy as adding the dojo library and the remote-console script tag to the page you wish to debug.

<script src="" type="text/javascript"></script>
<script src="remote-console.js" data-server="" data-channel="demo" data-json-ref="true"></script>

Ensure that the src path is set correctly to point to the remote-console.js on the jetty server. Likewise the data-server attribute should point to the server and path running the jetty cometd implementation. Pay attention to the loopback device IP and be sure to change it if you are planning on debugging on another device.

There are several parameters that you are able to pass to the remote-console.js script via HTML attributes. Please view the ReadMe in the Git Repo or the source code for a complete list.

, , , ,

No Comments

WebWorks Resource Name Not Valid Workaround

I’ve been looking at using Phonegap and Dojo for rapid application development on mobile devices. As I have been doing blackberry development for the past year or so I thought that this would be a good platform to start on. However, I almost immediately ran into a problem with the WebWorks packager.

The problem is that the packager will not permit paths with special characters in them – special characters including the somewhat limiting “_” and “-“. Instead of packaging the files it would return the error Invalid widget archive – resource name is not valid This is especially a problem with dojo and it commonly uses these conventions for stylesheets and js files.

After Googling, I found that this behaviour was by design. It seems that if you pass a file with a dash in it, the RAPC compiler thinks that it is a command line switch.

Fortunately, RIM has recently open sourced the Webworks API. I knew from my experience with bb-ant-tools that you were able to pass a file containing paths to the files to include in the package, thus circumventing the problem with the command line switches.

The packager now successfully packages _bad-path.txt.

To patch your webworks packager, download WebWorksPatched extract it and move the bbwp.jar to your webworks bin folder (Usually C:\Program Files\BlackBerry WebWorks Plug-in Eclipse\plugins\\wcpc\bin).

For the brave of heart, source code is available on GitHub at

, , ,