Brian Kotek:
Inversion of Control

I just pushed a new sample application called SwizModuleExample-Flex4 to GitHub. This example is meant to demonstrate the various ways that Swiz supports the use of modules. The key ideas demonstrated are:

• Loading a Module
• Detecting full creation of a Module (not just the ModuleEvent.READY event)
• Dispatching events from a root Swiz instance that are mediated by all Modules
• Dispatching events from a root Swiz instance to a specific Module
• Dispatching events from a Module that are mediated in the root Swiz instance
• Dispatching events from a Module that are mediated by other Modules.
• Injecting Beans that are defined in a root Swiz instance into a child Swiz instance.

While this example is really meant to be looked through at the code level, I have a running version with View Source enabled that you can look at as well. I hope folks find this example helpful!

Comments (2) | del.icio.us | Digg It! | Linking Blogs | 685 Views

Just a quick note that, as promised, my presentations from CFUnited are now online!

Clean Code

The Swiz Framework for Flex and ActionScript

Thanks to all who attended!

Comments (0) | del.icio.us | Digg It! | Linking Blogs | 526 Views

I've been using Chrome since someone created an AdBlock plugin for it. I love the browser, but the latest version of Chrome broke my ability to debug Flash and Flex applications using the debug player. This also kills the ability to use the Flash Builder Profiler. The fact that Chrome silently updates itself made this one of those "WTF" moments, since everything was working fine yesterday. It took me a while to track down the problem, so I thought I would save anyone reading this the pain.

It looks like this was caused by having their built-in Flash player enabled by default in the latest version of Chrome. The browser seems to want to use this version of the player even if you have the real Flash debug player installed as well! Luckily, the fix is simple (if not obvious): point Chrome at the URL "about:plugins", locate the built-in version of Flash player in the list, and disable it. Make sure you have the correct debug player also listed in the plugin list and that it is active. Restart Chrome and you're good to go.

Comments (5) | del.icio.us | Digg It! | Linking Blogs | 770 Views

This isn't new news, but I've been meaning to make this picture for a week or two and finally got around to it. :-)

Comments (4) | del.icio.us | Digg It! | Linking Blogs | 1039 Views

One of the utility classes that is part of the Swiz library is AutowiredTestCase. As the name implies, you can use this class to help test your Swiz applications.

In this case, code will show what's going on much better than doing a lot of typing, so here is a sample FlexUnit 4 test case. First, the class under test:

package com.briankotek.flex4swiztests.control
{
	import com.briankotek.flex4swiztests.event.MyEvent;
	import flash.events.IEventDispatcher;

	public class MyController
	{
		
		[Dispatcher]
		public var dispatcher : IEventDispatcher;
		
		public var didSomething : Boolean = false;
		
		[Mediate( event="MyEvent.CONTROLLER_ACTION_REQUESTED" )]
		public function handleAction() : void
		{
			didSomething = true;
			actionComplete();
		}
		
		private function actionComplete() : void
		{
			dispatcher.dispatchEvent( new MyEvent( MyEvent.CONTROLLER_ACTION_COMPLETE ) );
		}
		
	}
}
		

You can see this is a simple controller, which responds to the CONTROLLER_ACTION_REQUESTED event, updates a property, and then dispatches CONTROLLER_ACTION_COMPLETE. We want to test that the controller is responding to the correct event, property updating the property, and finally dispatching the completion event.

The event itself is a simple event class:

package com.briankotek.flex4swiztests.event
{
	import flash.events.Event;
	
	public class MyEvent extends Event
	{
		public static const CONTROLLER_ACTION_REQUESTED : String = "controllerActionRequested";
		public static const CONTROLLER_ACTION_COMPLETE : String = "controllerActionComplete";
		
		public function MyEvent(type:String)
		{
			super(type, true, false);
		}
	}
}
		

Finally, the test case itself:

package com.briankotek.flex4swiztests.control
{
	import com.briankotek.flex4swiztests.control.MyController;
	import com.briankotek.flex4swiztests.event.MyEvent;
	import org.flexunit.Assert;
	import org.flexunit.async.Async;
	import org.swizframework.core.*;
	import org.swizframework.utils.test.AutowiredTestCase;

	public class MyControllerTestCase extends AutowiredTestCase
	{	
		private var myController : MyController;
		
		[Before]
		public function setUp():void
		{
			myController = new MyController();
			
			swizConfig = new SwizConfig();
			swizConfig.eventPackages = "com.briankotek.flex4swiztests.event.*";
			
			beanProviders = [new BeanProvider( [myController] )];
		}
		
		[After]
		public function tearDown():void
		{
			myController = null;
		}
		
		[Test(async)]
		public function testControllerActionRequested() : void
		{
			Assert.assertTrue( "Controller property is already true.", myController.didSomething == false );	
			Async.handleEvent( this, swiz.dispatcher, MyEvent.CONTROLLER_ACTION_COMPLETE, checkEvent ); 
			swiz.dispatcher.dispatchEvent( new MyEvent( MyEvent.CONTROLLER_ACTION_REQUESTED ) );
		}
		
		private function checkEvent( event : Event, passThroughData : Object ) : void
		{
			Assert.assertTrue( "Controller property was not updated.", myController.didSomething == true );	
		}
		
	}
}
		

I start off setting up an instance of Swiz that my test can use. AutowiredTestCase has a method marked with [Before] metadata, so that FlexUnit runs it before each test. I create an instance of the class under test (MyController), then set the event packages on the SwizConfig. Finally, I place the MyController instance into a BeanProvider, so that Swiz will process it as a bean. This way, any Swiz metadata in MyController is processed.

The test method dispatches a CONTROLLER_ACTION_REQUESTED event. If all goes well, the mediated event in the controller should run, update the property, and then the controller will dispatch the completion event. Running the test produces a passing result, so everything is working as expected!

Note that because Swiz actually processes your test case itself as a bean, you can use Swiz metadata in your test if you want or need to. So injecting a dispatcher, mediating an event, or testing custom metadata processors are all possible as well.

Comments (1) | del.icio.us | Digg It! | Linking Blogs | 875 Views