As we all know, getting a new computer is awesome, but it’s also a double edged sword…as my other partner Joe noted: “The worst thing about getting a new laptop is…well…getting a new laptop.” Sure the thing flies and all, but man there’s a good amount of hrs getting it ready for primetime development…think of all the little tools you’ve collected to make your laptop rock…

My partner and I have started to compile a live list of dev tools, goodies, IDEs,and whatevs we use on a regular basis and we thought we’d share — if you have others, please add to this list:

Basic Software & IDEs

• Eclipse Galileo R Packages or more specifically we use the Eclipse J2EE IDE
• Flash Builder — usually plug this into Eclipse
• Fireworks
• Flash
• Balsamiq
• MS Office

Connectivity & Tools

• Remote Desktop Connection Client for Mac 2
• Chicken of the VNC
• Cisco VPN Client
• MySQL Workbench
• Oracle SQL Developer
• Maven

IM & Social

• Adium
• Skype
• TweetDeck

Tweet This Post

While there are several updates and changes I made to the underlying implementation, the overall functionality remains the same so please read my original post WASI AIR Logging Console & Logging Util Tools for a general overview.

See It In Action!

• Logging Test Application — Small test app that uses the logging framework and spits out log statements every second. I have a link to the console below for quick testing.
• Logging Console Test Application — Allows you to see the Console in action when you run it and the Logging Test Application at the same time.

Assets

• WASILoggingLibrary.swc — The Log Console and Logging Utils Library
• WASILogConsoleAIR.air — The AIR Logging Console

Updates & Changes

• The name of the SWC has changed from WASILogConsoleLibrary.swc to  WASILoggingLibrary.swc.
• The LocalConnection Logger is no longer a wrapper class, but now an actual logging target called LocalConnectionTarget.
• Added a Firebug (FireFox extension) Logging Target that outputs the same log message as the LocalConnectionTarget.
• Created a base WASILoggingTarget with several, common helper methods for creating targets.

Since I mentioned that some of the actual impl changed a bit I’m going to show some code illustrating the changes.

Setting Up in Main App :: Example Code

The difference between this one and last version I shared has to do with the use of targets as opposed to a wrapper class. I also put all of my logging specifics into a helper class for the Test App called Logging — I could’ve just as easily put this all into the main app file, but I decided to move it into a new class for better organization.

<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	creationComplete="this.init()">

	<mx:Script>
		<![CDATA[
			import com.webappsolution.controller.FilterControllerTest;
			import com.webappsolution.delegate.FilterDelegateTest;
			import com.webappsolution.logging.Logging;

			private static var loggerSetup:* = Logging.setupLogging();

			private function init():void
			{
				var filterDelegateTest:FilterDelegateTest = new FilterDelegateTest();
				var filterControllerTest:FilterControllerTest = new FilterControllerTest();
			}

		]]>
	</mx:Script>

</mx:Application>

The line to make note of is

private static var loggerSetup:* = Logging.setupLogging();

which calls my helper Logging class that actually creates the logging targets, levels, and filters.

Helper Logger Class (Not Required)

/**
 * Web App Solution Confidential Information
 * Copyright 2010, Web App Solution, Inc.
 *
 * @date Apr 26, 2010
 */
package com.webappsolution.logging
{
	import com.webappsolution.logging.LoggingUtils;
	import com.webappsolution.logging.target.FirebugTarget;
	import com.webappsolution.logging.target.LocalConnectionTarget;

	import mx.logging.LogEventLevel;
	import mx.logging.targets.TraceTarget;

	public class Logging
	{
		/**
		 * Create your list of targets here.
		 */
		public static function setupLogging():void
		{
			var level:int = LogEventLevel.ALL;
			var filters:Array = createFilters();
			var targets:Array = createTargets();

			// set up logging for the application
			LoggingUtils.setupLogging(level, filters, targets);
		}

		/**
		 * Create your list of compile-time filters here.
		 */
		public static function createFilters():Array
		{
			var filters:Array = ["*"];

			return filters;
		}

		/**
		 * Create your list of targets here.
		 */
		public static function createTargets():Array
		{
			var traceTarget:TraceTarget;
			var firebugTarget:FirebugTarget;
			var lcTarget:LocalConnectionTarget;
			var targets:Array;

			traceTarget = new TraceTarget();
			traceTarget.level = LogEventLevel.ALL;
			traceTarget.includeDate = true;
			traceTarget.includeTime = true;
			traceTarget.includeCategory = true;
			traceTarget.includeLevel = true;

			firebugTarget = new FirebugTarget();
			firebugTarget.level = LogEventLevel.ALL;
			firebugTarget.includeDate = true;
			firebugTarget.includeTime = true;
			firebugTarget.includeCategory = true;
			firebugTarget.includeLevel = true;

			lcTarget = new LocalConnectionTarget();
			lcTarget.level = LogEventLevel.ALL;
			lcTarget.includeDate = true;
			lcTarget.includeTime = true;
			lcTarget.includeCategory = true;
			lcTarget.includeLevel = true;

			// create a list of targets
			targets = [traceTarget, firebugTarget, lcTarget];

			return targets;
		}
	}
}

Here I’m just creating the specific logging targets for my application:

• TraceTarget — ouputs to your Flex IDE’s console
• FirebugTarget — ouputs to your FireFox’s Firebug plugin’s console
• LocalConnectionTarget — ouputs to WASI AIR Logging Console

The other change to make note of is the actual definition of the logger in each class you’re implementing logging. Let’s take a quick look here.

New Logger Instantiation

The OLD way was like this:

private static const logger:ILogger = LocalConnectionLog.getLogger(FilterControllerTest);;

The NEW way was like this:

private static const logger:ILogger = Log.getLogger(LoggingUtils.getFullyQualifiedClassName(FilterControllerTest));

The new design decouples the logging from our custom wrapper class LocalConnectionLog and now uses the out of the box mx.logging.Log to create a category for each logger instantiation. Notice the use of LoggingUtils.getFullyQualifiedClassName(clazz:Class):String to get the fully qualified string name for the object; one can also just pass in a string category of their choice instead of using the class name.

Tweet This Post