Brian Kotek: Inversion of Control - Flex

Swiz Example Application Demonstrating Module Support

Mon, 16 Aug 2010 13:12:00 -0700

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!

CFUnited Clean Code and Swiz Presentations Now Online

Wed, 04 Aug 2010 15:33:00 -0700

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!

Latest Chrome breaks Flash Debug player! Here's how to fix it.

Wed, 30 Jun 2010 09:07:00 -0700

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.

Apple HTML 5 Fail

Mon, 21 Jun 2010 09:37:00 -0700

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. :-)

Using the Swiz AutowiredTestCase

Tue, 15 Jun 2010 09:27:00 -0700

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:

js|
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:

js|
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:

js|
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.

Swiz 1.0RC Released! So here's an updated example, custom ViewMediator, and more

Wed, 19 May 2010 09:56:00 -0700

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!

Swiz Example Application Updated to Support Swiz 1.0 Beta

Fri, 05 Mar 2010 08:59:00 -0700

Update on 8/16/10: With the release of Swiz RC1, I released an updated version of this example application. 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:
xml|
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:
js| var chain : CommandChain = new CommandChain(); chain.addMember( new AsyncChainStepCommand( delegate.deleteUser, [user], userDeleteHandler ) ); chain.addMember( new AsyncChainStepCommand( delegate.deleteUserProfileImage, [user], userProfileImageDeleteHandler ) ); chain.addEventListener( "chainComplete", userDeleteCompleteHandler, false, 0, true ); 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!

Swiz 1.0 Beta is Live!

Mon, 01 Mar 2010 11:29:00 -0700

This morning, the Swiz team released the 1.0 Beta of the Swiz Framework. You can view the extensive list of updates at the Swiz web site. Have a look and try out the new features. We'll be doing a full update of the documentation as we prepare for the final release. I also have an updated version of my sample application about ready, and I will upload it and highlight the differences between 0.6.4 and 1.0. Stay tuned!

My CFinNC Presentations at SlideSix

Thu, 22 Oct 2009 12:02:00 -0700

I've uploaded my CFinNC presentations to SlideSix for anyone who's interested: Object-Oriented Design Principles Introduction to Swiz Overall, CFinNC was great. I actually had to work for a large chunk of the weekend so aside from presenting and mingling with folks later in the evening, I didn't get to attend many other sessions. That said, everything looked top-notch while I was there. The conference unfolded very smoothly and all of the attendees seemed very engaged. Hats off to Dan Wilson and the entire volunteer team for pulling this off! This conference definitely held its own against the other CF conferences I've attended. It was very difficult to tell that it was completely free. Hopefully we can do it again next year!

Flex DataGridColumn Complex Properties Bug and Workaround

Fri, 09 Oct 2009 12:57:00 -0700

One Flex limitation I've had to work around for a long time is the need for having a complex property name as the dataField for a DataGridColumn, like this: I had written a nice, generic, custom labelFunction as well as a custom NestedPropertyDataGridColumn to handle this, and it all seemed to work well. I just discovered that the Flex team had addressed this in the Flex 3.4 SDK update, though I don't think you'd ever know it since I couldn't find any actual note that this was added. The only reason I discovered this was actually looking at the source code, and then finding this ticket in the Flex issue tracker. So yay, we can use complex properties in our DataGridColumns now! Except...it's broken. Ugh. Really, guys on the Flex team? This was added and no one ever bothered to click on the column to sort it? Hmph. Anyway, as one workaround, you can use a custom DataGridColumn combined with a custom Sort to get proper sorting in most cases:

