Join us for an evening with Mike Chambers & Lee Brimelow from Adobe.  This will be a good opportunity to speak directly with Adobe, ask questions, and discuss recent changes around the Flash Player.

The Future of Flash – Mike Chambers

In this session, Mike will lead a discussion around recent changes and announcements around the Flash Platform. He will then spend some time laying out the roadmap for the Flash Player, and discuss the direction in which the player will evolve, including the general focus of the player and the ActionScript language and AVM (ActionScript Virtual Machine). In addition to discussing the Flash roadmap, we will be showing off the latest Flash and Adobe AIR content, give some sneak peeks on upcoming releases, and setting aside plenty of time for open discussions and Q&A.

Adobe Gaming Technology – Lee Brimelow

In this session Gaming Evangelist Lee Brimelow will reveal the latest technologies being worked on by Adobe for game developers. They will show how these technologies allow developers to create casual 2D games in addition to AAA 3D games. Current best practices will also be discussed.

This will also be streamed on my ustream channel for those who can’t attend in person.

Let’s give a quick example of a simple problem: You need to find the index of a string within a 2D array and do something with that index.  Here’s how I would do it normally:

private function findIndex(text:String):void
{
	var row:Array;
	var index:Point;
	for(var y:uint = 0, ylen:uint = array.length; y<ylen; y++)
	{
		row = array[y];
		for(var x:uint = 0, xlen:uint = row.length; x<xlen; x++)
		{
			if(row[x] == text)
			{
				index = new Point(x,y);
				break;
			}
		}
		if(index)
		{
			break;
		}
	}
	// Do something with index
}

You’ll notice that within the example, the second I find the index, I break out of the loops to reduce the run time of the function. The external loop always looks to see if ‘index’ is not null and breaks out if it is. I’ve never liked this approach because it adds more code than needed and sometimes its not as easy as just checking if a variable is not null. You could always use ‘return’ if your function is done with its purpose, but that’s not always possible.

The alternative to this is using label statements. What you can do is simply ‘label’ your loops and then when you want to break, you can specify which loop that needs to be broken. Take our current example and let’s add label statements in it:

private function findIndex(text:String):void
{
	var row:Array;
	var index:Point;
	outer:for(var y:uint = 0, ylen:uint = array.length; y<ylen; y++)
	{
		row = array[y];
		for(var x:uint = 0, xlen:uint = row.length; x<xlen; x++)
		{
			if(row[x] == text)
			{
				index = new Point(x,y);
				break outer;
			}
		}
	}
	// Do something with index
}

That is much better and cleaner. I’ve seen this done before in Java, but I have never encountered or read about it for Actionscript. This method can also be used with the ‘continue’ operator so that it skips the rest of the code to the next iteration or with block statements like so:

doSomething: {
	var x:uint = index.x;
	if(x > 100)
	{
		break doSomething;
	}
	trace(x);
}

I don’t think I would ever use it with block statements since these could be simply replaced with ‘if’ statements, but knowing about it can be beneficial. I know I will be using label statements in nested loops from now on.

I will say this right away, I’m biased towards Parsley and have advocated its use for over a year and a half now.  It has time and time again proven itself a reliable, robust and rapid framework for application development.  Its track record is quite impressive;  It was used to build some of the world’s largest Flex applications.  Jens Halm, the creator of Parsley, has done a wonderful job at making his framework extensible, fast and optimized for both Flash and Flex.  Robotlegs is also a good framework, don’t get me wrong, it just doesn’t capture me as much and it’s not optimized for Flex (pure Actionscript), but  in the end it comes down to your development preference.

Now to ask the question, which pattern we use for our project? Presenter or Mediator?  Parsley is built around the Presenter pattern while RobotLegs uses Mediator.  Simply speaking, the difference between the two is fairly minimal, but can affect your project quite a bit.  Here’s a quick diagram on how they work:

If you remember your UML class diagrams, you would see that a Mediator can only have one View, while the View can have many Mediators.  In this case, the Mediator is the ‘man-in-the-middle’ since nobody else knows about it; its sole purpose is to listen to the View and give it data.  The View communicates with the Mediator through events to which the Mediator acts upon.  One thing I like about this pattern is that it forces developers to use a proper “data in, events out” methodology and separates the concerns of the business from the View.  This also creates decoupled components since there’s no hard dependency in the View; it could still fully function if it is moved into another project.

For the Presenter, things are a bit different since the View knows about it.  The Presenter is there to just present data which is easily binded within the View, but this is problematic since it’s coupling your View to that Presenter and even the model (data).  However, you don’t need to use events within the View to communicate to your Presenter since you can access its public functions directly.  It’s easier to use this method because it limits the code needed to communicate between the View and the Presenter, but it’s coupling your View.

In the diagram, you might have noticed that with a Mediator pattern you can have a View with several Mediators and even reuse the Mediators on other Views.  This makes the Mediator more of a View based pattern.  The Presenter however doesn’t care and a View can have multiple Presenters which can (and should) be reused across multiple Views to display the data they need.  This makes the Presenter more of a data based pattern since it’s job is to give access to data and manage it.

There you have it.  One thing to remember is that patterns are meant to help you develop, not make it harder.   Since I love Parsley so much and had a need for a Mediator pattern for a project (needed to decouple the component) and Parsley only provides a Presenter pattern, I extended the framework to include a Mediator tag. It’s completely open source and now on GitHub.  Enjoy.

Videos for both presentations are available after the break.

In a way, this project (once it gets started in full force) will be one step ahead of Adobe because of the sheer number of developer resources out there on the web.  Definitely something to keep an eye on, so please sign up and contribute!