7

I'm looking for the fastest, most efficient way to debug my java application for BlackBerry.

I noticed that it takes forever just to attach the debugger to the device, using a Torch 9800 in my case. Do I have to attach it every single time I make a change to my code, or is there a better way?

I also noticed that in the console, the device seems to be printing a LOT of stuff I don't really care about. Sifting through all this can really be a pain. Is there a way to see only stuff relevant to my application in the console, specifically only things I myself print to it?

Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
PaulG
  • 6,920
  • 12
  • 54
  • 98

2 Answers2

8

  1. Eclipse debugger and profiler, in most cases - the best solution, but in some cases it does not help to find out what is the problem source.

  2. Writing to internal device log via EventLogger class. As an option, if there's a huge amount of data - external text file, located on the device media card (not internal device filesystem).

  3. Using console output window. Unfortunately there's no way to apply a filter on the console output, but there's a way to make work with console easier. Add sequence of symbols at the start of debug messages to distinguish your debug printouts from the system ones. For instance

    System.out.println("!!!!!!!!!!!!!!!!!!!!!!! myVar value = " + myVar);

Or that way:

System.out.println("#############################################");
System.out.println("############# object1: " + object1);
System.out.println("############# object2: " + object2);
System.out.println("############# object3: " + object3);
System.out.println("#############################################");

When there's a big amount of debug data in console just copy all console text to a text editor, like Notepad++ and work with it there.

  • 1
    Thanks. I've already started placing a bunch of symbols in front of my printouts. It helps for sure, but it's still awful that we can't filter. I do Android development using Eclipse as well but I have this option, very useful. – PaulG Mar 28 '12 at 13:26
  • About point #3, I use to do the same also. It is convenient to grep the whole log and get only your output (if you have a linux VM at hand). Unfortunately sometimes system messages get mixed with your own output lines, mostly when these are long. – Mister Smith Mar 28 '12 at 13:36
5

Yes, debugger on most modern simulators takes forever to attach. The newer the simulator, the more time it takes. What I usually do is:

  • Try to do the heavy debugging in the older simulator possible (often 83xx).
  • If not possible, launch the simulator and don't close it. This hot swap functionality is available only for 5.0 onwards in eclipse BlackBerry plugin.
  • Thanks to the hot swap you can launch the simulator (with run configuration) and then push the debug button. It is much faster than launching debug from the beginning.
  • When working with older versions of eclipse plugin where hot swap is not available, or coding for OS < 5.0, launch simulator from eclipse with run, then open RIM JDE (yes, that old-fashioned RIM-made Java IDE) and attach debugger from there (Debug menu -> Attach to -> simulator). You cannot stop in breakpoints, but you can see the text output. JDE does not come with eclipse plugin, you should download and install it independently.
Mister Smith
  • 27,417
  • 21
  • 110
  • 193
  • 1
    Thanks for the reply, I've given up debugging on the simulators and have been debugging exclusively on my device (Torch 9800). I find the simulators don't "always" act realistically. – PaulG Mar 28 '12 at 13:22
  • Then I suggest you to use JDE to attach to real device and see the output in real time, rather than having to open the event log. Also this way you can see `System.out.println` and not only log entries. Old eclipse plugins allowed to do this just pushing debug, but newer plugin versions reinstall the application each time, so it is slower than using JDE. – Mister Smith Mar 28 '12 at 13:26