ex. PlaylistMediator

package com.project.view
{
	import org.puremvc.as3.patterns.mediator.Mediator;
 
	public class PlaylistMediator extends Mediator
	{
		static public const NAME:String = "PlaylistMediator";
 
		public function PlaylistMediator( viewComponent:PlaylistView )
		{
			super( NAME, viewComponent );
		}
 
		public function get playlistView():PlaylistView
		{
			return getViewComponent() as PlaylistView;
		}
	}
}

As I've worked on PureMVC projects with other developers I've had the opportunity to see different approaches at writing application code in a PureMVC setting. The view getter was a pretty common practice, but as I've seen the way its used, and abused, I started wondering to myself, why? Why is this method necessary? Well obviously, it is necessary to retrieve the view component, without having to cast the type each time its needed. The real question is, why is it public?

The purpose of the Mediator is to listen for events on the view and send notifications to the Controller, and to provide an API to manipulate the view. And to a lesser extent, to listen to notifications that should update the view. However, I am not a fan of this either, and I try to keep notification handling in Mediators to a minimum. But that is beside the point I am trying to make about the view getter. With an API to the view provided by the Mediator I feel like the view getter should actually be protected or private, instead of public.

ex. PlaylistMediator

package com.project.view
{
	import org.puremvc.as3.patterns.mediator.Mediator;
 
	public class PlaylistMediator extends Mediator
	{
		static public const NAME:String = "PlaylistMediator";
 
		public function PlaylistMediator( viewComponent:PlaylistView )
		{
			super( NAME, viewComponent );
		}
 
		protected function get playlistView():PlaylistView
		{
			return getViewComponent() as PlaylistView;
		}
	}
}

Using protected or private enforces that you should manipulate the view via the Mediator's API, and also stops promoting code like this:

ex. PlaylistLoadedCommand

package com.project.controller.command
{
	import com.project.view.PlaylistMediator;
 
	import org.puremvc.as3.interfaces.INotification;
	import org.puremvc.as3.patterns.command.SimpleCommand;
 
	public class PlaylistLoadedCommand extends SimpleCommand
	{
		override public function execute( notification:INotification ):void
		{
			var playlist:Array = notification.getBody() as Array;
			var playlistMediator:PlaylistMediator = facade.retrieveMediator( PlaylistMediator.NAME ) as PlaylistMediator;
 
			var playlistItemView:PlaylistItemView;
			for (var i:Number = 0; i < playlist.length; i++)
			{
				playlistItemView		= new PlaylistItemView();
				playlistItemView.data		= playlist[ i ];
				playlistItemView.x		= 0;
				playlistItemView.y		= playlistItemView.height * i;
				playlistMediator.playlistView.addChild( playlistItemView );
			}
		}
	}
}

And instead, promotes code like this:

ex. PlaylistLoadedCommand – Registered to a notification sent when a Proxy is done loading playlist data

package com.project.controller.command
{
	import com.project.view.PlaylistMediator;
 
	import org.puremvc.as3.interfaces.INotification;
	import org.puremvc.as3.patterns.command.SimpleCommand;
 
	public class PlaylistLoadedCommand extends SimpleCommand
	{
		override public function execute( notification:INotification ):void
		{
			var playlist:Array = notification.getBody() as Array;
			var playlistMediator:PlaylistMediator = facade.retrieveMediator( PlaylistMediator.NAME ) as PlaylistMediator;
			playlistMediator.updatePlaylist( playlist );
		}
	}
}

In this example the Command simply calls the updatePlaylist() method on the PlaylistMediator, which encapsulates the logic required to actually update the playlist. The PlaylistMediator can now also offer this functionality to another application system if it is required later in development due to another action. Perhaps when the playlist is done and a refresh call is made, or if the user manually refreshes the playlist.

ex. In PlaylistMediator…

public function updatePlaylist( playlist:Array ):void
{
	var playlistItemView:PlaylistItemView;
	for (var i:Number = 0; i < playlist.length; i++)
	{
		playlistItemView		= new PlaylistItemView();
		playlistItemView.data		= playlist[ i ];
		playlistItemView.x		= 0;
		playlistItemView.y		= playlistItemView.height * i;
 
		playlistView.addChild( playlistItemView );
	}
}