js|
package com.briankotek.util.datagrid
{

import mx.collections.ListCollectionView;
import mx.controls.DataGrid;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.mx_internal;
use namespace mx_internal;

/**
 * A custom DataGridColumn that supports sorting a column that has a nested child property path for the dataField value.
 */
public class DataGridColumnNested extends DataGridColumn
{
	public function DataGridColumnNested( columnName : String = null )
	{
		super( columnName );
	}

	/**
	 * Override itemToLabel to force a ComparableSort custom sort class onto the parent DataGrid dataProvider.
	 * This works around a bug in sorting columns with complex property names in the dataField value.
	 * @param data
	 * @return
	 */
	override public function itemToLabel( data : Object ) : String
	{
		var parent : DataGrid;
		if( owner && owner is DataGrid )
		{
			parent = owner as DataGrid;

			if( hasComplexFieldName && parent && parent.sortableColumns && parent.dataProvider is ListCollectionView &&
				(
					!( ListCollectionView( parent.dataProvider ).sort ) ||
					!( ListCollectionView( parent.dataProvider ).sort is ComparableSort )
				)
			  )
			{
				ListCollectionView( parent.dataProvider ).sort = new ComparableSort();
			}
		}
		return super.itemToLabel( data );
	}

}
}

js|
package com.briankotek.util.datagrid
{
import mx.collections.Sort;
import mx.collections.SortField;

/**
 * Custom Sort class that forces the correct compareFunction for a given field to be used.
 */
public class ComparableSort extends Sort
{
	public function ComparableSort()
	{
		super();
	}

	override public function findItem( items:Array, values:Object, mode:String, returnInsertionIndex:Boolean = false, compareFunction:Function = null ):int
	{
		if( !compareFunction && fields && fields.length && fields[0] is SortField && SortField( fields[0] ).compareFunction )
		{
			compareFunction = SortField( fields[0] ).compareFunction;
		}
		return super.findItem( items, values, mode, returnInsertionIndex, compareFunction );
	}
}
}

This forces the custom Sort class onto the grid's dataProvider, and then forces the correct compareFunction from the SortField to be used by the Sort's findItem() method. Hopefully we'll get a fix for this soon, but in the meantime, maybe this workaround will help out some other folks.

I'm Speaking at the CFinNC Conference...See You There?

Fri, 04 Sep 2009 12:00:00 -0700

Just a quick note that I'll be speaking at the CFinNC conference on October 17-18th here in Raleigh, NC. My topics are Object-oriented Design Principles and The Swiz Framework for Flex. The conference is FREE and the lineup is very impressive, so if you can attend, please register! And if you register, please actually show up! The danger with a free conference is that it's easy for folks to back out at the last minute, since they lose nothing. But for the organizers, it makes estimating actual attendance difficult. So if you sign up, please do your best to make it. :-) I'm looking forward to seeing some folks that I normally have to wait until MAX or next year's CFObjective or CFUnited conferences to see. And I hope to meet a lot of new people as well. See you in Raleigh!

HTML 5 Isn't Going to Kill Flash

Thu, 09 Jul 2009 07:17:00 -0700

Lately I've seen a number of blog posts and news stories touting HTML 5 as some sort of Flash Killer in the RIA space. Am I the only one shaking my head at this? First off, let me say I'm thrilled that HTML 5 is in the works, and that the markup language is being improved. I could say it's about time, but I won't. (I guess I just did though!) That said, the people claiming that HTML 5 is going to kill Flash seem to have a pretty poor memory. According to the editor of HTML 5, it's not going to become a proposed recommendation until 2022. That's over a decade, folks. That's a long, looooong time. Think back a decade. Remember 1999? Most people were using IE 4. There was no AJAX, and there were no RIAs. There were no social networks. There was no Twitter, and no iPhone. Now project that kind of change forward 10 years, only double the rate of change. So much is going to happen before HTML 5 is widely adopted that it's not even funny. Heck, something might even kill Flash. But it's not going to be HTML 5. And even if the new spec offers some kind of parity with Flash, Flex, and Silverlight, it's not like the existing RIA platforms are going to stand still. There will be huge advances over the next decade. So being, among other things, a Flex developer, I'm probably biased here. But I just don't see what all the fuss is about. An updated spec is great, and I sure it will find many uses and offer a lot of interesting features. But to trot this out as yet another Flash Killer seems unrealistic at best, and reeks of ulterior motives at worst. What do you think? Am I right? Or am I just blinded by my association with Flex?

