ActionScript 3.0 Design Patterns

Think in Non-Linear Concepts

Other than the fact that nested conditionals can create the worst kind of object binding as each condition sends the program further down the binding rabbit hole, we seem to really need them for working out certain kinds of problems. For example, in a visual game scenario, the user may be faced with choices. Suppose the game state is a crossroad where the player must choose to go North, East, West or South (NEWS). Alternatively, the choice may be video perspectives of different directions. Any one of the choices carries with it a whole set of other states, conditions, capabilities and properties.

One way to handle this kind of choice is with a conditional statement. The following shows two things. First, it shows that when a direction is selected, it typically has more than one thing being affected. (The more than one thing is furnished by “Everything else.”) Second, the binding for each is represented by the conditions within each conditional. (You could do the same thing with a Switch statement, but the binding wouldn’t change.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

package
{
	import flash.display.Sprite;
	public class NEWS extends Sprite
	{
		private var newsArray:Array = new Array("north","east","west","south");
		private var dir:Object;
 
		public function NEWS()
		{
			for (dir in newsArray)
			{
				if(newsArray[dir]=="north")
				{
					trace("Hellloo Siberia");
					trace("Everything else....");
					trace("");
				}
				else if(newsArray[dir]=="east")
				{
					trace("Visiting Bejing");
					trace("Everything else....");
					trace("");
				}
				else if(newsArray[dir]=="west")
				{
					trace("Dude! You made it!");
					trace("Everything else....");
					trace("");
				}
				else if(newsArray[dir]=="south")
				{
					trace("¡Recepción a la Argentina!");
					trace("Everything else....");
					trace("");
				}
			}
		}
	}
}

That certainly can solve the issue of generating different responses from different object properties. It’s compact and saves ground-fills of wasted bits. It illustrates a common method of dealing with multiple options. The loop iterates through the object, and each iteration is examined by four conditional statements.

Unconditional Programming

Let’s go back to the NEWS example, and instead of having trace statements representing different directions, this next example uses short videos pointing in different directions. (I live in the woods so the videos are fairly woodsy—but they show the four points of the compass—honest.) I want to make an app with four buttons that plays a video pointing in the selected direction. Plus, I don’t want to use any conditional statements. (Easier than you think.) Click the Play and Download buttons to see a working example and get the code and videos.

In the next section where we examine the code you will see two things: No conditional statements and a non-linear solution. The user has several choices, and simply by making a choice she/he goes directly to the object desired—a directional video.
Read more…

Gentle Readers: Chandima and I try different things, and this is the first time (I think) that we’ve taken an online Adobe Connect presentation and the accompanying PowerPoint slides and translated them into an article (post.) If you were able to attend the online talk, you have all of the slides along with written commentary and you can take your time to review them. Of course if you are unable to attend because it’s 3:30 am in Mumbai, this provides an asynchronous means of participating. Let us know what you think. Is it effective? Ineffective? Makes no difference? Your comments are valuable and invited.

Lazy Bones

There’re more ways than one for being lazy with design patterns. In this post we’ll look at two: First we’ll see where you can take a program based on the Factory Method and reuse it for another program. Secondly, we’ll see where we put lazy instantiation in a Factory Method. That’s double lazy! So Homer Simpsons of the world unite! This is the design pattern for you. D’oh! (In the past we’ve examined lazy initialization, but in this post we’ll look at lazy instantiation.)

Last week we had our first online presentation thanks to the Adobe users in Brazil. However, many missed it, and I promised to provide everyone with the materials we covered. Besides, since this is a discussion of a Factory pattern we can reuse our Factory Button! (Even this post is lazy!) Click the two buttons to see the apps with two different implementations. Then you can download the two apps and the PowerPoint file from the presentation by clicking the download button.

Southern Brazil

New England

So you may be thinking that both of the applications are doing pretty much the same thing—placing objects on the screen. That’s true. Rocket science it’s not. However, the nature of the classes is such that we have a wide range of options with the objects. As the applications are currently laid out, it’s easy to change the objects and the collection of objects without breaking the application. Let’s see how.
Read more…

Take This One to Work

Figure 1: Factory Method with Single Concrete Creator

You can see the design similarities between this application (MrFace) and the Dragon application. The main difference is that this one has a single concrete factory (FaceCreator) for all of the concrete products. The factory churns out all of the Product children and puts them into an array. The Client requests the array from the Creator and pulls out the elements with a loop. As you can see, they’re all draggable elements. Try out the embedded SWF file below to see how it works:

[swfobj src="http://www.as3dp.com/wp-content/uploads/2009/12/Client1.swf" alt="MrFace" align="none"]

The same Product (from the Dragon application) is re-used so it is unnecessary to revise it. However, instead of a video and a dynamically generated graphic, all of the graphics were put into the Library as Sprite classes. (To make a Sprite class just change the Base class to flash.display.Sprite.)
Read more…

Take This One to Work

You will remember the initial query that launched this two-part post started with an inquiry into the possibility of dragging a Video while it was playing. In order to make the query more relevant to design patterns, this second part looks at the process for expanding the larger issue of dragging objects inside a Sprite. Whenever undertaking such a project, begin with the Variation Table (aka Magic Table) to find the possible variations. The wrong way to start developing a design pattern for a practical problem is to look at all of the different class diagrams and pick one that looks like it will fit your problem. Instead, always start by asking, what varies?

In this case, the “hitchhiker” to be dragged is the particular type of object in question. We saw how to drag a Video object, but what about other objects that need to hitchhike on a Sprite to be dragged? So, we’re talking about different objects—or put otherwise—object variation. The closest matching variation in the Magic Table is the variation of the subclass of the object that is instantiated. That means a Factory Method design. (See how easy that was?)
Read more…

It’s about time for another Golden Lunch Bucket Contest, and once again you can reap fame and fortune! (And again, we’ll provide the former if you provide the latter. This time, though, we must insist that you provide better prizes for yourself if you’re one of the winners!)

If you’re feeling lucky, then enter the contest. Who knows? You might just win, and then you can go nuts! We know, you’ll have to put up with the paparazzi and the inevitable groupies, but that’s just the cost of fame. (Our former winners will give you advice on how to handle it all.) Just remember Dirty Harry’s advice:

You gotta ask yourself one question: Do I feel lucky? Well, do ya, punk?

Read more…

Gentle Reader, this post includes one completed application and one in the works. The AIR ActionScript 3.0 Design Pattern Catalog is meant to be a developer’s aid, and so your ideas of what to include in the catalog is important. We would really appreciate your comments on what you think would be useful in developing an information template to be used for all of the design patterns.

I recently returned from a trip to Prague in the Czech Republic, and I went to work creating a video player for my HD videos I made using a Flip Mino HD camcorder (http://www.sandlight.net/prague). Rather than pulling out and reusing my trusty State Design Pattern player (see Chapter 10), I decided to start from scratch and create a player not using a design pattern. Then I would take the completed video player and use it as an example to show how to refactor a program to a design pattern. (This will be in an upcoming post.) Since I’ve never had to refactor the original program (tweak, maybe but not refactor), and I hadn’t worked with a State pattern lately, I found myself digging up all of the materials on the State Design Pattern. What I wished I had was a handy desktop app that I could click that would show me the essentials of the different design patterns. It would be an abbreviated design pattern catalog that could be used like the little Design Pattern Principles and Lunch Bucket Rules AIR app. Then when I need a quick reference I could use the desktop app to look up the essentials of the pattern.
Read more…

A few weeks ago we had a survey to see the practices used by professional ActionScript 3.0 developers, and the results are quite interesting. Roughly, 31% of the respondents indicated that they used design patterns and OOP either as a strict policy in developing their products or from within a template. Another 51% indicated that given the time, they’d employ design patterns and all of the good practices, but because of time pressure, often they could not. The smallest category, representing 12% of the respondents, indicated that they didn’t pay attention either to design patterns or good OOP practices. In other words, 88% of the respondents indicated that they were aware of and attempted to use good development practices as a general policy except where it was impossible because of time and/or resource constraints.
Read more…

A Three-Question Survey

I’m working on a new post about ActionScript 3.0 Design Patterns at work. To help get an accurate measure of what folks are doing in the ActionScript work world, I put together a simple survey. The survey is made with radio buttons and check boxes; so it only takes a minute to fill out. Click below to take the World’s Easiest Survey:

ActionScript Design Patterns at Work Survey

We thank you in advance, and when we get the post up, you’ll see the results from the survey.

The Naked Flash Designer

As a general way of making sense out of projects, they are divided into design and development. The design component usually means graphic design, but it can also include the UI (HCI) and information design—the kinds of things Edward Tufte talks about. In other words, design refers to everything that the user actually sees and interacts with. Those involved in design must expose their work to the user. It is in no way shrouded, and hence naked.

Developers’ work, on the other hand, has better cloaking than a Romulan space ship. If something goes wrong, and the program blows a gasket, the user can see a problem, but if things work, even in the most pedestrian program, the programming is invisible. The entire program can be one hack piled on top of another (as was the case with ActionScript prior to ActionScript 3.0), and no one would ever know. So, we programmers are safe to write any kind of code we want, and as long as it works, everyone is happy.

In many respects, most projects are design ones. The look, feel, navigation and interaction of a program makes or breaks it. A beautifully programmed project isn’t worth a bean if it looks poor, is difficult to navigate or interacts awkwardly with the user. Conversely, if a program looks and acts good, no one cares about what’s under the hood as long as it works.
Read more…

Easy to Find

We got to the point where the posts on the Principles of OOP and Design Patterns and the discussions of introducing Design Patterns to the workplace became so numerous that they were difficult to locate on the blog. This is the first index that we have, and as we continue to grow, we’ll have to add more. (We are certainly nearing that point with MVC and Pure MVC posts.) So, in the “Categories” section of our blog, we’ll be adding indices as needed. Look for the Index category to locate all indices.
Read more…