Almer/Blank Labs

Over the weekend I updated both the ZamfBrowser application and the ZendAmfServiceBrowser class that gives the ZamfBrowser information about your ZendAMF services set up.   …read more…

Some of you may have checked out the courses I posted over on the Adobe Developer Connection on building progressive and streaming video players with the Adobe Open Source Media Framework (OSMF).

Unfortunately, even those courses are relatively new, the code in them no longer works, because OSMF has advanced a few sprints. We’re now at OSMF sprint 9, and the framework continues to shift quite a bit.

Because there are almost no examples on the web of using OSMF with Flash (as opposed to Flex), and I’ve had several people email me asking if I had time to update the code.

And, so, finally I did. At least for the progressive player. So you can download the Flash CS4 source code to build an OSMF player with the Sprint 9 framework from the article on Building progressive video players in Flash with OSMF.

Share and enjoy!

My new online video course on Dynamic Multi-bitrate Streaming with Adobe Open Source Media Framework (OSMF) has just gone live on Adobe Developer Connection.

It’s 35 minutes across five lessons and takes you through the process of converting the progressive OSMF video player (which we create in the first installment of this course on Building Progressive Video Players with Adobe OSMF, into a dynamic multi-bitrate streaming player. Multi-bitrate streaming occurs when you program your Flash to deliver the highest quality video a viewer can see (dependent on their bandwidth). *Dynamic* multi-bitrate streaming is similar, with the additional feature of having your player constantly meters the bandwidth throughout viewing, to adjust the playback between multiple videos seamlessly, as the viewer’s bandwidth may fluctuate. …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. =)