Brian Kotek:
Inversion of Control

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 | 573 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 | 873 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 | 704 Views

There's a lot of good news from the Swiz world today. First, we just released the Swiz 1.0 Release Candidate, which fixes a number of small bugs in the beta and adds numerous new features. This version should be pretty much feature-complete, so at this point we'll be focused on fixing any issues that come up. A final 1.0 should be out in the next few weeks.

I did my best to help out with this release by working hard on updated documentation. You can see the fruits of this labor on the new Swiz documentation wiki we've created through JIRA Studio. You can also sign up to enter feature requests or bugs, vote on issues, and all the other good stuff that JIRA provides. If you have any feedback on the documentation, feel free to leave a wiki comment and we'll do our best to address it.

I've also created a Swiz 1.0RC version of my example application. If you like, you can view or download the source code.

Since 1.0RC removes the option for "view injection" into a bean, folks have asked about ways to handle providing a view to a Swiz bean. I created a MediateView custom metadata extension that should handle most of these needs. I'll do my best to keep it up to date as I get feedback about it.

And finally, in the "better late than never" department, I've uploaded the Swiz presentation I gave at cf.Objective() 2010 to SlideSix. I'll also be speaking on Swiz at this year's CFUnited conference. If you're planning on going, I'm happy to talk about Swiz into the wee hours of the morning!

Comments (3) | del.icio.us | Digg It! | Linking Blogs | 802 Views

With the release of the 1.0 Beta of the Swiz framework, I've updated my Swiz example application to the latest version. You can also view the source code if you like. I'd like to point out a few things that I had to change from the example based on version 0.6.4:

• The instantiation of the framework has changed in order to support multiple instances of Swiz, primarily for Flex module support:
  

  <swiz:SwizConfig id="mySwizConfig"
                   eventPackages="com.briankotek.swizdemo.event"
                   viewPackages="com.briankotek.swizdemo.view"
                   defaultFaultHandler="{genericFault}" />
  
  <swiz:Swiz id="mySwiz" beanProviders="{[Beans]}" config="{mySwizConfig}" />
  		

• The static methods on the Swiz class have been removed, due to the fact that there can now be multiple instances of Swiz. This means that instead of doing something like Swiz.dispatchEvent( event ), you now want to inject a dispatcher object into your non-view objects and dispatch events through it instead. The two main ways to do this are to inject the dispatcher in your BeanLoader/BeanProvider, or by having your class implement the IDispatcherAware interface, which will instruct Swiz to inject the dispatcher automatically.
• The [Autowire] metadata tag has been deprecated in favor of the more industry-standard [Inject]. [Autowire] will still work for now, but be aware that this may be removed in a future release.
• The use of the earlier CommandChain has changed to support more robust and extensible chains, as well as supporting internal Flex event-based chains on top of the existing support for chains that make server calls. For example:
  

  var chain : CommandChain = new CommandChain();<br>
  chain.addMember( new AsyncChainStepCommand( delegate.deleteUser, [user], userDeleteHandler ) );<br>
  chain.addMember( new AsyncChainStepCommand( delegate.deleteUserProfileImage, [user], userProfileImageDeleteHandler ) );<br>
  chain.addEventListener( "chainComplete", userDeleteCompleteHandler, false, 0, true );<br>
  chain.start();
  		

Anyway, that's all for now, but I'll be posting more about the Swiz updates soon. If you're interested in seeing more about 1.0, have a look at Sam Ahn's demo of Swiz using AS3Signals. A very cool use of the brand new custom metadata support now available in Swiz!

Comments (24) | del.icio.us | Digg It! | Linking Blogs | 2627 Views