Change orientation with device position

Reminder: We’ve placed all of the downloads on the University of Hartford’s Multimedia Web Design and Development download page. Just select the bottom on the ActionScript 3.0 files and click the download button.

Flash Builder Tip: First create an ActionScript Project so that you can test it as you develop. Once you have it all developed, create an ActionScript Mobile Project and just copy and paste the files from the AS Project.

Re-Decorating

In this first part all I want to do with this mobile game is to build and decorate the warrior and put it on an iOS mobile device using Flash Builder. The mechanics are very similar to previous posts on using the Decorator pattern to arm a character (See here and here.) Figure 1 shows a file diagram of the Decorator implementation:

Figure 1:Decorator File Diagram

Since this thing is going to be in pure code, we need to create a “warrior” in code, which was not done in the previous posts linked above. So outside of the pattern, we need a graphic image, as provided in the following code:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

package
{
	import flash.display.Shape;
	import flash.display.Sprite;
 
	public class BuildWarrior extends Sprite
	{
		private var head:Shape=new Shape();
		private var torso:Shape=new Shape();
		private var lftArm:Shape=new Shape();
		private var rtArm:Shape=new Shape();
		private var lftLeg:Shape=new Shape();
		private var rtLeg:Shape=new Shape();
 
		public function assemble():Sprite
		{
			this.addChild(makeHead());
			this.addChild(makeTorso());
			this.addChild(makeLftArm());
			this.addChild(makeRtArm());
			this.addChild(makeLftLeg());
			this.addChild(makeRtLeg());
			return this;
		}
 
		private function makeHead():Shape
		{
			head.graphics.lineStyle(1,0x6F74B3);
			head.graphics.beginFill(0x6F91A6,.50);
			head.graphics.drawRect(30,17,10,3);
 
			head.graphics.lineStyle(0.25,0x0066ff);
			head.graphics.beginFill(0x035AA6,.40);
			head.graphics.drawCircle(35, 7,10);
			head.graphics.lineStyle(1,0x6F74B3);
			head.graphics.moveTo(30,6);
			head.graphics.lineTo(34,6);
			head.graphics.moveTo(36,6);
			head.graphics.lineTo(40,6);
			head.graphics.moveTo(32,12);
			head.graphics.lineTo(38,12);
			graphics.endFill();
			return head;
		}
 
		private function makeTorso():Shape
		{
			torso.graphics.lineStyle(1,0x6F74B3);
			torso.graphics.beginFill(0x6F91A6,.50);
			torso.graphics.drawTriangles(Vector.<number>([10,20, 60,20, 35,90]));
			torso.graphics.endFill();
			return torso;
		}
 
		private function makeLftArm():Shape
		{
			lftArm.graphics.lineStyle(1,0x6F74B3);
			lftArm.graphics.beginFill(0x6FB3A7,.75);
			lftArm.graphics.drawRect(10,20,10,40);
			lftArm.graphics.drawRect(10,60,40,8);
			lftArm.graphics.endFill();
			return lftArm;
		}
 
		private function makeRtArm():Shape
		{
			rtArm.graphics.lineStyle(1,0x6F74B3);
			rtArm.graphics.beginFill(0x6FB3A7,.75);
			rtArm.graphics.drawRect(50,20,10,40);
			rtArm.graphics.drawRect(51,60,8,40);
			rtArm.graphics.endFill();
			return rtArm;
		}
 
		private function makeLftLeg():Shape
		{
			lftLeg.graphics.lineStyle(1,0x6F74B3);
			lftLeg.graphics.beginFill(0x6FB3A7);
			lftLeg.graphics.drawRect(23,70,12,45);
			lftLeg.graphics.drawRect(24,115,10,45);
			lftLeg.graphics.endFill();
			return lftLeg;
		}
 
		private function makeRtLeg():Shape
		{
			rtLeg.graphics.lineStyle(1,0x6F74B3);
			rtLeg.graphics.beginFill(0x6FB3A7);
			rtLeg.graphics.drawRect(36,70,12,45);
			rtLeg.graphics.drawRect(37,115,10,45);
			rtLeg.graphics.endFill();
			return rtLeg;
		}
	}
}

All of the concrete decorators similarly implement coded graphic representations. Of course, all of these are “outside” of the design pattern but are useful to see in the contact of the pattern.

The Client

In the actual mobile client, you begin with a super(); call and support for auto orientation in the iOS device. The code is automatically generated:

1
2
3

// support autoOrients
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;

I tossed out the super(); call, and generated the following client:

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

