Debugging a BlackBerry application can be done on a simulator, when the bug permits that sort of thing, or on the device itself. If you’re in a situation where you must debug your code while it runs on a real device, your can sometimes take advantage of the tethering debugger provided by the JDE; connecting the device to the PC via a USB cable, and then hoping everything is stable enough for you to catch a breakpoint and find your bug.
This is all fine and good, but there are times when you find yourself in a situation where neither of these techniques gives good results.
At Antair, during development of our BlackBerry applications, we often include a debug console in the dev builds of our apps.
With the debug console, all debug output hits the output screen when the dev build is running in the simulator, and when the dev build runs on a physical test device, the debug output is automatically persisted and is available to view on a dedicated screen that can be pulled up via a menu option or button.
The code below is a stripped-down version of the debug console we use at our company.
Using the console is easy. Include the code in your project, fill out the PERSISTENCE_GUID for your application, set the TAGID string to identify your application name in the debug logs, and when you want to output a debug statement, simply call Debug.print(“Something happened here…“);
Each line of the debug output, both in the output window when running in a simulator, and in the debug console screen when viewed on a device, will contain your debug message, the thread number on which the call was made (useful for thread/ui debugging), and the date/time of the log statement, with a millisecond timestamp for performance profiling.
To view the debug console on a real device, simple put in a call to pushScreen(new AntairLogScreen()). The screen has a built-in menu item to clear the persisted log messages, and will dismiss itself like a regular application screen.
If you’re running the RIM compiler preprocessor to switch between development, QA, and production builds, you can simply put in a call to set Debug.ENABLED = false for everything but the development builds, and the debug console will be there when you need to debug and go away quietly when you don’t need it.
The code is available on GitHub.