11-21-2010 02:22 PM - edited 11-21-2010 02:23 PM
I've created a sample build.xml that's available here:
I have tested it out on very simple projects on OSX, and the default "deploy" target works. I assume it will work on Linux (I'll test it out on my Ubuntu box as soon as I get the BB SDK there). I don't have a Windows box, so can't say what will happen there. At the very least, the amxmlc, bbpack, bbdeploy and fdb variables will have to be changed.
12-29-2010 12:42 AM - edited 12-30-2010 12:41 AM
@Tjitte, and any others who have been unable to connect to the commandline debugger after following the forum articles - I just wanted to post some observations from an entirely too long session of tracking down problems, in hopes of saving someone else some time.
First, if you create a debuggable .swf and package it into a .bar file with the commandline tools, and can't connect to it with fdb, make sure it was really created as a debuggable .bar:
Copy your .bar file to new name, rename as a .zip file, unzip it, and check the <unzipped bar file>/META-INF/MANIFEST.MF file. It apparently should have a line that says:
and NOT a line that says:
My experience was that I followed the knowledgebase article at
verbatim a few weeks ago, and for some reason was not able to connect the debugger.
Instead of launching the debuggable app with the recommended blackberry-airpackager commandline from that article, I instead had to do something like this:
blackberry-deploy -installApp -launchApp -debugHost 192.168.1.101 -devmode -device 192.168.32.128 -package HelloWorld.bar
I didn't have time to dig into the reasons at the time.
Coming back to the debug task this week, I found that what had worked a few weeks ago (and btw all of this was with the same BB SDK, 0.9.1) didn't work anymore, and I chalked it up to my taking bad notes on what I had done at the time.
This time, following the knowledgebase article verbatim worked for connecting to the debugger. However, I want to have more granular build targets in my build flow, so I tried to generate a debuggable .bar file without installing/launching/connecting the debugger at .bar build time.
I tried several seemingly rational variations of blackberry-airpackager commands, such as e.g.
blackberry-airpackager -target bar-debug -package HelloWorld.bar HelloWorld-app.xml HelloWorld.swf
but none of them produced a .bar with an "AirDebug" manifest file entry that could be then launched with blackberry-deploy and connected to with fdb.
As a wild guess I added in the -connect option for the .bar file build command, and that seemed to do the trick, e.g.:
blackberry-airpackager -target bar-debug -connect 192.168.1.104 -package HelloWorld.bar HelloWorld-app.xml HelloWorld.swf
produces a manifest file with "AirDebug", where leaving out -connect produces a manifest file with "Air".
This seems like a bug to me.
By the way, any old IP address such as 127.0.0.1 seems to work for the -connect option, so it looks like I don't have to dynamically find my IP address at .bar build time just to build a .bar for later install/launch/debug.
RIM, if you're watching these forums, can you look into this apparent SDK bug with blackberry-airpackager and/or clarify why it works this way?
12-29-2010 12:19 PM
Thanks for the detailed analysis.
I had given up on using "fdb", but on reading your post I thought I'd check whether what I'd been doing was somehow wrong.
I've been using a Python script to control the compilation/deployment process. It's simple, just supports a few of the most useful options (e.g. "-d/--debug") and watches the return code from invoking amxmlc, blackberry-airpackager, and blackberry-deploy so it knows whether to early-abort the compile/package/install sequence.
In this I'd been using the "-compiler.debug" option on amxmlc, and "-debug -connect X.X.X.X" on the airpackager call, and the deploy call was generic with just -installApp -launchApp -device and -package options with appropriate values. I just checked and my manifest.mf file has the Qnx/AirDebug entry point, and therefore always has (since I haven't touched my build script).
This never worked on with fdb. The app would pause on startup to connect, and fdb never saw the connection. So I wrote my own primitive pyfdb.py program just so I could see trace output.
After reading your post, I tried again. Ran fdb and typed "run" as I'd tried many times before. Built one of my experimental apps with debug options as noted above and waited for it to deploy.
Lo and behold, it worked! I have not changed the sequence one iota from what I've done before.
The only possible conclusion I can reach is that using "fdb" is unreliable. Maybe it works sometimes, maybe it doesn't. Maybe once it doesn't work, it won't work again until you do something like maybe reboot. Maybe it will work only once in ten times. I have no idea yet.
I'll start trying it out a bit more, since my pyfdb.py program didn't seem to let timers run properly, and maybe I'll narrow the problem with fdb down a bit more, whatever it is.
Anyway, it appears that if someone thinks he has "figured out" fdb, whether it worked for him or not, it may well be one of those cases where the magic incantation finally settled on is not completely necessary. For example, your "-devmode" option certainly isn't mandatory as I didn't use it.
Very odd, but somewhat hopeful.... I guess the book isn't closed on fdb yet after all.
12-29-2010 01:48 PM
I have a really big issue...Well it may not be really big, but its urgent.
I've successfully made a build with the following command:
blackberry-airpackager -package C:\Blackberry_Tablet_OS_Development\src\ShortenThi
s.bar -installApp -launchApp C:\Blackberry_Tablet_OS_Development\src\ShortenThi s-app.xml C:\Blackberry_Tablet_OS_Development\src\ShortenThi s.swf C:\Blackberry_Tablet_OS_Development\src\blackberry -tablet-icon.png -device 192.168.174.128 -password password1
...And now once it launches in the simulator, the icon is only the default icon, and when I open the app it shows the "Your application is loading" screen, then that dissapears and the home screen re-appears...
12-29-2010 01:59 PM
Couple of things that might help (and questions)
1) There is a parameter in blackberry-airpackager that defines the root path for the other parameters to help simplify the command (believe it is -C).
2) Not certain why all the content you are referencing is in /src and not /bin-debug, especially the app.xml file and .swf file. Maybe not a big deal if that is how you setup your project, but can be dangerous when cleaning the project.
3) Should not need -password since that is not enforced yet.
1) How is the icon defined (blackberry config file or application config file [icon72])?
2) Does the app work as an AIR application?
3) Does a simple application (liek helloworld) install and run OK?
12-29-2010 02:04 PM
Hey! Thanks for the help, I did some re-arranging, and little fixes etc ...
So I made sure everything was in PATH, renamed things, added another image to the command (which I was missing the first time-maybe the cause of the no-show?), and I moved the CMD to the directory where the app is, and then everything worked perfectly!
12-31-2010 05:52 PM
I had to switch over to using the -connect param when I'm only just building the BAR file as stated above to get the AirDebug as the entry point. I also had to switch over to using blackberry-deploy to get fdb to connect at all. Here are the build commands I use incase it might help someone else:
Building AS to SWF:
amxmlc -output AIRHelloWorld.swf -compiler.debug /workspace/AIRHelloWorld/target/classes/AIRHelloWo
Building SWF to BAR:
blackberry-airpackager -connect 192.168.5.232 -package AIRHelloWorld.bar AIRHelloWorld.xml AIRHelloWorld.swf blackberry-tablet-icon.png
Installing to the simulator:
blackberry-airpackager AIRHelloWorld.bar -installApp -device fusion -password <password>
blackberry-deploy -package AIRHelloWorld.bar -launchApp -connect 192.168.5.232 -device fusion -password <password>
I later changed my installing command to use blackberry-deploy, however it worked with blackberry-airpackager just the same:
blackberry-deploy -package AIRHelloWorld.bar -installApp -device fusion -password <password>
01-01-2011 09:26 AM
I already used the -connect parameter so the Entry-Point-Type was Qnx/AirDebug.
I followed the methodes in the previous messages but I'm still not able to connect to fdb. although there is some progress. I now see some more information in the cmd window.
I use an other methode to debug my app. When there is somthing wrong in the app, it displays a dialog with information about the error along with the source file and the line number.