package
{
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
 
	public class MobileDecState extends Sprite
	{
		private var warrior:Component=new Warrior();
		private var warriorSpirit:Sprite=new Sprite();
		public function MobileDecState()
		{
			warriorSpirit.addChild(warrior.getarmor());
			warriorSpirit.x=50,warriorSpirit.y=50;
			addChild(warriorSpirit);
 
			warrior=new DecBodyArmor(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			warrior=new DecShield(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			warrior=new DecHelmet(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			warrior=new DecParticleCompressor(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			// support autoOrients
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
		}
	}
}

Publishing for Mobile

For some reason, more steps are involved in publishing for Flash Builder than Flash Pro. However, once you have your certificate (it has a .p12 extension) and your provisioning file created using the tools available to Apple developers; it’s pretty simple. If you don’t know about the Apple iOS developer program for both Windows and Mac users, you need to go there first.

Here’s how to publish using Flash Builder: (Download the Beta version/update of Flash Builder 4.5.1. While you’re at it, download the beta version of Adobe AIR 3.)

1. Open a New > New ActionScript Mobile Project (Figure 2)

Figure 2: Open a New ActionScript Mobile Project

2. Specify your target platform as Apple iOS with Automatically reorient selected and click Next. (Figure 3)

Figure3: Mobile Settings

3. Click the Platform Setting and select Platform and Target devices (Figure 4)

Figure 4: Specify Platformsettings

4. Build Paths provides the opportunity to add SWC folders or a project. Figure 5 shows using the default settings.

Figure 5: Include additional or different paths if requires

5. The next step in creating your app will not come until you are finished coding it all. Then when you press the green arrow (Run) button at the top, you will begin the Run Configurations sequence. Figure 6 shows the On device radio button selected. You are likely to see some red circles with white ‘X’s in them, but don’t worry. If there’s one next to the Packaging setting click the [Configure] link.

Figure 6: Run Configurations

6. Set the Certificate and Provisioning file. Both of these should be ready using the software that the Apple iOS Developer program provides. Use the Browse buttons to locate yours. (These cannot be generated using Adobe software.)

Figure 7: Setting Certificate and Provisioning files

Once the certificate and provisioning file are set, click the Apply button and then click OK.

7. If all has gone right you will see the Packaging Completed window shown in Figure 8. At this point you will have to open iTunes on your computer, and make sure that your mobile device is connected to your computer. You will need to locate the .ipa package and drop it into the iTunes library. It’s easiest to just click the (Reveal package in Finder) to get the .ipa package.

Figure 8: Completed Window

8. Figure 9 shows the bin-debug folder opened with the .ipa package. Be sure that the Apps window on your iTunes library is selected and drag the .ipa package into the iTunes library.

Figure 9 Drag .ipa package into iTunes Apps Library

9. The final step requires that you select the connected device (shown right above Little Richard Greatest Songs in Figure 10 ) and then find your new app in the Sync Apps window. Be sure to check the box next to the app. Then click the Apply button. Clicking the Apply button will then begin the Sync process. Once it is finished you should see the icon.

Figure 10: Adding the app to an iOS device

Adding the State Design

With this and the previous posts for mobile devices, you’ve seen that design patterns work well with mobile app development. All of the advantages found in design pattern development for computers can be found in creating applications for mobile devices.

In the next post, this process will be continued by adding a State pattern to the app to create a game. If you don’t have a mobile device, you can use the same coding for making the app for your computer.

State Video Game!

Is the State Pattern the way to go with a game based on videos? First, we have to ask, what varies? In this case, different places on the grid represent different situations in a game environment and depicted in a video. (Actually, any environment that requires unique states presented in videos–such as a guided tour of a museum–would be ). Simply put, the videos vary and each represents a different state. So the answer to the first question is, yes, the State pattern is appropriate.

Second, we must ask, are updates and changes easy with this application of the pattern? In this particular case, I tested several different videos with this applications, and it’s very easy to swap and change videos. In fact, if I want to use .SWF files for animation instead of videos, that too would be a cinch.

Third, we need to consider the code generated. Will using the State pattern generate more code and more work than other patterns or coding strategies? This may be the Achilles’ heel of the pattern used as a game generation design. Consider the following:

1. Each grid cell is a state
2. A 19 x 19 grid generates 361 cells
3. Each cell needs a State class
4. The grid requires 361 State classes
5. The Context class requires getter methods for each class
6. The Context class generates at least 1,444 lines of code (assuming each method takes up 4 lines)
7. The Context class constructor function requires an additional 361 statements to instantiate instances of each state

If that looks like a lot of code and classes, it is. However, design patterns were originally created to ease the task of very large programs, and just about any way you work it out, 361 different states (video shots) is going to be difficult to keep track of. The biggest problem I can see in this design is in the Context class. The Context keeps track of what state the user is currently in. When states change (and you’ve got 361 of them), you have to include a method in the Context for changing states. There’s where you end up with a very big class. Before going on, though try playing the game and download the files using the buttons below: (By the way, this time there’s a surprise…see if you can find it in the play..be careful, it’ll eat you.)

*Reminder: I’m putting all of the downloads into a general download site stored under “ActionScript 3.0″; so, just click on the latest download and you’ll get all of the files, including the videos and even the Excel spreadsheet with the direction grid.

The Game Map So Far

To see what’s going on, I’ve created a “game map” of the files in this State and where you can navigate to. All of the videos were made with a Flip Mino HD camera and then “cartoonized” in Adobe After Effects and rendered in Adobe Premier. Keep in mind that this is a prototype work-up for a full-fledged game. Figure 1 shows how far the game is at this point. The spiral icon between East4 and East5 indicates a “turnaround.” That is, when in the East5 state, if the West button is pressed, the video does a turnaround and heads West to the state East4. (Give it a try.) Figure 1 shows the map:

Figure 1: Map of the States

For those of you who work with games and user-guided realities with video, I’d like to get any feedback you may have. Other than one little conditional statement in the Distributor class, this application is wholly free of conditional statements. The big deal about the lack of conditional statements is that nothing is bound by or entangled in a conditional. That means if you want to change the states or the context, you can do so without having to keep track of any conditional statement.

The drawback of using a State design pattern like this is that it generates a lot of classes. As you can see in the Context class, each state is instantiated in an object, and so a lot of objects are floating around. However, with some tweeks here and there, I believe you’d be able to create and remove state objects dynamically, and like the video, you’d just be using one instance at a time.

A Better State is at Hand

In our previous post on the State Design Pattern, I wanted to have a nice clear example, but in the process, too many parts were left out, and in some respects it was more complicated with the use of the helper class (Distributor) than it had to be. As a result, the design generated multiple instances of the Distributor class and each instance was difficult to control—not to mention the fact that each new instance overloaded the program with unneeded instances. As a result, I decided to simplify the video process by creating a single instance of the Distributor in the Client and just pass the name of the requested video to be played through the same instance using the Distributor’s methods. So instead of having each state return a Sprite instance, they now return a String instance used by the single Distributor instantiated in the Client. The following buttons provide the new files to download and running example:

*Note about Downloads: I’m in the process of moving all of the downloads to the MWDD site at the University of Hartford. It’s still being set up, and I’m working on a way to provide more information about each of the downloads. All of the downloads for this blog will be under ActionScript 3.0/Flash (which includes Flash Builder/Flex).

Secondly, the first example just included two states—one for starting and one for going one step to the east. That helped keep things simple, but it didn’t do much for seeing how the State design pattern can handle the North-East-West-South (NEWS) directions. Figure 1 provides a statechart that shows an NEWS state machine with an additional state to the east. It provides a better idea of where the State pattern can take us.

Figure 1: Statechart of Direction Relative States

The statechart shows movement between states and the kinds of transitions relative to a starting position.

A State Map

Basically, that State pattern is used to map different directional states. Each state has its own class, and because each state is “self-aware” in that it knows that it can only go to certain other states, no matter where you are in a map matrix, all of the possible choices of movement are available. In order to create a map, I had to set up a plan for naming each state relative to a starting position. I began with a 19 x 19 spreadsheet. This generated 361 cells (or states) which would mean a total of 361 classes. Figure 2 shows a portion of the spreadsheet. The yellow cells represent the zero axis of the NEWS positions relative to the starting point. Each cell off of the central axis is named as an intersection between North and South and the East or West state relative to the Start start state:

Figure 2: State matrix naming map

New State Interface and State Classes

This new state pattern is still incomplete because it doesn’t go beyond the initial first steps along the zero axis of north/south and east/west. However, the State pattern will need new interface methods to move in the NEWS directions and move to the Start state. We employ the following interface:

1
2
3
4
5
6
7
8
9
10
11
12

package
{
	public interface IState
	{
		function goEast():String;
		function goWest():String;
		function goNorth():String;
		function goSouth():String;
 
		function goStart():String;
	}
}

All of the return types are now String instead of void. So now, all of the concrete states will return a string. This string will call up the video associated with movement to the appropriate requested cell (state).

I’ve been giving second thoughts to including a goStart() method. Having a start state is important, but it should be just like the other states—the player arrives there by navigating in the NEWS directions. However, I’m still trying to figure out a way to make it the default starting point without using the goStart() method; so for now it stays.

Since the IState interface has changed; so too do the classes that implement it. The East1 state now has all five methods. However, a lot of the material is commented out because only a limited set of directional states and videos have been created at this time. So the commented out dir values are the actual values that will be used once the videos and the states are completed.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

package
{
	import flash.display.Sprite;
 
	//East1
	class East1State implements IState
	{
		private var context:Context;
		private var dir:String;
 
		public function East1State(context:Context)
		{
			trace("--East1--");
			this.context = context;
		}
		public function goEast():String
		{
			//Going east would require entering into a new state
			//Relative to the starting state, the second eastward
			//move is "east2";
			trace("heading east");
			//dir="east2";
			dir = "east1";
			return dir;
			//The following would have to be first built
			//context.setState(context.getEast2State());
		}
 
		public function goWest():String
		{
			dir = "intro";
			trace("Go West");
			context.setState(context.getStartState());
			return dir;
		}
 
		public function goNorth():String
		{
			//dir = "N1E1";
			dir = "north1";
			trace("Going north");
			//context.setState(context.getN1E1State());
			return dir;
		}
 
		public function goSouth():String
		{
			//dir = "S1E1";
			dir = "south1";
			trace("Going south");
			//context.setState(context.getS1E1State());
			return dir;
		}
		public function goStart():String
		{
			dir = "intro";
			trace("Go to starting point");
			context.setState(context.getStartState());
			return dir;
		}
	}
}

In the next (and last) installment in this series next week, I hope to have more done to create a little D&D type game with videos. This intermediate post will save time and space for the final installment as far as explaining the matrix.

The Video Playing Class: Distributor

The Distributor helper class provides the structure for playing progressive downloads and is now instantiated directly in the Client and has methods available for a cleaner video playback. Also, in the metadata handler, I added a code for sizing the video player to the size of the current video. Since I’ve stated to use Adobe After Effects with Adobe Premier, to add cartoon effects to the video, I’ve been having sizing problems. (Suffice it to say, there’s a learning curve going on.) The following shows the new Distributor class.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

package
{
	//This is a 'helper class'. A helper class is one that is not a 'participant' of the
	//Design Pattern, but it performs a task for one or more of the participants.
	import flash.net.NetConnection;
	import flash.net.NetStream;
	import flash.display.Sprite;
	import flash.media.Video;
	import flash.events.NetStatusEvent;
 
	public class Distributor extends Sprite
	{
		private var nc:NetConnection = new NetConnection();
		private var ns:NetStream;
		private var vid:Video=new Video();
		private var hookup:Boolean;
		private var dir:String;
		private var sniffer:Object=new Object();
 
		public function Distributor()
		{
			nc.addEventListener(NetStatusEvent.NET_STATUS,doConnect);
			nc.connect(null);
			vid.x = 137.5,vid.y = 80;
		}
 
		private function doConnect(e:NetStatusEvent):void
		{
			hookup=(e.info.code=="NetConnection.Connect.Success");
			if (hookup)
			{
				ns = new NetStream(nc);
				ns.client = sniffer;
				sniffer.onMetaData = getMeta;
				vid.attachNetStream(ns);
			}
		}
 
		public function playVid(vidName:String)
		{
			dir = "vids/" + vidName + ".f4v";
			//dir="vids/"+vidName+".flv";
			ns.play(dir);
			addChild(vid);
		}
 
		public function stopHere():void
		{
			ns.close();
			removeChild(vid);
		}
 
		private function getMeta(mdata:Object):void
		{
			vid.height = mdata.height;
			vid.width = mdata.width;
		}
	}
}

The playVid(vidName:String) method expects a string naming the video to be played (minus the extension). The state methods provide that string to be used in the Client’s instance of the Distributor class.

The Context and Client

All that’s left are the Context and Client classes. While the State classes stay the same as far as size is concerned, the Context class grows with each new state to handle. The reason that the Context class keeps growing with each new state is that it must keep track of the current state. In the State design pattern, the Context is where you can generate a lot of code. The full 19 x 19 matrix would generate over 1000 lines of code. There may be a better way of keeping track of the states, but for now, the following Context class reflects the current condition of the class:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

package
{
	//Context class
 
	class Context
	{
		private var east1State:IState;
		private var west1State:IState;
		private var north1State:IState;
		private var south1State:IState;
		private var startState:IState;
		private var stateNow:IState;
 
		public function Context()
		{
			trace("States Set");
			startState = new StartState(this);
			east1State = new East1State(this);
			west1State = new West1State(this);
			north1State = new North1State(this);
			south1State = new South1State(this);
 
			stateNow = east1State;
		}
//Directional methods
		public function doStart():String
		{
			return stateNow.goStart();
		}
 
		public function doEast():String
		{
			return stateNow.goEast();
		}
 
		public function doWest():String
		{
			return stateNow.goWest();
		}
 
		public function doNorth():String
		{
			return stateNow.goNorth();
		}
 
		public function doSouth():String
		{
			return stateNow.goSouth();
		}
//Setter for current state
		public function setState(stateNow:IState):void
		{
			trace("A new state is set");
			this.stateNow = stateNow;
		}
//Getters for each concrete state
		public function getStartState():IState
		{
			return this.startState;
		}
 
		public function getEast1State():IState
		{
			return this.east1State;
		}
		public function getWest1State():IState
		{
			return this.west1State;
		}
		public function getNorth1State():IState
		{
			return this.north1State;
		}
		public function getSouth1State():IState
		{
			return this.south1State;
		}
	}
}

At this stage of development, the Context only allows movement to the first step away from the starting point. Each concrete state class requires a method to specify each of the interface directions (e.g., doEast()) and a getter method for a specific state (e.g., getEast1State()). While the directional methods will not change, each concrete state class requires a new getter method.

Finally, the Client sets up the UI and uses information from the concrete states to play different videos. It follows the same format as the original, but it now instantiates an instance of the Distributor class.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var newsState:Context=new Context();
		private var eastBtn:Button=new Button();
		private var westBtn:Button=new Button();
		private var northBtn:Button=new Button();
		private var southBtn:Button=new Button();
 
		private var startBtn:Button=new Button();
		private var dis:Distributor=new Distributor();
		private var vidNow:String;
 
		public function Client():void
		{
			addChild(dis);
			vidNow=newsState.doStart();
			dis.playVid(vidNow);
 
			eastBtn.addEventListener(MouseEvent.CLICK,moveEast);
			eastBtn.x = 500,eastBtn.y = 200;
			eastBtn.label = "East",eastBtn.width = 40;
			addChild(eastBtn);
 
			westBtn.addEventListener(MouseEvent.CLICK,moveWest);
			westBtn.x = 5,westBtn.y = 200;
			westBtn.label = "West",westBtn.width = 40;
			addChild(westBtn);
 
			northBtn.addEventListener(MouseEvent.CLICK,moveNorth);
			northBtn.x = 260,northBtn.y = 5;
			northBtn.label = "North",northBtn.width = 40;
			addChild(northBtn);
 
			southBtn.addEventListener(MouseEvent.CLICK,moveSouth);
			southBtn.x = 260,southBtn.y = 370;
			southBtn.label = "South",southBtn.width = 40;
			addChild(southBtn);
 
			startBtn.addEventListener(MouseEvent.CLICK,moveStart);
			startBtn.x = 10,startBtn.y = 20;
			startBtn.label = "Start",startBtn.width = 40;
			addChild(startBtn);
		}
 
		private function moveEast(e:MouseEvent):void
		{
			dis.stopHere();
			dis.playVid(newsState.doEast());
		}
 
		private function moveNorth(e:MouseEvent):void
		{
			dis.stopHere();
			dis.playVid(newsState.doNorth());
		}
 
 
		private function moveWest(e:MouseEvent):void
		{
			dis.stopHere();
			dis.playVid(newsState.doWest());
		}
 
		private function moveSouth(e:MouseEvent):void
		{
			dis.stopHere();
			dis.playVid(newsState.doSouth());
		}
 
		private function moveStart(e:MouseEvent):void
		{
			dis.stopHere();
			dis.playVid(newsState.doStart());
		}
	}
}

In the next post I hope to have the beginnings of a little navigation through a video maze and a surprise to gobble up a player.

Starting State Design Patterns

I started working on the State design pattern, and I realized how easy it is to quickly get lost. The idea of a state machine is pretty clear and simple, and so is the State Design Pattern. However, I find that if I’m away from it for any length of time, it gets all tangled up again—like fishing line in a well-used tackle box. So, in this inserted post between Part I and Part III of the Video Game Machine series of posts, this one is for beginners in the State design pattern.

The two examples used are simple, but both have to get through the tangle of the requests from the Client through the Context requests and on to the concrete states via the State interface. The first example is wholly abstract but really simple. Play and download buttons provide access to get started:

Overview

Figure 1 shows the State class diagram and the ActionScript 3.0 files so that you can easily see the implementation of the pattern. The Client makes a request for a given state through the Context. The Context checks the current state (think lights on; lights off as two distinctive states) and then requests the action from the current state. So, if current state is lights on and the request is to turn on the lights, it wouldn’t do anything because the state already exists.

Figure 1: Class and File Diagrams of State Design Pattern

Rather than turning the lights on or off, this example starts with a “Starting” state and a state known as “East1.” So the user is either in the Start State or the East1 State. These two states will be abstract with trace() statements in this first example that helps to see what’s going on, but in the second app in this post, we’ll use videos. Once the State design pattern is established, it’s very easy to add and change objects without crashing the application. That’s what makes the State pattern so valuable; a little extra work at the outset pays huge dividends in the long run.

The Participants

The State design pattern deals with variation in an object’s state. An adventure game can be treated as a series of states that the player enters and leaves. Depending on the state (situation) different things are possible. The state can change from the home base, to the wizard’s fortress to the jungle to an underground cavern maze, into and out of a worm hole, a parallel universe or anything the developer’s mind conjures.

The most important work in the State pattern is Context class. It keeps track of the current state to determine how to handle a request. Imagine three states known as:

• State 1
• State 2
• State 3

State 1 can only remain in its current state or go to State 2. It cannot go directly to State 3. So if the Client requests State 3, the Context realizes that the current state is State 1 and so makes the call to State 1 where the options available in that state do not include a move to State 2.

The determinations are not made using conditional statements. Rather, as each state is called, it reports to the Context establishing itself as the current state. As a State pattern application grows in size, it must generate a separate concrete state for each new situation and possible changes in state. The State interface requires a new method for accessing the new states, and the concrete states must include that method in their structure—even if the method results as a null one. For example, in the State 1 concrete state class, the method to go to State 3 does nothing.

Leaving the Nest and Returning

Figure 2: Basic State Transitions

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

//State Interface
package
{
	public interface IState
	{
		function goEast():void;
		function goStart():void;
	}
}
---------------
//Concrete State 1
package
{
	//Starting State;
	class StartState implements IState
	{
		private var context:Context;
		public function StartState(context:Context)
		{
			trace("--Start State--");
			this.context = context;
		}
		public function goEast():void
		{
			trace("Heading east");
			context.setState(context.getEast1State());
		}
		public function goStart():void
		{
			trace("You're already at start");
		}
	}
}
---------------
//Concrete State 2
package
{
	//East1
	class East1State implements IState
	{
		private var context:Context;
		public function East1State(context:Context)
		{
			trace("--East1--");
			this.context = context;
		}
		public function goEast():void
		{
			trace("Heading East");
                       //add code for the next eastward movement (e.g., East2)
		}
		public function goStart():void
		{
			trace("Go to starting point");
			context.setState(context.getStartState());
		}
	}
}

In looking at the IState interface, you can see that two methods (goEast() and goStart()) must be implemented by all classes that implement the interface. As you can see, the two classes do that, but they are implemented in very different ways depending on which state is the current one. If the current state is East1, the goEast1() informs the user that he/she is heading east (for the next eastward state from the Start state). In the same state, the goStart() method informs the user that the program is heading to the starting point. More importantly though is the line:

context.setState(context.getStartState());

As soon as the method is launched, it changes the current state to the next state. That means that the target state is all set for the next request as soon as it is invoked. Further, note that all state constructor functions include a Context instance.

Setting the current state in the Context is the key to understanding and using the State Design Pattern.

Of course the methods can do much more, and in more complex states all kinds of different properties and additional methods may be added.

The Context and Client

Now that you’ve seen the two states, take a look at the request mechanisms in the Context and Client classes. First, take a look at the all-important context class.

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
41
42
43
44

//Context Class
package
{
	//Context class
	class Context
	{
		private var east1State:IState;
		private var startState:IState;
		private var stateNow:IState;
 
		public function Context()
		{
			trace("States Set");
			startState = new StartState(this);
			east1State = new East1State(this);
			stateNow=startState;
		}
		public function doStart():void
		{
			stateNow.goStart();
		}
 
		public function doEast():void
		{
			stateNow.goEast();
		}
 
		public function setState(stateNow:IState):void
		{
			trace("A new state is set");
			this.stateNow=stateNow;
		}
 
		public function getStartState():IState
		{
			return this.startState;
		}
 
		public function getEast1State():IState
		{
			return this.east1State;
		}
	}
}

The Context first initializes instances of each state and a variable to hold the current state. Note that all three are initialized as interface types (IState). This allows for loose binding because the instances are not bound to a concrete class. (Remember the principle: Program to the interface; not the implementation.)

The two functions that call the state classes are essentially requests. The Client’s requests are passed through the Context’s methods that make requests through the current contextual state (stateNow).

The final three methods are getters and setters. The setter is called from the concrete states to establish the next (called) current state. Each state includes a context getter to the called state. As you can see in the two concrete states, the setter is set with the getter functions. (getEast1State(); getStartState().)

To initiate the process, you need a Client class. This one includes buttons for firing off selected states, but if you want, you can have the requests in the constructor function fired off directly without the buttons.

In any case, the requests are through the Context and even though the requests are for different states, the Context makes the requests to the concrete states through the state interface (IState.)

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

//Client
package
{
	//Test the State design pattern
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var twoState:Context=new Context();
		private var eastBtn:Button=new Button();
		private var startBtn:Button=new Button();
 
		public function Client():void
		{
			eastBtn.addEventListener(MouseEvent.CLICK,moveEast);
			eastBtn.x = 500,eastBtn.y = 200,eastBtn.width=40;
			eastBtn.label="East";
			addChild(eastBtn);
 
			startBtn.addEventListener(MouseEvent.CLICK,moveStart);
			startBtn.x = 10,startBtn.y = 10;
			startBtn.label="Start",startBtn.width=40;
			addChild(startBtn);
		}
 
		private function moveEast(e:MouseEvent):void
		{
			twoState.doEast();
		}
 
		private function moveStart(e:MouseEvent):void
		{
			twoState.doStart();
		}
	}
}

The requests are made through the context and context methods using the format:

Context.doWhatever();

such as,

twoState.doEast();

So basically, all the Client has to do is to request the implied concrete state through the context, and the results will be in terms of the current context that is self-aware. The Client doesn’t have to even think about it. It makes the requests, and the Context and states take care of the details.

Play with this first example for a while to see the information that is coming back in the trace() statements. It will keep you enthralled of a minute or two, but still it’s important to understand.

Getting Started on a Video State Game

Once you get the basics down, let’s move on to an example that is a starting point for the State Video Game. Originally when the video game was introduced in Part I of this series, each direction had its own class made up of a class to play a video (North, East, West and South—NEWS). Using a State design pattern, each concrete state will call a video. However, instead of having separate classes for each video, the concrete state will just contain a string used to specify which video will play. In the context of design patterns, the classes that are not participants in the pattern but are used to perform an oft-repeated task are called “helper classes.” For this next step, we’ll use a helper class called Distributor. It plays any f4v video using progressive download. (The commented out line will do the same for flv files.

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
41
42
43
44
45
46
47
48
49
50
51
52
53

package
{
	//This is a 'helper class'. A helper class is one that is not a 'participant' of the
	//Design Pattern, but it performs a task for one or more of the participants.
	import flash.net.NetConnection;
	import flash.net.NetStream;
	import flash.display.Sprite;
	import flash.media.Video;
	import flash.events.NetStatusEvent;
 
	public class Distributor extends Sprite
	{
		private var nc:NetConnection = new NetConnection();
		private var ns:NetStream;
		private var vid:Video=new Video();
		private var hookup:Boolean;
		private var dir:String;
		private var sniffer:Object=new Object();
 
		public function Distributor(vidName:String)
		{
			dir="vids/"+vidName+".f4v";
			//dir="vids/"+vidName+".flv";
			nc.addEventListener(NetStatusEvent.NET_STATUS,doConnect);
			nc.connect(null);
			vid.x=137.5, vid.y=80;
		}
 
		private function doConnect(e:NetStatusEvent):void
		{
			hookup=(e.info.code=="NetConnection.Connect.Success");
			if (hookup)
			{
				ns=new NetStream(nc);
				ns.client=sniffer;
				sniffer.onMetaData=getMeta;
				vid.attachNetStream(ns);
				ns.play(dir);
				addChild(vid);
			}
		}
 
		private function getMeta (mdata:Object):void
		{
			//Use if metadata required
		}
 
		public function stopHere():void
		{
			ns.close();
		}
	}
}

The string variable dir is the file name of the requested video. (Think of dir as short for “direction.”) It includes a stop method (the stopHere() function), but it has not been implemented in the rest of the application yet. As a result, the current video will not stop when the next one is selected. In the next (and last) post in this series, that will be included.

Because the states are playing videos, the IState methods need to return something other than void. Because the Distribution class extends Sprite, we know that we can create a Sprite object and return a variable that instantiates Distribution (and the video it’s playing) to the Client and the screen for viewing. So, first of all, we’ll look at the IState interface and its concrete implementations.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

//State Interface
package
{
	import flash.display.Sprite;
	public interface IState
	{
		function goEast():Sprite;
		function goStart():Sprite;
	}
}
---------------------
//Start State
package
{
	import flash.display.Sprite;
 
	//Starting State;
	class StartState implements IState
	{
		private var context:Context;
		private var vidNow:Sprite;
		private var nullSprite:Sprite=new Sprite();
 
		public function StartState(context:Context)
		{
			trace("--Start State--");
			this.context = context;
		}
		public function goEast():Sprite
		{
			trace("Heading east");
			vidNow = new Distributor("east1");
			context.setState(context.getEast1State());
			return vidNow;
		}
		public function goStart():Sprite
		{
			trace("You're already at start");
			vidNow = nullSprite;
			return vidNow;
		}
	}
}
---------------------
//East1 State
package
{
	import flash.display.Sprite;
 
	//East
	class East1State implements IState
	{
		private var context:Context;
		private var vidNow:Sprite;
		private var nullSprite:Sprite=new Sprite();
 
		public function East1State(context:Context)
		{
			trace("--East1--");
			this.context = context;
		}
		public function goEast():Sprite
		{
			//Going east would require entering into a new state
			//Relative to the starting state, the second eastward
			//move is "east2";
			//vidNow = new Distributor("east2");
			trace("heading east")
			return nullSprite;
			//The following would have to be first built
			//context.setState(context.getEast2State());
		}
		public function goStart():Sprite
		{
			vidNow = new Distributor("intro");
			trace("Go to starting point");
			context.setState(context.getStartState());
			return vidNow;
		}
	}
}

Because the return is expecting a Sprite, I created a “null sprite.” It’s simply an instantiated Sprite object with no content. The return null worked, but it threw an error, and a quick fix without adding error handlers was to create an “empty” Sprite object.

Next, the Context class is changed little from the original. However, the initial state is set to East1 and then the constructor class in the Client calls the StartState to change the current state to the StartState and plays the start video. Otherwise, the Context class is very similar to the original:

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
41
42
43
44
45

package
{
	//Context class
 
	import flash.display.Sprite;
	class Context
	{
		private var east1State:IState;
		private var startState:IState;
		private var stateNow:IState;
 
		public function Context()
		{
			trace("States Set");
			startState = new StartState(this);
			east1State = new East1State(this);
			stateNow = east1State;
		}
		public function doStart():Sprite
		{
			return stateNow.goStart();
		}
 
		public function doEast():Sprite
		{
			return stateNow.goEast();
		}
 
		public function setState(stateNow:IState):void
		{
			trace("A new state is set");
			this.stateNow = stateNow;
		}
 
		public function getStartState():IState
		{
			return this.startState;
		}
 
		public function getEast1State():IState
		{
			return this.east1State;
		}
	}
}

All of the trace() statements have been left in place so you can see what’s happening under the hood while playing the videos requested.

Finally, the Client class makes requests while adding them to the stage. It too is very similar to the original abstract example:

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var twoState:Context=new Context();
		private var eastBtn:Button=new Button();
		private var startBtn:Button=new Button();
 
		public function Client():void
		{
			addChild(twoState.doStart());
			eastBtn.addEventListener(MouseEvent.CLICK,moveEast);
			eastBtn.x = 500,eastBtn.y = 200;
			eastBtn.label = "East", eastBtn.width=40;
			addChild(eastBtn);
 
			startBtn.addEventListener(MouseEvent.CLICK,moveStart);
			startBtn.x = 10,startBtn.y = 20;
			startBtn.label = "Start",startBtn.width=40;
			addChild(startBtn);
		}
 
		private function moveEast(e:MouseEvent):void
		{
			addChild(twoState.doEast());
		}
 
		private function moveStart(e:MouseEvent):void
		{
			addChild(twoState.doStart());
		}
	}
}

