By Tehdog (Own work) [CC0], via Wikimedia Commons (Mute_Icon.svg, Speaker Icon.svg)

Some of you may have noticed that the Beta 3 release of the BlackBerry® 10 Native SDK got a bit quieter in the console when creating Cascades™ applications. As of Qt 4.8.3, all output that used to code to the console (qDebug(), qWarning(), qCritical() etc) is now output to slog2. This not only affects the logging from C++ but also any console.log() JavaScript logging done from within QML as well as error messages at runtime. No console output can make troubleshooting even simple issues very frustrating. Luckily there are a few workarounds detailed in the “Known limitations” section of the release notes that can get you access to the logging information.

1) This workaround gets you the logging information back to the console, but should be removed prior to publishing your application to the BlackBerry App World™ storefront. Either of the following can be done:

a. Use the fprintf() function with stdout or stderr as the output stream to receive output directly to the console. This is easy to do to add in-line console output from C++, but will not restore logging to the console from QML.
ex fprintf(stdout, “I am a console message\n”);

b. Register your own message handler with the application to have all qDebug() (etc) and QML output handled however you wish (including using fprintf() as mentioned above). To do this, open your main.cpp file (the default main file for a Cascades application) and add a function similar to the following above the main method:

void myMessageOutput(QtMsgType type, const char* msg){
               fprintf(stdout, "%s\n", msg);
               fflush(stdout);
}

Then in the main method we need to register the above method as a message handler:

int main(int argc, char **argv)
{
    Application app(argc, argv);
    qInstallMsgHandler(myMessageOutput);
    ...
}

After this is done you will once again have console output!

2) To see debug information that is output from qDebug(), you can access the slogger2 logs as follows:

In the IDE, in the Target Navigator view, right-click the device target. Click Launch SSH Session.

In the terminal that appears, do one of the following:

• To view the current slogger2 logs, type slog2info.
• To view real-time output for the processes that are being debugged (for applications that are running in development mode), type slog2info -w.
• To view help information on slogger2, type slog2info -h.

You can also access the log files directly in the /tmp/slogger22 on the device and run these logs through slog2info at a later time.

This works well to retrieve all logs, but has a bit more overhead than option 1b) and also does not allow you to see the logs in the console.

Now you have a few options to get access to the application logs, which can be used in the interim until a solution comes in a future NDK release and the above workarounds are no longer needed.

The workarounds mentioned above are also covered in the following places:

• Cascades Beta 3 – Release Notes
• Upgrading to Beta 3 – QNX Momentics IDE changes
• Getting Started – Debugging and profiling

COM26 – Logging: The Easy, Flexible Way
Logging is a powerful instrument to find bugs and understand why an application is under-performing or why something went wrong.

Ekkehard Gentz, Software Architect with ekkes-corner

Register for BlackBerry DevCon Americas now!

In an industry full of young up-and-comers, Ekkehard (Ekke) Gentz stands out for his 30 years of experience and insight in the rapidly changing world of mobile development. In 2010, Ekke realized that he could meet many of his customer’s needs with mobile business applications for BlackBerry® smartphones as part of his enterprise business applications. Using Java® and BlackBerry® 6, Ekke develops client software and server software for small -and medium-sized companies. Ekke is also very involved in the Eclipse community.

Ekke talked to us about why the BlackBerry solution is right for his customers, how BlackBerry 6 and BlackBerry® 7 have led to the design of powerful apps, and how “Super Apps” are a key differentiator.

Why do you recommend the BlackBerry solution to so many of your customers?
I always go as deep as possible into frameworks, platforms, and technologies to find the best mobile solution for my customers, and I’ve found that there are a number of customer requirements that I can only solve using the BlackBerry solution. The combination of integrated native solutions like the BlackBerry Push service, the BlackBerry® Enterprise Server, and GPS functionality have been hugely important to some of my customers. I’m astonished how many times I discover that a customer’s special requirements can only be solved using the BlackBerry solution.

Why do you like working with BlackBerry 6 and BlackBerry 7?
Whenever I speak to Java developers or Eclipse developers, I explain to them that with the BlackBerry OS it’s easy to use your experience to develop really great-looking applications with all of the unique features of BlackBerry smartphones. The Research In Motion® (RIM®) team added more APIs and extended Java Specification Requests (JSRs) to make it easier for Java developers, and the BlackBerry 6 applications are oftentimes much more engaging than similar iOS applications because of its deep integration with the native app. Also, the command framework for Super Apps is designed to be straightforward. It’s a great way to work with applications communicating with each other, and it’s very powerful.

Do you have a specific example of using Super Apps to help optimize business processes?
One example is the location-based services and GPS tracker. SQLite is a database for mobile devices that is designed to allow access from one application at a time. To solve the issue of both apps needing to access the SQLite database at the same time, the background app registers its services as remote commands using the BlackBerry Command Framework API. The foreground apps then use these commands to communicate with the background apps. This works really well and isn’t something that I could do easily with Windows Phone 7, iOS or Android™.

How important is the BlackBerry Java Plug-in for Eclipse?
Using BlackBerry 6 and BlackBerry 7 with the BlackBerry® Java® Plug-in for Eclipse® definitely makes it easier to work with Eclipse, especially for users who are not as familiar with it. I work with it daily and it was the reason why I developed an Eclipse-based OSGi server with Eclipse Jetty. I integrated OsGi services that were using the BlackBerry Push SDK, which made it possible to install both the mobile software and server software — including all of the Push services — in one Eclipse installation. This was much simpler than having to install the normal BlackBerry Push SDK with the J2EE Stack and Spring framework.

How does your logging framework function?
I try to avoid using debuggers unless there are serious problems, because they don’t give you the real behavior of an application. I didn’t want to use a debugger or an event log. In the past I had used an open source logging monitor that was easy to use with applications and allowed me to search for and see debugger warnings. For BlackBerry smartphones, my logging works in the background; it’s a library, and it’s designed to be easy to implement. If I have a foreground application and a background application and my server application pushing content through the BlackBerry smartphone, I can go into this logging monitor and see side-by-side what happens in both apps on the server side.

Thanks for taking the time to talk to us, Ekke! Readers, please take the time to check out Ekke’s website and all the cool projects he’s currently working on.