Introducing the Console class and debug package
I realized I need a more…official…way of debugging my apps, so I wrote the Console class. It’s primary function is to record activity to a specified log file. So far, I have a few methods that write entries—success, error, cancel, and print. I definitely plan to add more, but these are the main ones I intend to use in the near future. Since the name “trace” is off limits in AS3, I referenced my PHP background and named the trace method, “print”.
The class also includes the ability to automatically trace entries to Eclipse’s console along with writing them to a file. Files are written asynchronously, but I also added a delay property that combines entries, so the writing process is less likely to slow down the app. Taking advantage of AIR 2.0’s UncaughtErrors feature, the Console automatically logs fatal errors and their stack traces, if possible. Here’s an example of its usage:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | var path:String = File.applicationStorageDirectory.nativePath; // params: log file path, LoaderInfo // automatically writes a session start entry to the log Console.init(path, loaderInfo); Console.delay = 1000; Console.traceError = true; // params: id, message Console.success("wp post", "wrote blog post"); // params: id, message Console.error("wp post", "previous post was depressing"); // params: id, message Console.cancel("Christmas", "why would you want to do that?"); // params: message Console.print("this is a test"); |
[Fri Dec 18 00:31:31 GMT-0500 2009] Session Start [Fri Dec 18 00:31:31 GMT-0500 2009] [success] [wp post] wrote blog post [Fri Dec 18 00:31:31 GMT-0500 2009] [error] [wp post] previous post was depressing [Fri Dec 18 00:31:31 GMT-0500 2009] [cancel] [Christmas] why would you want to do that? [Fri Dec 18 00:31:31 GMT-0500 2009] [print] this is a test
I do expect to build the class over time, eventually adding TextField support. In the meantime, the source code is available on GitHub.
Hi, sorry for your loss. CurrentDate class was a nice idea…
I’ve just read your Console class. Now I wonder if it’s better to close the filestream on each commit than keeping it open while the application is up ?
I wrote a Console-like class last month and i decided to keep the stream open. Just for convenience. It seems to work, but maybe it’s not the better way.
@Rémi — good question. I’ll be sure to look into it. I was under the assumption that a file needed to be closed to complete the write, but maybe I read the documentation wrong. Thanks for letting me know!
@Rémi — I just tested always open vs open when writing and the former is barely faster. Since there’s not much of a difference, keeping it open only when writing with a transaction-based system seems right to me. If anyone else has input, feel free to share.
Ok,
It must depend on the usage. Always open work well for file editing for example.
* like FLA files with Flash or DOC with Word…