In the constructor function, the statement,

addChild(twoState.doStart());

has been added to kick start the Start video and then set the StartState to the current state. Because the Context was changed to make East1State the current state, this line re-sets the StartState to the current one.

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.

The Client, the UI and Requests

Like any good Client class, this client takes care of the UI and makes requests from other classes. Most of it is just providing a non-conditonal and non-linear solution.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

package
{
	import fl.controls.Button;
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var dummy:Sprite=new Sprite();
		private var nBtn:Button=new Button();
		private var eBtn:Button=new Button();
		private var wBtn:Button=new Button();
		private var sBtn:Button=new Button();
		private var north:North;
		private var east:East;
		private var west:West;
		private var south:South;
 
		public function Client()
		{
			nBtn.addEventListener(MouseEvent.CLICK,goNorth);
			nBtn.width=70;
			nBtn.x=(550/2)-(nBtn.width/2),nBtn.y=10;
			nBtn.label = "North";
			addChild(nBtn);
 
			eBtn.addEventListener(MouseEvent.CLICK,goEast);
			eBtn.width=70;
			eBtn.x=550-(eBtn.width+5),eBtn.y=210;
			eBtn.label = "East";
			addChild(eBtn);
 
			wBtn.addEventListener(MouseEvent.CLICK,goWest);
			wBtn.width=70;
			wBtn.x = 5,wBtn.y = 210;
			wBtn.label = "West";
			addChild(wBtn);
 
			sBtn.addEventListener(MouseEvent.CLICK,goSouth);
			sBtn.width=70;
			sBtn.x=(550/2)-(sBtn.width/2),sBtn.y=370;
			sBtn.label = "South";
			addChild(sBtn);
		}
 
		private function goNorth(e:MouseEvent)
		{
			north=new North();
			addChild(north);
		}
 
		private function goEast(e:MouseEvent)
		{
			east=new East();
			addChild(east);
		}
 
		private function goWest(e:MouseEvent)
		{
			west=new West();
			addChild(west);
		}
 
		private function goSouth(e:MouseEvent)
		{
			south=new South();
			addChild(south);
		}
	}
}