SilverFlash Beta Released: A Joint RIA Platform from Adobe and Microsoft?!

Wed, 01 Apr 2009 06:41:00 -0700

Microsoft and Adobe just announced the public availability of a joint RIA platform called SilverFlash. While it is only in early beta, and the future plans are somewhat vague, this looks like it could be something quite interesting for Flash and Flex developers for several reasons. First, it actually goes far beyond Microsoft's current Silverlight platform, in that it actually merges the Flash platform with the Windows Presentation Foundation (WPF). In some ways this seems similar to what Adobe AIR provides, except that the WPF extends much more deeply into the Windows operating system. That means a lot more power when doing desktop integration. But obviously the real draw here is that we'll have a unified RIA platform that is backed by all the major players in the industry (even Sun is on board) and that runs on any operating system. Just imagine: the power and ubiquity of Flash combined with the stunning calendar widgets of Sliverlight, all wrapped in a Java applet. You can download the beta at the SilverFlash Launch website. This is going to do for RIAs what the Apple Newton did for handheld computing!

Flex Tip: Why ListCollectionView Is Your Friend

Wed, 18 Mar 2009 10:59:00 -0700

I've been meaning to blog quickly about this topic for a while. But a post from Mike over at Smart Pitbull prompted me to go ahead and do it. Mike was having an issue with having two Flex DataGrids both bound to the same ArrayCollection. When he did something that sorted one grid, both grids would be sorted. This wasn't what he wanted, so he looked at a couple of solutions. His first idea was to have the server convert his query into an Array, and use that to create two separate ArrayCollections based on the array. This works, but it required adding the server-side logic to do this translation. On the advice of some readers, he dropped that solution and instead went with client-side code that loops over the result and adds each item to two separate ArrayCollections. Actually, I think Mike's first solution was the better of the two. The second option creates two completely different ArrayCollections, which means no changes to one will be reflected in the other. One can add, remove, and modify elements in one collection and the other will remain completely unaffected. In most cases this is going to be a bad thing. Even if there are two separate grids, you probably don't want to have to manually synchronize the underlying data. Which is exactly what would have to happen here. If someone adds a User to one of the collections, the other collection (and grid) will not change. In general, you want to have a single data collection so that changes to it are immediately reflected in any views that are bound to it. The solution that I would offer is to use two ListCollectionViews to act as the binding targets for the DataGrids. Among the many (MANY) benefits of working with my friend Joe Rinehart was that he clued me into this option very early in my Flex learning curve. So in Mike's case, the solution is to wrap the collection returned from the server in two ListCollectionViews, one of each grid, like so:

js|
modelData = e.result as ArrayCollection
gridData = new ListCollectionView( modelData );
advancedGridData = new ListCollectionView( modelData );

With this approach, you can sort the grids independently and not affect the other. This is because the the DataGrid (and indeed anything that sorts a collection) will apply a Sort or filterFunction directly on the bound collection. That is why you'll see both grids sort together if they are both bound to the same collection, and why the sorting is independent if each grid is bound to a different ListCollectionView. At the same time, since the underlying collection is shared by both of the ListCollectionViews, you don't need to worry about synchronizing the two collections when has elements added, removed, or changed. I've created a simple example to show this in action. View source is enabled if you want to see what's going on. Hopefully this makes sense, and shows why using a ListCollectionView wrapper around your underlying data is a very useful option when you need to expose that data in different views.

Swiz Part 5: Simulating Server Calls with a mock AsyncToken

Mon, 16 Mar 2009 13:16:00 -0700

In the last entry in this series on the Swiz framework, I discussed the use Dynamic Responders to make calls to the server as easy as possible. This entry is a short aside on how you can use some nice testing features that are built into Swiz to simulate calls to a server. As before, the current version of the application and its source code is available.

So far, we've looked at how Swiz's inversion of control (IoC) features make managing dependencies in a Flex application dead simple. We've dispatched events from the CentralDispatcher, and we've executed service calls using our Delegate class. But what is actually happening at the Delegate level? Let's delve into this.

