This article is primarily directed at BlackBerry® WebWorks™ developers who have written extensions in Adobe® AIR® and would like to be able to use the free Adobe debugging tool to debug them.
For this example I will be using two custom pieces. First off we will be using my fork of @rem’s JSConsole because it is a simple WebWorks tool that will let us access the WebWorks APIs to demonstrate them. Second we are going to use my systemlog API for WebWorks because it contains the ability for WebWorks Applications to write trace statements which show up in the FDB debugger.
Everyone has used the -d option with WebWorks to bring up our old friend the Web Inspector™, but I will touch on this first.
This of course leads to one of the things that makes developing web apps for the BlackBerry® PlayBook™/ BlackBerry® 10 so much simpler than most other mobile platforms. The first time I showed some friends who were developing for other tablets the Web Inspector, they nearly flipped out.
Because I had written the extension I spoke of earlier, I had actually written some logic where I was sending trace() calls out to the debugger. However, since I had added the technology only to match the behavior of the handheld extension, I had not tested it yet.
When I presented at BlackBerry DevCon Asia on the topic back in the fall, I glossed over the fact that I was unsure how to effectively debug a running WebWorks App on the Adobe® ActionScript® Level. I in fact said, when you build with -s you should be able to open the resulting source in Adobe® Flash Builder® and it should all “Just Work.” I then added that I did not personally have a copy of Flash Builder and so I was unsure.
With a desire to actually have my extension merged in, I wanted to actually verify that it was correctly logging things. I started off here:
It's a useful KB Article about how to build using the command line tools which are freely available for debugging PlayBook applications. The real key take away on that is that you need to do two things:
Call amxmlc -compiler.debug <bla.ax>
Normally you just call without the flag.
Once you have an SWF file, call blackberry-airpackager -target bar-debug -connect [YOUR COMPUTER'S IP ADDRESS]
I will refer back to this article later, because it also describes how to connect the debugger to a running application; but let's leave that for later.
Armed with this information I decided the next course of action would be to look at the WebWorks packager and see what could be done to manipulate it to build the way I wanted.
This meant finalizing my process of installing Maven and getting building up and running for BBWP. The instructions here are fairly detailed and functional. Once I had successfully built the BBWP tooling from GitHub®, I opened it up in Eclipse™. Which worked like a charm by making a project in the root level and importing the existing project of “packager”.
This is where I started looking around at how the code worked and that is where I discovered something special.
It seems that someone at BlackBerry wanted there to have the ability to do this.
Looking closely at the code I realized that you could change the “TARGET” to “bar-debug” by setting what was referred to as an “debugModeInternal”.
Now that I knew that it had already been done, I just needed to go and figure out how to send us down that code path.
Thankfully because WebWorks is all open source I was able to track down the command line parsing code to discover this gem.
What amazed me the most about this was it is actually in shipped versions of the WebWorks packager, at least in BBWP version 126.96.36.199. So we can simply append this option to our build and we wind up with a build we can attach the debugger to.
The resulting BAR file can be loaded onto the PlayBook simulator and we wind up with a result that looks like this on launch :
From here we need to follow the second set of instructions from the KB Article.
We need to:
Open a new command line window and run fdb.exe.
Once the program starts enter run.
Return to the simulator.
In the simulator window enter the IP address of your computer, that you are assigned by VMware®. Under IP Config it is listed as VMnet8. For my machine it is 192.168.159.1.
Press OK and alt tab back to the other command line window running fdb.
If all you care about is trace statements enter continue at the prompt. If you are more interested in complicated debugging you will have to learn how to use fdb.
You will then see trace statements as your applications progresses.