As you can see from the Client and testing the app, the Client just fires a function that calls one of four classes that run a video. The user makes requests through the buttons that fire methods that call classes. These classes contain what’s required for each of the four states. We’ll use North as a generic example. (The other three classes are identical except for the name of the video they call.)

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
41
42
43

package
{
	import flash.net.NetConnection;
	import flash.net.NetStream;
	import flash.display.Sprite;
	import flash.media.Video;
	import flash.events.NetStatusEvent;
 
	public class North extends Sprite
	{
		private var nc:NetConnection = new NetConnection();
		private var ns:NetStream;
		private var vid:Video=new Video();
		private var hookup:Boolean;
		private var dir:String="north.f4v";
		private var sniffer:Object=new Object();
 
		public function North()
		{
			nc.addEventListener(NetStatusEvent.NET_STATUS,doConnect);
			nc.connect(null);
			vid.x=137.5, vid.y=80;
		}
 
		private function doConnect(e:NetStatusEvent):void
		{
			hookup=(e.info.code=="NetConnection.Connect.Success");
			if (hookup)
			{
				ns=new NetStream(nc);
				ns.client=sniffer;
				sniffer.onMetaData=getMeta;
				vid.attachNetStream(ns);
				ns.play(dir);
				addChild(vid);
			}
		}
		private function getMeta (mdata:Object):void
		{
			//Use if metadata required
		}
	}
}

The sharp-eyed among you will have spotted the conditional statement. It is fired by the NetConnection.Connect method and is more of a good practice than anything else. I could probably get away without it given that the videos are so small and load quickly; however, it is a good practice to check to make sure that a video is connected. So rather than trying to prove a point at the expense of a good practice, I’ll allow this one conditional to check connections and preserve a good practice. (I’ll also be tracking down another way to do the same thing without a conditional.)

You may be thinking that you could do the whole thing in the Client class by stuffing all the required methods and properties into the Client. You’d be right. In fact, while you’re at it you could stuff improvements in error checking and remove each video as a new one was played. However, as you put more and more into a class, you cease to delegate and continue to bind. Re-use and change becomes difficult because the less delegation you use, the more dependencies you stack up.

Next week, we’ll see how to refactor this set of classes into a state machine and a State design pattern. The State design pattern has a magic Context participant and other features that you’ll enjoy when you begin to abandon linear thinking and give OOP thinking a go.

Figure 1: Tour through State Design Pattern

As you can see it’s pretty simple—sort of a PowerPoint chat. (Nowhere near as flexible as the one created with the Memento pattern.) So, if you’re interested in a mild tour, click the Play button and hop on:

