trace()
Perhaps the most common logging approach is to use Flex's global trace() function. This is extremely easy to invoke from the code because
trace() is a globally available function and so does not require any imports or explicit inclusion. It also is simple to use because it is designed to be simple rather than sophisticated and the lack of options for logging keep it simple. Finally, its simplicity is enhanced by the implicit conversion of non-String datatypes passed to it to Strings via the non-String objects' toString() methods.While trace()'s key advantage is its simplicity, it has some significant limitations. First and foremost among trace()'s disadvantages is that it requires a debug Flash player to be used so that communication can take place between the browser hosting the application back with the server. On top of that, the Flex code must be compiled with the debug option turned on (-debug=true) and trace()'s default output behavior is to write log messages to the console in which the command-line debugger (fdb) is being run (if not using FlexBuilder).
Per Olesen's blog entry Flex Trace and Logging discusses how to route Flex trace() output to a file or to the FlashTracer Firefox plug-in. Note that because all of these are trace-based, they all require a Flash Debug player.
Alert.show
Like trace(), this is an easy way to go and that is its biggest advantage. Unlike trace, an import (of mx.controls.Alert) is required to use Alert.show. The much bigger disadvantage of this approach is that the message is output on the client side and can become very irritating, especially if there is heavy debugging or logged messages within loops.
Alert.show() feels very similar to JavaScript's alert() function, but there is one significant difference. While JavaScript's alert() stops JavaScript execution until the user clicks on a button, Flash continues to process its main code execution instead of waiting on user response. Despite Alert.show()'s several disadvantages, there are times when it may be a first choice for quick and dirty (and temporary) logging. This is because it does not require a debug player to be running in the browser. In fact, it does not require the Flex code to be compiled with debug turned on and does not require the debugger to be running on the server.Flex's mx.logging Framework
A primary strength of both the trace() approach and the Alert.show() approach is the simplicity of using each approach. However, trace() depends on a debug player being installed and this is not likely to be the case in production. Alert.show() provides its output to the person using the web browser and logging is normally desired by the developers. Like trace(), therefore, the Alert.show() approach for logging and debugging seems suited only for development environments and not for production. (Of course, Alert.show() can still be used for user interactivity in production).
Flex provides the mx.logging package as a means to have greater sophistication and flexibility in logging. It can be used without the limitations of trace() and Alert.show() and makes an ideal production-time logging framework. This is especially true when used in conjunction with a server-side service (such as a web service or HTTP service). Per Oelsen describes this in his blog entry Sending Logs to the Server Using Custom LogTarget in Flex.
Using the mx.logging package requires more effort than using trace() or Alert.show(), but the effort is very reasonable and yields many benefits at a relatively low cost. The logging framework is built primarily upon the concepts of loggers and targets. Flex developers can customize loggers by implementing the mx.logging.ILogger interface. Likewise, the mx.logging.ILoggingTarget interface is implemented for any custom targets. The mx.logging.targets.LineFormattedTarget class inherits from a class that implements this ILoggingTarget interface and is commonly the class overridden by developers to create their own custom targets. There are a few tricks to doing this and I recommend reading Per Oelsen's blog entry cited earlier regarding trace() for coverage of this as well.
Once you have your own custom classes created and have a service on the server side to accept logging from the client, many of the limitations of trace() and Alert.show() are no longer present. There is more work initially to set this up, but using the framework once it is in place is not much more difficult than using trace() or Alert.show() and provides significantly more flexibility.
Resources and References
There are many good blogs and other resources on using various Flex logging mechanisms. Here is a small sample of some of them:
No comments:
Post a Comment