BB10: Debugging


Debugging a BlackBerry 10 application is a bit primitive. I want to jot down my notes on how I've been debugging my applications so I can refer back to them later.

References:

Overview

While BlackBerry provides a debugger with the QNX Momentics IDE, it is a bit limited in what it can do. As my day job consists of writing code in a Microsoft shop I can easily see the differences between Momentics and Visual Studio. Where Visual Studio will let you investigate any managed object at a breakpoint, the Momentics will only give you limited information about objects. You need to supplement your debugging with debug statements. In addition to all this, Javascript/QML Debugging is very primitive (no debugger yet AFAIK).

 

C/C++ Debugging

One of the first things you'll notice about debugging in C/C++ is that there is a hidden breakpoint which gets triggered at the start of every debug session. When I first experienced this at the BlackBerry 10 Hackathon I attended, I wasn't sure what was going on- it looked like the app was hanging someplace and my breakpoint hadn't been hit. Just hit the 'Continue' button (May need to do this twice) and program execution will resume.

Once your breakpoint has hit, there is a Variables window which will show you what is in-scope and inspectable. If you want to debug objects like QVariants, Lists and other non-basic types you'll need to implement qDebug() statements that look something like this:

qDebug() << “something coming” << QVariantBlah;

Unfortunately, adding qDebug() lines requires you to rebuild and restart your debugging session. It can be hard to know exactly where to put qDebug() lines so I tend to add them only when there is something I specifically want to track during debugging or when something fails.

Now for the fun part: In order to see the deconstructed object using qDebug, you need to open an SSH Connection to your BB10 device and view the console / debug log. While the Momentics IDE makes this easy, it is still a hassle to have to go to another screen and view debug message output that your debugger can't decode automatically. :/

Note: As viewing a debug log via SSH is also required for JavaScript / QML Debugging, I've broken out the section on how to set this up. See the bottom of the page for details.

 

JavaScript / QML Debugging

JavaScript debugging is more primitive than C++ debugging. At least with C++ you can set a breakpoint, even if you can't always decode the data in the local variables directly. with JavaScript you are entirely at the mercy of the device debug log.

While JavaScript exceptions will automatically be written to the log for you to analyze, you'll need to write in your own debug statements to troubleshoot unexpected JavaScript behavior.You can use console.log() to write to the log file:

console.log(someJavaScriptObject);

Once you've sprinkled logging statements through your code it can be a hassle to go through and remove them when you ship. Adding some conditional log logic is helpful.

Now that you're logging, you can open the device debug log via SSH and try to figure out what's going on (see next section below)

 

Get access to Device Debug Log

Now for the fun part: Analyzing the data you've collected. Here's how you can do that:

  • Go to the QNX System Information Perpsective
    SystemInformationButton.png 
      
  • Launch an SSH session to the device
    LaunchSshSessionToPhone.png
  • If this is the first time you've launched an SSH Session to your device, you'll see a scary message telling you that the remote host identification has changed and that it is possible that someone is doing something nasty and that someone could be eavesdropping on you right now (man in the middle attack)
    NastySshMessage.png
    Go ahead and click Yes if you're sure you want to connect to your device. :)
  • Now you'll be in the Terminal tab. Go ahead and run slog2info -w:
    LoggerCommandToRun.png
  • The slog2info command will provide you with the application debug log. The log entries will be helpful in debugging your applications.

 

Note: Something that works for me is to keep slog2info running while testing my apps. As C/C++ debug mode is only useful some of the time, I tend to avoid it and just use logging messages.