By the way, the Catalyst project has made me far more aware of Flash Builder/Flex code. It uses Flex in its engine. If you’re interested in Catalyst, you can download the Beta at Adobe Labs. I tried importing programs (SWF files) made with design patterns, and it works great. About the only thing I didn’t do with this tour is to put the videos on Flash Media Server—sorry. I was in a hurry and wasn’t sure how to link up FMS to Catalyst. I could have written the code in Flash/Flex and created an SWF file to import into Catalyst, and that works fine, but I’m pretty pressed for time on this project.

As always, your comments and valuable feedback is encouraged. I’ll be back working on this blog as soon as I’m finished with the Catalyst project. Besides, Chandima has been writing knock-out posts to keep you interested!

Helper Class is Helped

Playing the Game by the Rules: First Break the Rules

The nice thing about a State design pattern is that once the rules are established, you can build your algorithms and the different states invoke them according to the rules you’ve established. You can have a number of different algorithms within the State framework, and they should all work in accordance with the rules—no matter what the rules are or what algorithms you use to invoke them.

To see if the revised game follows the movement rules, try and break the rules. The main rule that you can attempt to break is the No reverse without stopping rule. So if you’re going right and you press the Left button, your helicopter should first stop and then you’d have to press the Left button a second time. Or you can reverse direction by pressing the Stop button and then press the opposite direction. Click the Play button to give it a whirl:

So go ahead and try to break the rules! If you can; then the design fails. If not, it succeeds. Once you’re finishing playing, download the latest code and see how the rules were applied.

Revising the Mover Class

To make it easier, the Mover class was revised so that the Timer was a property of a parent class (TimeMachine) that the Mover could use. This would provide a single source for the properties that could be inherited and used by the Mover to start and stop specific Timer instances used to move the helicopter.

1
2
3
4
5
6
7
8
9
10
11
12
13

package
{
	//Sort of an Abstract class
	//(But not really!)
	import flash.utils.Timer;
	public class TimeMachine
	{
		protected var timeRight:Timer=new Timer(5);
		protected var timeLeft:Timer=new Timer(5);
		protected var timeDown:Timer=new Timer(5);
		protected var timeUp:Timer=new Timer(5);
	}
}

All the TimeMachine does is create some properties, and even though it looks like an abstract class or interface, the properties are all instantiated and the Timer is set with a value. (Okay, so it’s concrete.)

Now that the Mover class has some inherited properties that are locked and loaded, it can focus on some simple algorithms to move the helicopter, as you can see in the following listing:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

package
{
	import flash.events.TimerEvent;
	import flash.display.Sprite;
 
	public class Mover extends TimeMachine
	{
		private var sp:Sprite;
 
		//Go to the right
		public function goRight(sp:Sprite):void
		{
			timeUp.stop();
			timeDown.stop();
			this.sp=sp;
			timeRight.addEventListener("timer",doRight);
			timeRight.start();
		}
 
		private function doRight(e:TimerEvent):void
		{
			sp.x++;
		}
		//Go to the left
		public function goLeft(sp:Sprite):void
		{
			timeUp.stop();
			timeDown.stop();
			this.sp=sp;
			timeLeft.addEventListener("timer",doLeft);
			timeLeft.start();
		}
 
		private function doLeft(e:TimerEvent):void
		{
			sp.x--;
		}
		//Go up
		public function goUp(sp:Sprite):void
		{
			timeRight.stop();
			timeLeft.stop();
			this.sp=sp;
			timeUp.addEventListener("timer",doUp);
			timeUp.start();
		}
 
		private function doUp(e:TimerEvent):void
		{
			sp.y--;
		}
		//Go down
		public function goDown(sp:Sprite):void
		{
			timeRight.stop();
			timeLeft.stop();
			this.sp=sp;
			timeDown.addEventListener("timer",doDown);
			timeDown.start();
		}
 
		private function doDown(e:TimerEvent):void
		{
			sp.y++;
		}
 
		//Stop everything
		public function goStop(sp:Sprite):void
		{
			timeRight.stop();
			timeLeft.stop();
			timeUp.stop();
			timeDown.stop();
		}
	}
}

With its new set of properties, the Mover class can more easily keep track of which timers are running and which are stopped. Also, it can follow the rules laid out for movement and minimize unnecessarily stopping timers for a given state. For example, in the MoveDown state, the helicopter can not go directly to the MoveUp state. So the goDown() method does not have to include timeUp.stop() because that timer has already been stopped because it had to go to the Stop state first (which invokes the goStop() method in the Mover class) resulting in all timer instances to stop.

Walking through a Change of State

The changes made following a change of state may help you see how everything works together. So we’ll begin in the client with a Right button press and follow it through to where the helicopter is moved or stopped. (Keep in mind that the default state is Stop.)

//Client–request right movement from Stop state
private function doRight(e:MouseEvent):void
{
        //contextNow is Context instance
        contextNow.rightMove();
}
———–
//Context
public function rightMove():void
{
        //stateNow is a State instance
        stateNow.doMoveRight();
}
———–
//State > Stop

//context = Context instance
//context.mover = Mover object that
//is a property of the Context class
//context.chopper = Helicopter instance that
//is property of the Context class

public function doMoveRight():void
{
        context.mover.goRight(context.chopper);
        context.setState(context.getRight());
}
———–
//Mover class

public function goRight(sp:Sprite):void
{
        timeUp.stop();
        timeDown.stop();
        this.sp=sp;
        timeRight.addEventListener(“timer”,doRight);
        timeRight.start();
}
———–
private function doRight(e:TimerEvent):void
{
         sp.x++;
}

While that process is going on, a new State is set and held in the Context class. It is now ready for the next move—whatever it may be.

Bring on the Algorithms, but Don’t Forget this Stated as an Aggregation!

I know there are a lot of algorithm whizzes out there, and please feel free to provide algorithms that you think are more elegant, smarter or just plain better than what I cobbled together. However, please keep in mind that this discussion began because I was hoping to show how aggregation works in composition.

Also, why not add more states? You could add states to pick up and drop off aid supplies with the helicopter, for example. Or you could have states where a friendly Martian flying saucers help out in the first Intergalactic Aid effort!

Fixing a State Design Pattern

In a recent post to illustrate the use of composition and delegation, I created a simple game using a State design Pattern—the Aid Game. A lot of people had lots of questions and suggestions for making it better and being one who thrives on improvement and change, I promised to have a post where we’d review it as a State design pattern and not a quick and dirty example of composition.

In this post I’d like to go over some key elements of a State design and to see if we can improve on the original Aid Game by better design of state classes. Also, I’m going to leave the final repairs up to you—I’ll provide some guidelines for improved states, and you can implement them. Also, I’ll provide a little helper class that is an example of continuous movement based on one from our book that Chandima used to illustrate MVC. (I simplified it from the original; so if you look at the MVC chapter—Chapter 12—, you’ll only see pieces of it.)

Why a State Design and What are the States?

To get started, we have to ask the same key question that we should ask for every design we do. Namely,

What varies?

In moving the helicopter around in the Aid Game, the main thing that varies is the state of flight. (Each of the different directions and a stopped state represents a variation in state.) Ergo, I selected the State Design Pattern.

In our simple State design, I used five different states:

1. Stop
2. Move Right
3. Move Left
4. Move Up
5. Move Down

Next, I’ll add some rules that were not in the first version:

• Before reversing direction, you must first go to the Stop state.
• If a current state is called, it cannot invoke itself.
• Movement is continuous

Let’s look at these rules applied to the Move Right state:

• Stop—call Stop state
• Left —call Stop state (Cannot reverse direction—must stop first)
• Right—already moving right–null operation
• Up—call Up state
• Down—call Down state

In the initial version, (The Aid Game) states called themselves, but that’s not allowed now. So, you can change the states to reflect these new rules.

The final rule is really one that better reflects state—continuous movement. To reflect this new game characteristic I put together a simple helper class, Mover. Using this class, the helicopter keeps a constant state moving left, right, up, down or stop.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

package
{
	import flash.utils.Timer;
	import flash.events.TimerEvent;
	import flash.display.Sprite;
 
	public class Mover extends Sprite
	{
		private var timeOn:Timer=new Timer(1000/200);
		private var sp:Sprite;
 
		//Go to the right
		public function goRight(sp:Sprite):void
		{
			timeOn.stop();
			this.sp=sp;
			timeOn.addEventListener("timer",doRight);
			timeOn.start();
		}
 
		private function doRight(e:TimerEvent):void
		{
			sp.x++;
		}
		//Go to the left
		public function goLeft(sp:Sprite):void
		{
			timeOn.stop();
			this.sp=sp;
			timeOn.addEventListener("timer",doLeft);
			timeOn.start();
		}
 
		private function doLeft(e:TimerEvent):void
		{
			sp.x--;
		}
		//Go up
		public function goUp(sp:Sprite):void
		{
			timeOn.stop();
			this.sp=sp;
			timeOn.addEventListener("timer",doUp);
			timeOn.start();
		}
 
		private function doUp(e:TimerEvent):void
		{
			sp.y--;
		}
		//Go down
		public function goDown(sp:Sprite):void
		{
			timeOn.stop();
			this.sp=sp;
			timeOn.addEventListener("timer",doDown);
			timeOn.start();
		}
 
		private function doDown(e:TimerEvent):void
		{
			sp.y++;
		}
 
		//Stop everything
		public function goStop(sp:Sprite):void
		{
			timeOn.stop();
			this.sp=sp;
			sp.x=sp.x;
			sp.y=sp.y;
		}
	}
}

You don’t have to use that class, and if you want you can put the operations in the individual states. However, to see how it works, test it out with the helicopter in the Aid Game. Then you can decide whether you want to use it or not. Generally, I’d assume that you’d have some way of invoking movement through the Context by a call in the State child classes.

Let’s See What You’ve Made

