Almer/Blank Labs

A common practice amongst PureMVC developers when creating PureMVC Mediator implementations is the "view getter", a getter method that returns the instance of the view object that the Mediator is coupled with. As an example I will use an imaginary media player with a playlist. …read more…

Just posted an update to ZamfBrowser.  ZamfBrowser can now generate code for use in either Flash or Flex based projects.   …read more…

One of my favorite things about using PureMVC as my application framework are the standards established for organizing application code.  For notification names the common ways that I have seen these organized is by declaring constants on the concrete Facade, or by externalizing them to external classes.  I have tried both approaches, but my preferred method is to externalize the constants to notification classes.  Not only do I feel like its more organized because the notification names for a section of the application are centralized to different notification classes.  But, it is also a good way to clean up the amount of imports in the concrete Facade and centralize the Command registrations to these notification classes.

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 )