Logs

#Sources Essentially, there are two types of logs, that are captured and presented inside Visual Studio:

application's standard output (aka console logs),
and slog2 messages.

slog2 is not currently supported for PlayBook.

Fortunately none of them requires application running with debugger actively attached. That's why if you believe debugging is too slow and you know, that the crucial part of your code is wrapped with proper logs, you might simply run it via Visual Studio.

Example:

Log Sample

Usage - console logs

Suggested way of publishing console logs, is to call following code, whenever anything should appear in logs:

fprintf(stdout, message);
fflush(stdout);

If you don't flush the standard output after printing it will be cached and sent from application to the plugin with a delay. For small applications, that produce almost no log it might mean, it will be sent at exit. Message should already contain Window's style line ending.

From the running process perspective, at launch time, the standard output was redirected to a file:

 <app_sandbox>/logs/log

For example: /accounts/1000/appdata/com.codetitans.FallingBlocks.testDev_llingBlocksb07fdb40/logs/log

Target Navigator

##Usage - slog2

Slog2 is a bit more sophisticated logger. Maybe because it monitors everything since last device boot and it guarantees that logs were persistently stored.

Configuration is for sure a bit more complicated. See the docs, but it pays off, when reliable solution is about to be used. By default only some system APIs (like: bsp_initialize()) generate slog2 messages. To print message manually, following line must be called:

slog2c(buffer_handle, 0, SLOG2_INFO, message);

Buffer_handle should be configured and obtained only once, before any logging.

#Settings

Settings

#Limitations

Among the obvious pros of developed logs capturing feature, there are some drawbacks developers should be familiar with. It might save some frustration, in case something is still now working as though under particular conditions.

There is no automatic way to stop loggers unless slog2info is manually killed and console capture is disabled via Target Navigator window.
Since console logger is simple file reader continuously checking, if nothing new appeared, be aware that it doesn't monitor the state of the process, to which the log file belongs. What does it mean?

Monitoring doesn't know, when application finished and never stops pinging for new content
Some 'artifacts' might appear from logger, when application supports running as card and that card is invoked (as effectively in OS it spawns the process again, overwriting the existing log file)

There might be several unexpected slog2info processes running on the device. One process is launched each time connecting to the target device. Although it is impossible to ask the device to kill this process automatically, when something bad happens to Visual Studio or link to the target.