Okay, now’s a good chance to implement those algorithms. Put them into the State structure and let’s see how you’ve repaired the state machine. We’re not looking for a better algorithm per se, but rather how it can be used with the State design pattern. It doesn’t have to be ready for prime it, but it must be invoked within the context of the State design. (By the way, did you notice that there are no conditional statements in the State design?)

Take This One to Work

I decided that a good starting point would be to have a helicopter fly aid packages to different places on the screen. It would start at the airport and then fly the aid to different sprite objects representing groups of people in need. However, to get started, all I did was to set up five buttons to move the helicopter around the screen beginning at the airport. Figure 1 shows what the game looks like. (It is set up on an 800 by 600 display; so I had to cut off part of the right side to fit in this blog format.) The movement buttons are in the lower left portion of the screen.

Figure 1: State Pattern moves Helicopter Object

Click on the Play button to get an idea of how it works:

The Little State Engine that Could

The concept of a state machine or state engine brings the focus to changing states. Each state is delegated to a separate class, and as an object’s state changes, the state is handled by (delegated to) the appropriate class. In order to keep track of the current state, all requests are handled by a Context class. The Context class acts as an interface for the Client, and so the Client need not deal with the State objects directly. Figure 2 shows the class diagram for the State pattern.

Figure 2: State Design Pattern Class Diagram

If you look at the class diagram, you may be thinking that it looks a lot like the Strategy design pattern. You’d be right! They look very similar, but their intent is quite different. In the class diagram, you’ll see the little red state label. Therein lies the difference between the State and Strategy patterns. The State pattern delegates different states and the Strategy pattern delegates different algorithms. Thus, the intent is quite different even though the class diagrams are similar.

Direction and Movement

In the past, I’ve used State designs for doing work with video players changing states such as play, record, pause and stop. For this one, I wanted to change directions of a moving object, and I selected a relatively simple design for changing the direction (movement state) of a helicopter. Using the vertical plane of a computer monitor for a reference point, the movement states are up, down, left, right, and stop. I used a very simple movement algorithm—the helicopter crabs along at 8 pixels per button click. (If you’re interested in more robust movement, see page 458 where Chandima has a nice algorithm for moving along continuously.) Remember, the purpose of this blog is to help understand design patterns, and so we try to focus on relatively clean examples. Once you get the design pattern down, it’s easy to add some really great algorithms.

With that in mind, I created the different classes for each of the different states along with classes for a Client and Context that work with a State interface. Figure 3 shows the file class diagram for the example:

Figure 3: State File Class Diagram

The Client requests are through the Context class. In turn, the Context class contains the moving object (chopper) as a property, and so it’s available to the different concrete state classes that change its state.

The Delegation Master

When working with the State Design Pattern, the state files tend to grow with added states. That’s because each state class must have the complete interface of the State class, which means all of the states. So, to save some time, I’ve put it online for you in CS3 and CS4 files. If you’re using Flex (Flash Builder) all you’ll need is a sprite object for the helicopter and the graphics you can see in Figure 1.) Click the Download button to get all of the files you need:

Okay, we’re all set to look at the Context class. The role of the Context class is to keep track of the current state and set the state requested by the Client.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

package
{
	//Context class
	import flash.display.Sprite;
 
	class Context
	{
		private var stoph:State;
		private var moveup:State;
		private var movedown:State;
		private var moveleft:State;
		private var moveright:State;
		private var stateNow:State;
		public var chopper:Sprite;
 
		public function Context( chopper:Sprite )
		{
			this.chopper=chopper;
			trace("State is here");
			moveup=new MoveUp(this);
			stoph=new Stop(this);
			movedown=new MoveDown(this);
			moveleft=new MoveLeft(this);
			moveright=new MoveRight(this);
			stateNow=stoph;
		}
		public function upMove():void
		{
			stateNow.doMoveUp();
		}
		public function stopMove():void
		{
			stateNow.doStopNow();
		}
		public function downMove():void
		{
			stateNow.doMoveDown();
		}
		public function leftMove():void
		{
			stateNow.doMoveLeft();
		}
		public function rightMove():void
		{
			stateNow.doMoveRight();
		}
 
		public function setState(stateNow:State):void
		{
			trace("A new stateNow is set:");
			this.stateNow=stateNow;
		}
		public function getState():State
		{
			return stateNow;
		}
		public function getUp():State
		{
			return this.moveup;
		}
		public function getStop():State
		{
			return this.stoph;
		}
		public function getDown():State
		{
			return this.movedown;
		}
 
		public function getLeft():State
		{
			return this.moveleft;
		}
 
		public function getRight():State
		{
			return this.moveright;
		}
	}
}

The “chopper” is the helicopter object passed from the Client through a parameter. It is typed to the Sprite parent (interface) to follow the principle of programming to the interface instead of the implementation. In Flash, the Helicopter class is in the Library, while in Flex, you can put it anywhere you want as long as it can be instantiated in the Client as a Sprite type and passed to the Context class.

As you can see, several variables are initialized as State objects. The default state is Stop, and so when the program starts, the chopper object is in the stop state. Then, you will see a series of setter functions such as:

1
2
3
4

public function leftMove():void
{
	stateNow.doMoveLeft();
}

Such setter functions are called from the Client, but the Client never sees the concrete state object that they are delegated to by the Context. The Context passes on the request to another function that sets the current state and calls the requested state. Voila! Delegation at work.

The States

The next step is to set up a State interface with all of the different methods that will be set up in each state. That’s easy because we are using an ActionScript interface, and not the more general interface that is virtually any parent class.

1
2
3
4
5
6
7
8
9
10
11

package
{
	//Interface
	public interface State
	{
		function doMoveUp():void;
		function doMoveDown():void;
		function doStopNow():void;
		function doMoveLeft():void;
		function doMoveRight():void;
	}

Next, each of the concrete state classes must implement the full interface. However, only certain methods are used in each state to implement the state. The way I chose to implement the state was in the state itself. What results is that when the state is initially called, nothing happens because that current state (or calling state) does not contain the new state. This is a bit different from other state designs I’ve done, but it works well enough when the state change is movement. The following listing contains all of the five states:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191

package
{
	//MoveDown State;
	class MoveDown implements State
	{
		//private var chopper:Sprite=new Helicopter();
		private var context:Context;
 
		public function MoveDown(context:Context)
		{
			trace("--MoveDown State--");
			this.context=context;
		}
		public function doMoveUp():void
		{
			context.setState(context.getUp());
		}
		public function doStopNow():void
		{
			context.setState(context.getStop());
		}
		public function doMoveDown():void
		{
			context.chopper.y+=8;
			context.setState(context.getDown());
		}
		public function doMoveLeft():void
		{
			context.setState(context.getLeft());
		}
		public function doMoveRight():void
		{
			context.setState(context.getRight());
		}
 
	}
}
 
/////
 
package
{
	//MoveLeft State;
	class MoveLeft implements State
	{
		private var context:Context;
 
		public function MoveLeft(context:Context)
		{
			trace("--MoveLeft State--");
			this.context=context;
		}
		public function doMoveUp():void
		{
			context.setState(context.getUp());
		}
		public function doStopNow():void
		{
			context.setState(context.getStop());
		}
		public function doMoveDown():void
		{
			context.setState(context.getDown());
		}
		public function doMoveLeft():void
		{
			context.chopper.x-=8;
			context.setState(context.getLeft());
		}
		public function doMoveRight():void
		{
			context.setState(context.getRight());
		}
 
	}
}
 
/////
 
package
{
	//MoveRight State;
	class MoveRight implements State
	{
		private var context:Context;
 
		public function MoveRight(context:Context)
		{
			trace("--MoveRight State--");
			this.context=context;
		}
		public function doMoveUp():void
		{
			context.setState(context.getUp());
		}
		public function doStopNow():void
		{
			context.setState(context.getStop());
		}
		public function doMoveDown():void
		{
			context.setState(context.getDown());
		}
		public function doMoveLeft():void
		{
			context.setState(context.getLeft());
		}
		public function doMoveRight():void
		{
			context.chopper.x+=8;
			context.setState(context.getRight());
		}
	}
}
 
/////
 
package
{
	//MoveUp State;
	class MoveUp implements State
	{
		private var context:Context;
 
		public function MoveUp(context:Context)
		{
			trace("--MoveUp State--");
			this.context=context;
		}
		public function doMoveUp():void
		{
			context.chopper.y-=8;
			context.setState(context.getUp());
		}
		public function doStopNow():void
		{
			context.setState(context.getStop());
		}
		public function doMoveDown():void
		{
			context.setState(context.getDown());
		}
		public function doMoveLeft():void
		{
			context.setState(context.getLeft());
		}
		public function doMoveRight():void
		{
			context.setState(context.getRight());
		}
 
	}
}
 
/////
 
package
{
	//Stop State;
	class Stop implements State
	{
		private var context:Context;
 
		public function Stop(context:Context)
		{
			trace("--Stop State--");
			this.context=context;
		}
		public function doMoveUp():void
		{
			context.setState(context.getUp());
		}
		public function doStopNow():void
		{
			context.setState(context.getStop());
		}
		public function doMoveDown():void
		{
			context.setState(context.getDown());
		}
		public function doMoveLeft():void
		{
			context.setState(context.getLeft());
		}
		public function doMoveRight():void
		{
			context.setState(context.getRight());
		}
 
	}
}

Each movement state simply increments or decrements the relative value of the x and y properties of the chopper. So while it may look complex, it really is not. Also, it is very easy to change; so if you want to add continuous movement, you should be able to do so.

The Client

This particular Client could have been set up to get all of its buttons elsewhere, but otherwise, all it does is to fire off event handlers to make requests. However, it is essential that it begins by instantiating a Helicopter instance that it passes to the Context class through a Sprite typed parameter. So, the Client, never even talks to the state objects. Instead, it just sends all requests for changing the direction and movement of the Helicopter instance through the Context.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

package
{
	//Client makes requests
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		public var chopper:Sprite=new Helicopter();
		private var contextNow:Context=new Context(chopper);
 
		private var upBtn:Button=new Button();
		private var downBtn:Button=new Button();
		private var stopBtn:Button=new Button();
		private var leftBtn:Button=new Button();
		private var rightBtn:Button=new Button();
		private var testBtn:Button=new Button();
 
		private const AEROPORTX:Number=84;
		private const AEROPORTY:Number=64;
 
		public function Client()
		{
			chopper.x=AEROPORTX,chopper.y=AEROPORTY,
			addChild(chopper);
 
			//Default
			contextNow.stopMove();
 
			upBtn.x=132,upBtn.y=465;
			upBtn.width=45, upBtn.height=25;
			upBtn.label="Up";
			upBtn.addEventListener(MouseEvent.CLICK, doUp);
			addChild(upBtn);
 
			stopBtn.x=132,stopBtn.y=513;
			stopBtn.width=45,stopBtn.height=25;
			stopBtn.label="Stop";
			stopBtn.addEventListener(MouseEvent.CLICK, doStop);
			addChild(stopBtn);
 
			downBtn.x=132,downBtn.y=561;
			downBtn.width=45,downBtn.height=25;
			downBtn.label="Down";
			downBtn.addEventListener(MouseEvent.CLICK, doDown);
			addChild(downBtn);
 
			leftBtn.x=69,leftBtn.y=513;
			leftBtn.width=45,leftBtn.height=25;
			leftBtn.label="Left";
			leftBtn.addEventListener(MouseEvent.CLICK, doLeft);
			addChild(leftBtn);
 
			rightBtn.x=200,rightBtn.y=513;
			rightBtn.width=45,rightBtn.height=25;
			rightBtn.label="Right";
			rightBtn.addEventListener(MouseEvent.CLICK, doRight);
			addChild(rightBtn);
		}
 
		private function doUp(e:MouseEvent):void
		{
			contextNow.upMove();
		}
 
		private function doStop(e:MouseEvent):void
		{
			contextNow.stopMove();
		}
 
		private function doDown(e:MouseEvent):void
		{
			contextNow.downMove();
		}
 
		private function doLeft(e:MouseEvent):void
		{
			contextNow.leftMove();
		}
 
		private function doRight(e:MouseEvent):void
		{
			contextNow.rightMove();
		}
	}
}

