Olog is a free, windowed, light weight logging utility for Flash based web and desktop applications. Stop littering you code with pesky trace statements!
Download ZIP here | Connect with SVN here | Documentation here
(Current version is 1.3.0 Google Project homepage)
It’s not a debugger, a profiler, a command line interface, a competitor to DeMonster Debugger or anything like that. It’s a well featured logging utility that will make you stop using that trace statement. It’s free and also, it’s really, really, really simple to use. Once included in your source path, all you need to get started is this:
It adds 20 KB to your movie and it looks like this:
Useful output
Much of what makes Olog so useful is the way in handles datatypes. In general you are better off passing it raw values rather than trying to format them for reading. That’s because Olog includes a number of internal parsers to help display the most useful information about anything you’ll throw at it. Olog.trace or simply otrace is the powerhouse of the package. It will churn butter for you and output the fat contents if you ask it to, while at the same time trying to limit the amount of information to the most useful bits. If you’re not satisfied, swap it for Olog.describe and you will get everything there is to know about what you feed it.
Metadata
Each line in Olog is prefixed with a line number and a run time stamp by default. The run time stamp shows the time elapsed since the application was launched. This is useful for immediately determining bottlenecks in the performance, because you instantly see how much time has passed between each log message. Run time, clock time and line numbers can be chosen in any combination or disabled altogether. Olog.traceRuntimeInfo will output all the capabilities and properties of the current running environment. This is useful stuff if you’re including the client in testing your app.
Production safe
Olog is designed to be left in when your app goes live. It will not throw any errors of it’s own and it goes to extended lengths not to throw any on your behalf either. If an operation fails internally, it is always gracefully handled in the form of a log message instead of something your end user might discover. It is also very lightweight, and although it’s not recommended for banner ads, the footprint is small enough to make little difference in most apps you could imagine.
Olog can be password protected. It is not on by default so take caution if there is sensitive data in there. It’s as simple as writing Olog.password = “yourpassword”. If Olog is invoked, a password prompt will open and the log will open as soon as the correct password is entered. The Esc key will make it go away. By default Olog can be opened by pressing SHIFT + Enter, or by right clicking and selecting “Open log”. Both can be disabled.
Basic TDD
Test Driven Development is still in probably the slowest incubation phase known to man, but is slowly but surely gaining traction, even in the most disorganized corners of the developer world. Olog will not give FlexUnit a run for it’s money. But 70-80% of unit testing is assertion of an actual value that’s supposed to be equal to an expected value. Olog provides a simple assert method to provide you with the very basics. It produces output like this:
So this is for when you don’t feel the need to classpath that jar, add those swcs, extend those test runners… make that extra launch config…..
Performance testing
Again, there are more holistic solutions out there. But a large part of performance optimization has to do with keeping track of how long something takes to load or execute. Olog.newTimeMarker is designed for this very purpose. You pass it a name and it returns an id. You store this id in a variable, and on the next line after the operation has completed you pass this id to Olog.completeTimeMarker. The name and duration of the operation you timed is displayed in the log window.
Display List debugging
Olog contains a powerful and fast display list crawler. It works by calling Olog.traceDisplayList, and you pass it a root object and the maximum number of levels down you want to inspect. It will output a nicely formatted tree view with a type description and child index of each item. Additionally, you can pass it a property name or function name to be read and appended for each item in encounters. Don’t worry, if the property or function doesn’t exist on any object, it will be ignored. It has been tested to crawl a display list containing 54.000 display objects 16 levels deep in just under 400 milliseconds.
Utility functions
Ever wanted to set a break point without halting execution? Maybe there’s an animation you wanna see complete, but you’re interested in some property values right before it starts. Olog includes several utility functions, among which breakPoint is only one. It will tell you the precise location where it occurred and it will describe any object you pass it.
Actually, breakPoint makes heavy use of another utility function, getCallee, which is available to you as well. It will return a string representation of whatever function called the function you are currently in. Sounds clever? I thought so too! (we’re so alike, you and I…).
There are also nullFunction, which can be assigned to any funciton reference to indicate a yet to be implemented function, and noMethodBodyWarning, which is useful when building abstract classes. They work pretty much the same, but are slightly contextually different.
Ease of use
Olog is a singleton, added to your project with addChild ( Olog.window ). You can write to Olog before adding it to the display list. It will write those messages as soon as it can. Once on the display list, it will remain on top at all times (which can be disabled). It is a window that can be moved, resized, maximized and minimized and it will remember it’s state from launch to launch. This means that if you left Olog open at x:34, y56, width: 405, height 660 before you closed that browser window, Olog will appear the exact same way on the next launch. This can also be turned off of course.
When minimized, Olog will show only it’s title bar (Mac OS 9-style) and it will also show the number of unread messages, colored by the highest severity of all the unread lines. So if it goes orange, you know there’s been a warning.
Keeps track of memory
The total memory in use by Flash Player is always displayed on the top right corner of Olog. In addition you can set a memory limit, say 70 (MB). If memory usage exceeds this limit, the memory used is display in red. God is in the details.
Truncation
Olog.setTruncation enables truncation of long messages and messages that span several lines independently. Any truncated message can later be opened and closed in the log window.
Output
Stuff doesn’t just go into Olog, you can also get it out again. To start, you can use enableRegularTraceOutput and enableJavascriptConsole to make Olog write it’s parsed output to both the built in output panel and the JavaScript console/Firebug respectively. If you want to leverage Olog’s parsing, but also want the output elsewhere, you can listen to OlogEvent.OLOG_OUT, which will dispatch a copy of all Oline objects as they are parsed. Imagine sending those over a socket; remote loggin’, baby!
There is also a menu available by clicking the circle at the top right. This will give you the option to save all the contents of the log to either XML or a text file. Once your clients get used to sending you these files along with a screenshot at the time something went pear shaped, I’ll bet you the time it takes to isolate a bug will plummet.