You might have noticed that within my Controller, I'm having Swiz wire in an object of type IUserDelegate:

js|
[Autowire]
public var delegate : IUserDelegate;

Why am I specifying the type as an interface instead of an actual class name? Flexibility! One of the most basic tenants of object-oriented design is to "design to interfaces". That doesn't necessarily mean you have to type everything as an interface. It just means you should keep your typing at the highest level of abstraction that you can. Ideally, that means typing things to interfaces or abstract classes. Because I'm typing the delegate to IUserDelegate, that means I can have Swiz autowire anything that implements the contract defined by the IUserDelegate interface. And that's exactly what I'm doing. Here's the Beans.mxml file again:

xml|

You can see that the delegate is actually a MockUserDelegate. Here's the code for that class:

js|
package com.briankotek.swizdemo.delegate
{
	import com.briankotek.swizdemo.model.User;
	import mx.collections.ArrayCollection;
	import mx.rpc.AsyncToken;
	import org.swizframework.delegate.AbstractDelegate;
	import org.swizframework.util.TestUtil;

	public class MockUserDelegate extends AbstractDelegate implements IUserDelegate
	{
		
		// CONSTRUCTOR
		
		public function MockUserDelegate()
		{
			super();
		}
		
		// PUBLIC METHODS
		
		/**
		 * In a real application this would execute a server call to a remote object
		 */ 
		public function loadUsers() : AsyncToken
		{	
			return TestUtil.mockResult( buildMockUserCollection() );
		}
		
		/**
		 * In a real application this would execute a server call to a remote object
		 */ 
		public function saveUser( user : User ) : AsyncToken
		{
			if( !user.id )
			{
				user.id = Math.round( Math.random() * 100 );
			}
			return TestUtil.mockResult( user );
		}
		
		/**
		 * In a real application this would execute a server call to a remote object
		 */ 
		public function deleteUser( user : User ) : AsyncToken
		{
			return TestUtil.mockResult( user );
		}
		
		/**
		 * In a real application this might execute a call to a third party file server
		 */ 
		public function deleteUserProfileImage( user : User ) : AsyncToken
		{
			// Pretend that this deletes a file from a file server like Amazon S3.
			return TestUtil.mockResult( user ); 
		}

		// PRIVATE METHODS
		
		/**
		 * Build a fake collection of Users as a mock result.
		 */ 
		private function buildMockUserCollection() : ArrayCollection
		{
			var result : ArrayCollection = new ArrayCollection();
			
			var user1 : User = new User();
			user1.id = 1;
			user1.firstName = "Tom";
			user1.lastName = "Swift";
			result.addItem( user1 );
			
			var user2 : User = new User();
			user2.id = 2;
			user2.firstName = "Bob";
			user2.lastName = "Hope";
			result.addItem( user2 );
			
			var user3 : User = new User();
			user3.id = 3;
			user3.firstName = "Alan";
			user3.lastName = "Alda";
			result.addItem( user3 );
			
			var user4 : User = new User();
			user4.id = 4;
			user4.firstName = "Roger";
			user4.lastName = "York";
			result.addItem( user4 );
			
			return result;	
		}
	}
}

As you can see, I'm not actually making a call to a server. I'm generating an ArrayCollection of "fake" User objects, and then using a handy method called mockResult() in the Swiz TestUtils class. This method generates an AsyncToken for you and adds your result to it. It will even let you simulate a delay, like a real server call would have. In this way, you can easily test your Swiz application without needing the server side working. This not only makes examples like mine much easier to release, but it lets you unit test your applications, as well as do work on parts of the UI before the server-side code has been implemented yet. I hope you can see the usefulness of this approach, the handy nature of Swiz's mockResult() method, and the ease with which Swiz lets you swap out implementations like this. I'll sign off for now, but in the next entry (which will come more quickly than this one did, I promise) we'll look at another great Swiz feature: Dynamic Event Mediators.