This was just a small example, where I only showed accessing one mediator. There are instances where a notification might need to update two or three views. Instead of writing 10-20 lines in a Command per Mediator that needs to have a view updated, its much neater and easier to read to simply call a method on each Mediator. This has other benefits other than short code. If you are following some code that you are trying to debug it is easier to understand what happens if a notification is handled directly by a Command, since you will be able to see all affected actors, Mediators, Proxies, in a single centralized location. Listening to the notifications within all the mediators makes it more difficult to find all of the places that a single notification effects, as the example illustrates below. The alternative would be to listen to the notifications in each mediator, and have a command that triggers the proxy method. I think its more maintainable and easier to debug if all notifications go directly to a command. It makes more commands, and its more tedious, but in the end its far more maintainable and easier to debug.

package com.project.controller.command
{
	import com.project.view.PlaylistMediator;
	import com.project.view.MenuMediator;
	import com.project.model.proxy.ApplicationDataProxy;
 
	import org.puremvc.as3.interfaces.INotification;
	import org.puremvc.as3.patterns.command.SimpleCommand;
 
	public class PlaylistLoadedCommand extends SimpleCommand
	{
		override public function execute( notification:INotification ):void
		{
			var playlist:Array = notification.getBody() as Array;
 
			var playlistMediator:PlaylistMediator = facade.retrieveMediator( PlaylistMediator.NAME ) as PlaylistMediator;
			playlistMediator.updatePlaylist( playlist );
 
			var menuMediator:MenuMediator = facade.retrieveMediator( MenuMediator.NAME ) as MenuMediator;
			menuMediator.resetMenu();
 
			var applicationDataProxy:ApplicationDataProxy = facade.retrieveMediator( ApplicationDataProxy.NAME ) as ApplicationDataProxy;
			applicationDataProxy.getPlaylistInfo( playlist );
		}
	}
}

package com.project.controller.notifications
{
	import com.project.controller.commands.LoginCommand;
	import com.project.controller.commands.LogoutCommand;
 
	import org.puremvc.as3.interfaces.IFacade;
 
	public class LoginNotifications
	{
		static public const LOGIN:String = "LOGIN_NOTIFICATION";
 
		static public const LOGOUT:String = "LOGOUT_NOTIFICATION";
 
		public function LoginNotifications( facade:IFacade )
		{
			facade.registerCommand( LOGIN, LoginCommand );
			facade.registerCommand( LOGOUT, LogoutCommand );
		}
	}
}

Above is an example of a notification class. The constructor requires an IFacade object that it uses in the constructor to map notifications to commands using the IFacade object that is passed into the constructor. You can see how a bigger group of commands can be nicely organized into this class. Below is an example concrete Facade.

package com.project
{
	import com.project.controller.notifications.LoginNotifications;
 
	import org.puremvc.as3.patterns.facade.Facade;
 
	public class ProjectFacade extends Facade
	{
		public function ProjectFacade()
		{
			super();
		}
 
		static public function getInstance():ProjectFacade
		{
			if (!instance) instance = new ProjectFacade();
 
			return instance;
		}
 
		override protected function initializeController():void
		{
			super.initializeController();
 
			new LoginNotifications( this );
		}
	}
}

In the example above we can see the usage example for the notifications class for the login group. In the override for the initializeController() method, after initializing the controller, a LoginNotifications object is started with a reference to the IFacade instance that is the concrete facade, or simply "this". The amount of imports is reduced in the concrete facade, and there are less lines required in the initializeController() method, creating a neater, shorter concrete facade class.

This kind of organization is almost always based on personal preference, this just happens to be mine. =)

• Low-to-intermediate level Flash ActionScripters, comfortable coding on the timeline, who want to learn the raw ActionScript, as well as the underlying concepts, required to work with OSMF
• Higher level coders, using Adobe Flash or Flex, who want a quick run-down of the core classes utilized when building an OSMF video player

• Introduction: Brief Overview of OSMF and Installing the SWC ( 5:44 )
• Lesson 1 : Basics of Video Playback with OSMF ( 6:46 )
• Lesson 2 : Handling Changes in View State ( 7:04 )
• Lesson 3: Adding a Pause Toggle Button ( 8:55 )
• Lesson 4: Sizing the Video ( 9:56 )
• Lesson 5: Adding Volume Control ( 5:56 )
• Lesson 6: Adding a Progress Bar ( 13:58 )
• Lesson 7: Adding Seek Functionality ( 10:43 )
• Lesson 8: Cleaning Up After a Video ( 8:26 )
• Lesson 9 : Playing Multiple Videos ( 11:05 )