As you can see, it can make five different requests based on the button event handlers, and all of them are through Context methods (e.g., contextNow.rightMove()).

Because the example is so simple, you may be thinking that you could have done the same thing with a single class and not an exhaustive amount of code. You’d be absolutely right. Also, you would not lose an ounce of functionality. However, the focus of this example is to see how delegation is used and how easy it would be to use the exact same code for all different kinds of movement. Further, you could re-use the code for moving as many objects as you wanted. Because the entire program is so loosely coupled, substitution and change is very simple.

Anyway, you can do a lot with the State Design Pattern. For starters, why not improve on this little application and turn it into a game? Fo example, you could add an independent sprite to be picked up at the airport and dropped at the 10 different locations. Add one timer for continuous movement and another for keeping score of how fast you could move all of the aid packages to the needy orange sprites.

This might be a good resource for our next Golden LunchBox contest!

Here Comes the Big Bad State Machine

Before we get going on refactoring the video player application, we need to see where it will go in the context of both the State and the Factory Method design patterns. Figure 1 shows the relationship between the refactored player (State) and the factory that delivers the data (Factory Method).

Figure 1: Files for two design patterns in class diagram

The images are organized in an “open” folder, and the videos are placed in separate folders showing their relative position to the classes making up the two design patterns. The Client makes a request through the Factory Method to populate a List component with data from a DataProvider. Then, the request from the Client to the player can be made through the List component by clicking on the video selection. Figure 2 shows what the final product looks like so that you can more easily follow the refactoring:

Figure 2: Selected video running in state machine player

If Figure 2 looks different from what we started in Part I of this article, it’s because the application changed. Originally, the plan was to take the application made for showing F4V files (H.264 formatted HD files) using the latest version of Flash Media Server (FMS) and show how it was refactored. However, since most readers do not develop with FMS, the plan was changed to show a progressive download application that anyone could use. The State design pattern is almost identical to the one used in our book to develop a player. Likewise, we don’t plan to try your patience by rehashing Chapter 10 or the article on DevNet that cover statecharts, the details of state machines and the State Design Pattern. Instead, I’d like to focus on the Client and show how it makes requests to different sets of classes using different design patterns. Therefore, I’ll only briefly go over the State Design Pattern to help you orient yourself to its use in the current context with another design pattern.

State Machine as Time Machine

I like to imagine the state machine as a time machine. Each time represents a different state. As you go from one state to another, things look different and the possibilities are different. If you go to the mid 18th century you’ll find horse-powered transportation and in that state you’ll find no air transportation beyond hot air balloons. Conversely, if you go into the future to the 22nd century you may find transportation that runs only on hydrogen and air travel only occurs beyond the stratosphere. In different time periods you expect different capabilities. Likewise, in different states, you have different expectations. For example, in the video player, if you are in a stop state you cannot stop. That’s because in that state, you’re already stopped. Likewise, in a play state you cannot go to play, because you’re already there.

Some states are trickier than others, but you have options. In one video player I made, I would not allow the user to go from Pause to Play or Stop. The user had to first Un-Pause by going to Pause again. That was when the main Pause state was set up as a toggle. One blogger complained that he just couldn’t deal with a Player that would not allow one to go from Pause to Stop or Play. The reason behind my decision was that some funny things happened when one left the Pause state without un-pausing it first. (Now that ActionScript 3.0 has a NetStream.resume() method, the toggle is no longer required.) Of course, if one decides that it’s perfectly fine to go from a Pause state to a Play or Stop; all you’ve got to do is to change the code in the Pause state—in fact it’s really easy to do and is one of the advantages of the State Design Pattern. (In case you haven’t noticed, I have no god-like powers to enforce code decisions—you’re programmers; so change the code all you want!)

By setting up your program as state machines, you have the option of easily changing the states. You can change the contents of the states (as suggested in the previous paragraph) or you can add new states. As your application changes and grows, all you need to do is to change the states to reflect the application’s functionality.

Avoiding Conditional Statements

My favorite feature of the State Design Pattern is that it has no conditional statements. Count ‘em—none. In fact, in this entire program, you’ll find only a single switch statement in the ConcreteCreatorVid class in the Factory Method pattern portion of the program. If you look at different Factory Method patterns in most languages, you’ll find that the concrete creator classes contain one or more conditional statement; so, sometime you do need them. (I’ve concealed one more conditional in the Client that takes care of a little bling, but you’ll have to search to find it—besides it doesn’t count because it’s in the Client.)

What do I have against conditional statements? Well, it’s not so much that I have anything against conditionals as it is the fact I like the idea of not using them. The State design makes you stop and think of what possibly can happen in a given state. Then instead of first having to filter through conditional statements, you simply do exactly what the current state allows. The logic flow is more pleasing and forces me to be a better programmer.

The Mighty Client

One of the original goals of refactoring my video player was to give it more flexibility and to cut down on the size of a single big class—essentially a huge self-serving Client. The idea of the Client is to make requests, and it should not be used as an everything class. Several design patterns include the Client as a participant, but even they recognize the role of the Client as a request-maker.

In Figure 1, you can see that the Client makes requests through the Creator interface in the Factory Method pattern and through the Context class in the State pattern. A Client making requests from multiple classes or interfaces is not unusual—consider the Abstract Factory pattern. The request-making involves a set of UIs for different data sets for the DataProvider object. It provides the List UI with selections used to request the different videos available for displaying in the player. The following listing shows that the great majority of the Client is taken up by UIs and methods for making request with the UIs.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177

package
{
	//Progressive Download
	import fl.controls.Button;
	import fl.controls.List;
	import fl.events.ListEvent;
	import fl.data.DataProvider;
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.net.NetConnection;
	import flash.net.NetStream;
	import flash.events.NetStatusEvent;
	import flash.media.Video;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var btnGp1:Button=new Button();
		private var btnGp2:Button=new Button();
		private var btnGp3:Button=new Button();
		private var playList:List=new List();
		private var stopBtn:Button;
		private var pauseBtn:Button;
		private var resumeBtn:Button;
		private var nc:NetConnection=new NetConnection();
		private var ns:NetStream;
		private var vid:Video = new Video();
		private var context:Context=new Context();
		private var flv:String;
		private var metaCap:Object;
		private var stopState:Boolean;
		private var mset:Boolean = false;
		private var group1:DataProvider=new DataProvider();
		private var group2:DataProvider=new DataProvider();
		private var group3:DataProvider=new DataProvider();
		private var create:Creator=new ConcreteCreatorVid();
 
		public function Client()
		{
			nc.connect(null);
			ns = new NetStream(nc);
			//Handle end of flv play status
			ns.addEventListener(NetStatusEvent.NET_STATUS,flvCheck);
 
			setUI();
			setProviders();
 
			//Set up object to capture metadata
			metaCap = new Object  ;
			ns.client = metaCap;
			metaCap.onMetaData = getMeta;
		}
 
		private function setUI():void
		{
			addChild(vid);
			vid.x = 150;
			vid.y = 50;
			vid.attachNetStream(ns);
 
			//Video Buttons and List Components
			playList.x = 20,playList.y = 50;
			addChild(playList);
 
			group1 = create.selectData("group1");
			playList.dataProvider = group1;
 
			stopBtn=new Button();
			stopBtn.label = "Stop";
			stopBtn.width = 50;
			stopBtn.x = 142,stopBtn.y = 352;
			addChild(stopBtn);
 
			pauseBtn=new Button();
			pauseBtn.label = "Pause";
			pauseBtn.width = 50;
			pauseBtn.x = 206,pauseBtn.y = 352;
			addChild(pauseBtn);
 
			resumeBtn=new Button();
			resumeBtn.label = "Resume";
			resumeBtn.width = 55;
			resumeBtn.x = 270,resumeBtn.y = 352;
			addChild(resumeBtn);
 
			//Add Event Listeners
			playList.addEventListener(ListEvent.ITEM_CLICK,doPlay);
			stopBtn.addEventListener(MouseEvent.CLICK,doStop);
			pauseBtn.addEventListener(MouseEvent.CLICK,pauseNow);
			resumeBtn.addEventListener(MouseEvent.CLICK,resumeNow);
		}
 
		private function setProviders():void
		{
			//Data provider buttons
			btnGp1.x = 20,btnGp1.y = 160;
			btnGp1.label = "Group1";
			addChild(btnGp1);
 
			btnGp2.x = 20,btnGp2.y = 190;
			btnGp2.label = "Group2";
			addChild(btnGp2);
 
			btnGp3.x = 20,btnGp3.y = 220;
			btnGp3.label = "Group3";
			addChild(btnGp3);
 
			//Add Event Listeners
			btnGp1.addEventListener(MouseEvent.CLICK,getGp1);
			btnGp2.addEventListener(MouseEvent.CLICK,getGp2);
			btnGp3.addEventListener(MouseEvent.CLICK,getGp3);
		}
 
		private function getMeta(mdata:Object):void
		{
			(mset) ? removeChildAt(0) : null;
			mset = true;
			vid.width = mdata.width;
			vid.height = mdata.height;
			var backdrop:Shape=new Shape();
			backdrop.graphics.beginFill(0x611427,1);
			backdrop.graphics.drawRect(vid.x,vid.y,vid.width,vid.height);
			addChildAt(backdrop,0);
		}
 
		private function getGp1(e:MouseEvent):void
		{
			group1 = create.selectData("group1");
			playList.dataProvider = group1;
		}
 
		private function getGp2(e:MouseEvent):void
		{
			group2 = create.selectData("group2");
			playList.dataProvider = group2;
		}
 
		private function getGp3(e:MouseEvent):void
		{
			group3 = create.selectData("group3");
			playList.dataProvider = group3;
		}
 
		private function flvCheck(e:NetStatusEvent):void
		{
			stopState=(e.info.code=="NetStream.Play.Stop");
			(stopState) ? halt():null;
		}
 
		private function halt():void
		{
			context.stopPlay(ns);
			vid.clear();
		}
 
		private function doPlay(e:ListEvent):void
		{
			flv = e.item.data;
			context.startPlay(ns,flv);
		}
 
		private function doStop(e:MouseEvent):void
		{
			halt();
		}
 
		function pauseNow(e:MouseEvent):void
		{
			context.pausePlay(ns);
		}
 
		function resumeNow(e:MouseEvent):void
		{
			context.resumePlay(ns);
		}
	}
}

I’ve got to admit that for a Client class, this one seems pretty big. However, all of the data for selecting the videos and working the video player are either part of the Factory Method or State design patterns. With only slight modifications in the Client this same player can handle FMS files, including F4V files. I’ve used this same State pattern for several different kinds of players, including the one operating FMIS 3.2 and playing high definition videos ( such as these) that we discussed in Part I of this post.

The Context Class

The Context class is the key to understanding the State Design Pattern as a pattern and not simply a state machine. When you look at it, the class appears to be nothing more than a getter/setter class. However, it is far more. It establishes which state is the current state. By setting up the current state, it provides for one of the best examples of polymorphism that can be found in OOP. The State interface provides four methods, but depending on the current concrete state class, each method is implemented differently. The following listing shows the Context class used in this example:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

package
{
	//Context Class
	import flash.net.NetStream;
 
	class Context
	{
		private var playState:State;
		private var stopState:State;
		private var pauseState:State;
		private var resumeState:State;
		private var state:State;
		public function Context()
		{
			trace("Video Player is on");
			playState = new Play(this);
			stopState = new Stop(this);
			pauseState = new Pause(this);
			resumeState = new Resume(this);
			state=stopState;
		}
		public function startPlay(ns:NetStream,flv:String):void
		{
			state.startPlay(ns,flv);
		}
		public function stopPlay(ns:NetStream):void
		{
			state.stopPlay(ns);
		}
		public function pausePlay(ns:NetStream):void
		{
			state.pausePlay(ns);
		}
		public function resumePlay(ns:NetStream):void
		{
			state.resumePlay(ns);
		}
 
		public function setState(state:State):void
		{
			trace("A new state is set");
			this.state=state;
		}
		public function getState():State
		{
			return state;
		}
		public function getPlayState():State
		{
			return this.playState;
		}
		public function getStopState():State
		{
			return this.stopState;
		}
		public function getPauseState():State
		{
			return this.pauseState;
		}
		public function getResumeState():State
		{
			return this.resumeState;
		}
	}
}

The Context class delegates requests (from the Client) to a State object. All methods either use or return a State object. The trick in the Context is to keep track of the current state so that when a requested method is returned to the Client, it is done in the appropriate manner. (e.g., a stop play request will not be sent from a stop state.)

The State Interface and the States

The state interface and the concrete states are relatively easy. Using either an interface or abstract class, the State interface provides the essential methods that can be implemented in the concrete state classes. First, the State interface shows four simple methods—playing, stopping, pausing and resuming video play:

1
2
3
4
5
6
7
8
9
10
11
12

package
{
	//State Interface
	import flash.net.NetStream;
	interface State
	{
		function startPlay(ns:NetStream,flv:String):void;
		function stopPlay(ns:NetStream):void;
		function pausePlay(ns:NetStream):void;
		function resumePlay(ns:NetStream):void;
	}
}

All of the methods have the same parameters except for the startPlay() method that has an additional string parameter for the video URL. The rest are for directing actions in the NetStream() object.

Finally, the concrete State classes that implement the State interface are set states. That means that the action associated with the state has been set so that you can possibly do whatever that state allows. For example, if you’re in the Stop state, you can go to the Play state, but since you’re already in the Stop state, it doesn’t make any sense to go there. (Think of yourself at a stop sign in traffic. You can go to “drive” but since you’re at stop, you cannot “go” there.) So, without further ado, let’s look at the four state classes:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147

package
{
	//Stop State
	import flash.net.NetStream;
 
	class Stop implements State
	{
		private var context:Context;
		public function Stop(context:Context)
		{
			trace("--Stop State--");
			this.context=context;
		}
		public function startPlay(ns:NetStream,flv:String):void
		{
			ns.play(flv);
			trace("Begin playing");
			context.setState(context.getPlayState());
		}
		public function stopPlay(ns:NetStream):void
		{
			trace("You're already stopped");
		}
		public function pausePlay(ns:NetStream):void
		{
			trace("Cannot go to Pause from Stop.");
		}
		public function resumePlay(ns:NetStream):void
		{
			trace("Cannot go to Resume from Stop.");
		}
	}
}
 
 
package
{
	//Play State
	import flash.net.NetStream;
 
	class Play implements State
	{
		private var context:Context;
		public function Play(context:Context)
		{
			trace("--Play State--");
			this.context=context;
		}
		public function startPlay(ns:NetStream,flv:String):void
		{
			trace("You're already playing");
		}
		public function stopPlay(ns:NetStream):void
		{
			ns.close();
			trace("Stop playing.");
			context.setState(context.getStopState());
		}
		public function pausePlay(ns:NetStream):void
		{
			ns.pause();
			trace("Begin pause.");
			context.setState(context.getPauseState());
		}
		public function resumePlay(ns:NetStream):void
		{
			trace("Cannot resume from a play state.");
		}
	}
}
 
 
package
{
	//Pause State
	import flash.net.NetStream;
 
	class Pause implements State
	{
		var context:Context;
		public function Pause(context:Context)
		{
			trace("--Pause State--");
			this.context=context;
		}
		public function startPlay(ns:NetStream,flv:String):void
		{
			trace("You have to go to resume");
		}
		public function stopPlay(ns:NetStream):void
		{
			trace("Don't go to Stop from Pause");
			//Allow going from Pause state to Stop state
			//ns.close();
			//context.setState(context.getStopState());
		}
		public function pausePlay(ns:NetStream):void
		{
			trace("Cannot pause from Pause state.");
		}
 
		public function resumePlay(ns:NetStream):void
		{
			ns.resume();
			trace("Quit pausing.");
			context.setState(context.getResumeState());
		}
	}
}
 
 
package
{
	//Resume
	import flash.net.NetStream;
 
	class Resume implements State
	{
		var context:Context;
		public function Resume(context:Context)
		{
			trace("--Resume State--");
			this.context=context;
		}
		public function startPlay(ns:NetStream,flv:String):void
		{
			trace("Start over");
			context.setState(context.getPlayState());
		}
		public function stopPlay(ns:NetStream):void
		{
			ns.close();
			trace("Stop playing.");
			context.setState(context.getStopState());
		}
		public function pausePlay(ns:NetStream):void
		{
			ns.pause();
			trace("Pause.");
			context.setState(context.getPauseState());
		}
		public function resumePlay(ns:NetStream):void
		{
			trace("Already in resume state.");
		}
	}
}

In addition to providing a set of methods that direct the program to the next possible set of states, the constructor function in each state class sets itself as the current state. Put differently, each state sets the current context to itself.

Using Multiple Design Patterns

Creating programs with multiple design patterns is no more unusual than writing programs with multiple methods or properties. Further, this particular application suggests that you can mix and match design patterns and reuse the major components for any number of projects. Further, the Client doesn’t know (or care) what changes are made in the different components as long as they follow the rules laid out by the interface and the request to the appropriate component in the pattern is unchanged.

The difficult part is doing it right the first time. Then, later as the program requires changes (as it always does), it’s easy to do so. Further, you can take the exact same design patterns and use them for different applications, which saves time as well.

As a final note, I’ve left several trace statements in the code to help you better see what happens in different states. Once in a given state and running the program from within either Flex or Flash, note the trace output. Also, try requesting “impossible” states—such as pressing the Stop button when the program is already stopped. Finally, if you do not like a condition placed on a state (such as disallowing movement from one state to a certain different state), go ahead and change the program.