Ever since I started working with mobile devices with Flash and ActionScript 3.0, I’ve been looking for faster ways to move my objects through those little windows on iPhones, Androids and Blackberries. Lag time is huge and the action looks geriatric. I’ve seen some interesting things done with the bitmapped classes, and in previous posts we’ve discussed what may be helpful. However, since I haven’t used them extensively (or fully), I thought it’d be a good idea to walkthrough my thinking on the topic. For a while now I’ve been working on a a Samurai action game, and while I’ve been making progress, I keep looking for speed tweaks. In general my thoughts regarding bitmapped graphics and Bitmap classes can be summed up in Figure 1. If I create a single Bitmap object using the BitmapData objects (or convert graphic files into BitmapData elements) and then clone the object, I should be able to save processing time.

Figure 1: Cloned and Colored

Second, in order for an object to look like more than a single object, I want to change something about the cloned object. With my simple samurai fighter, I can change its color because it is a Bitmap object. So, first we’ll look at how to create a bitmapped object from scratch using both the Bitmap and BitmapData objects.

Making Bitmapped Objects from Code

I like drawing bitmapped objects or using digital photography. However, in order to best understand what’s going on, let’s start from scratch with BitmapData objects. Figure 2 shows the fundamentals of creating a bitmapped data object:

Figure 2: Implementing BitmapData Object

The ActionScript 3.0 BitmapData object contains a 32-bit integer made up of four 8-bit values (0-255). The first parameter expects a width, the second height—this is the Bitmap shape; a rectangular data matrix. The third parameter is the objects transparency, which has a default value of true (it is transparent). By setting the transparency argument to false, you make the object opaque. The 32-bit integer is the final parameter with the first two hexadecimal values being the alpha value with the final six values expressing an RGB color. The following class provides a basic example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package 
{
	import flash.display.Sprite;
	import flash.display.Bitmap;
	import flash.display.BitmapData;
 
	public class Basic extends Sprite
	{
		private var burntOrange:BitmapData;
		private var burntOrangeClone:BitmapData;
		private var bm:Bitmap;
		private var bmClone:Bitmap;
 
		public function Basic()
		{
			burntOrange = new BitmapData(50, 50, false, 0x00CC5500);
			bm=new Bitmap(burntOrange);
			bm.x=100,bm.y=100;
			addChild(bm);
		}
	}
}

That’s really pretty simple. All you have to do is to define the BitmapData object and then use it as an argument in creating a new Bitmap object. At this junction we’re just making squares; however, from previous posts that have converted bitmap files into BitmapData objects, we can generate far more complex figures. For now, though, we’ll stick with the squares. When you test the code, you’ll get a nice burnt orange square. Try changing the size of the square and experiment with different colors and transparency levels.

A Clone of a BitmapData Object

The next step is to copy the implemented BitmapData object. Fortunately, the BitmapData object contains a clone() method so it’s also easy to do as you can see in the following 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

package 
{
	import flash.display.Sprite;
	import flash.display.Bitmap;
	import flash.display.BitmapData;
 
	public class Clone extends Sprite
	{
		private var burntOrange:BitmapData;
		private var burntOrangeClone:BitmapData;
		private var bm:Bitmap;
		private var bmClone:Bitmap;
 
		public function Clone()
		{
			burntOrange = new BitmapData(50, 50, false, 0x00CC5500);
			bm=new Bitmap(burntOrange);
			bm.x=100,bm.y=100;
			addChild(bm);
 
			burntOrangeClone=burntOrange.clone();
			bmClone=new Bitmap(burntOrangeClone);
			bmClone.x=200,bmClone.y=100;
			addChild(bmClone);
		}
	}
}

Original and Cloned Objects

Using BitmapData.colorTransform()

The real value in using BitmapData objects, whether clones are quicker to create than new objects, is the colorTransform() method in the BitmapData API. For this post, I am only touching on one aspect of using the method with a ColorTransform object, and that is changing colors by using the ARGB color multipliers. If I create a BitmapData object, and clone it with different colors, I’ve effectively created a new useful object. If I change the multiplier value (0-1) for the alpha channel, I change the tint of the color. Likewise, if I change the RGB values, I change the colors in those channels.

The BitmapData.colorTransform() method has two parameters, Rectangle and ColorTransform, objects available in the flash.geom package. As a result both must be imported. Both the ColorTransform and Rectangle classes may be used on their own, but here they are employed as part of a BitmapData class method with the name colorTransform(), which may be a little confusing; so bear with me here. The full format of BitmapData.colorTransform() is BitmapData.colorTransform(Rectangle, ColorTransform). The following program will be the starting point:

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

package 
{
 
	import flash.display.Sprite;
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.geom.Rectangle;
	import flash.geom.ColorTransform;
 
	public class CloneColorTransform extends Sprite
	{
		private var burntOrange:BitmapData;
		private var burntOrangeClone:BitmapData;
		private var bm:Bitmap;
		private var bmClone:Bitmap;
		private var clrTransform:ColorTransform;
		private var rect:Rectangle;
 
		public function CloneColorTransform()
		{
			burntOrange = new BitmapData(50,50,false,0x00CC5500);
			bm = new Bitmap(burntOrange);
			bm.x = 100,bm.y = 100;
			addChild(bm);
 
			burntOrangeClone = burntOrange.clone();
			clrTransform=new ColorTransform();
			clrTransform.alphaMultiplier=0.75;
			//clrTransform.redMultiplier=0.0;
			//clrTransform.greenMultiplier=0.0;
			//clrTransform.blueMultiplier=0.0;
			rect=new Rectangle(0,0,50,50);
			burntOrangeClone.colorTransform(rect,clrTransform);
			bmClone = new Bitmap(burntOrangeClone);
			bmClone.x = 200,bmClone.y = 100;
			addChild(bmClone);
		}
	}
}

In the code, notice that the BitmapData and Rectangle instances both have the same 50 x 50 size. That is very important lest you end up with strange results. The first two parameters of the Rectangle object are the x and y position values. The results (seen at the right) illustrate how to change a cloned object’s tint based on the original tint. Try changing the alpha multiplier to see how to tint the color darker or lighter. Also note that even thought the clone is identical except for the tint, it is clearly distinguishable as different even though the same BitmapData values were employed in both.

Changing Colors of Images from Bitmap Files

The real payoff for using BitmapData objects is that a colorful object can be changed in different useful ways. In the paired images at the top of this post, each has a different set of colors. By changing color multipliers, you can change individual colors in a single multicolored file. For example, take the simple Adobe logo. Support Adobe decided to open a branch office on the moon and wanted some changes to indicate that the office was off-earth. They may want to make some subtle changes so that the logo is instantly recognizable but clearly different. Consider the following:

Making a special logo for Adobe's office on the moon

The following program was employed in creating all of the different images. Its design allows you to put in any file you want; so use your own if you like.

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

package 
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Loader;
	import flash.events.Event;
	import flash.net.URLRequest;
	import flash.display.Sprite;
	import flash.geom.Rectangle;
	import flash.geom.ColorTransform;
 
	public class BitMapColorCloneTransform extends Sprite
	{
		private var fileData:BitmapData;
		private var fileDataClone:BitmapData;
		private var file2Bit:Bitmap;
		private var file2BitClone:Bitmap;
		private var imageLoader:Loader;
		private var url:String;
		private var rect:Rectangle;
		private var clrTransform:ColorTransform;
 
		public function BitMapColorCloneTransform()
		{
			//url="samGif.gif";
			//url="trans.png";
			url="logo.png";
 
			imageLoader = new Loader();
			imageLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);
			imageLoader.load(new URLRequest(url));
		}
		private function onComplete(e:Event):void
		{
			fileData = e.target.content.bitmapData;
			file2Bit = new Bitmap(fileData);
			file2Bit.x=10, file2Bit.y=20;
			addChild(file2Bit);
 
			fileDataClone=fileData.clone();
			rect=new Rectangle(0,0,file2Bit.width,file2Bit.height);
			clrTransform=new ColorTransform();
			//clrTransform.alphaMultiplier=0.75;
			clrTransform.redMultiplier=0.75;
			//clrTransform.greenMultiplier=1.0;
			clrTransform.blueMultiplier=0.0;
			fileDataClone.colorTransform(rect,clrTransform);
			file2BitClone = new Bitmap(fileDataClone);
			file2BitClone.x=270, file2BitClone.y=20;
			addChild(file2BitClone);
 
		}
	}
}

An important element to note in the program is that the Rectangle object is the same dimensions as the BitmapData object that was loaded from a file. Using the width and height properties of the BitmapData object for the width and height of the Rectangle object simplified the process.

More on Bitmapped Objects and their Properties

I want to create a program using a design pattern that allows experimentation with the different properties of Bitmap and BitmapData objects and look further into ColorTransform. All of this attention is to see if using clones with different colors can add some speed to the process of object creation and differentiation on mobile devices. Also, I hope to see if we can find a design pattern to accommodate the development time in changing and maintaining larger programs designed for the mobile user.

The idea of taking a perfectly good graphic file and taking it apart and putting it back together again has a surprising appeal. You may wonder why one would want to do that? For me, it’s a chance to explore the Bitmap classes built into ActionScript 3.0 and see if there is some way to manage the pixel set better and learn as much as possible about the behavior of bitmap data, filters and anything else that might be useful for speeding things up.

More importantly for design pattern development is creating bitmap data objects and moving them around between participants in a pattern and making changes and additions to a program. In creating this pattern, I found it relatively easy to create a concrete product class from an abstract class used in loading and changing standard bitmap files into ActionScript 3.0 bitmap code; however, I had to spend some time calling for a bitmap object through a creator. In other words, getting something up on the stage using a Factory Method design pattern was more than just duplicating what I had done before with the Loader class and bitmap graphic files.

To get started, download the files used and take a look at the outcome by pressing the Play button.

You will find examples from three types of bitmapped graphics: GIF, JPEG and PNG. Identical code was used to break them into bitmap objects from ActionScript 3.0 classes.

The Bitmap Product

The design participants to see first are the abstract and concrete bitmap products (BitMapProduct, BitMapSam). The abstract class contains the properties used in both loading the bitmaps and working with Bitmap and BitmapData properties and methods.

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

//Product
package 
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Loader;
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Abstract class
	public class BitMapProduct extends Sprite
	{
		protected var url:String;
		protected var imageLoader:Loader;
		protected var prodData:BitmapData;
		protected var prodBit:Bitmap;
 
		public function doBitMap(url:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Concrete Product
package 
{
	import flash.display.Bitmap;
	import flash.display.Loader;
	import flash.events.Event;
	import flash.net.URLRequest; 
 
	public class BitMapSam extends BitMapProduct
	{
		public override function doBitMap(url:String):void
		{
			imageLoader = new Loader();
			imageLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);
			imageLoader.load(new URLRequest(url));
		}
		private function onComplete(e:Event):void
		{
			prodData = e.target.content.bitmapData;
			prodBit = new Bitmap(prodData);
			addChild(prodBit);
		}
	}
}

Note that the Product (BitMapProduct) extends Sprite and the Concrete Product (BitMapSam) extends the Product. As a result the concrete product is a Sprite.

The Bitmap Factory

The Creator (factory) elements consist of the abstract factory (BitMapCreator) and the concrete factory (BitmapSamMaker). The Creator holds a reference to the Product (abstract factory) and the factory method, but that’s it. The concrete factory returns an instance of the Product using lazy instantiation.

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

//Creator (Factory)
package 
{
	import flash.errors.IllegalOperationError;
 
	public class BitMapCreator
	{
		protected var product:BitMapProduct;
 
		// ABSTRACT Method (must be overridden in a subclass)
		public function factoryMethod(url:String):BitMapProduct
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}
 
//Concrete Creator
package 
{
	public class BitMapSamMaker extends BitMapCreator
	{
		public override function factoryMethod(url:String):BitMapProduct
		{
			if (! product)
			{
				product=new BitMapSam();
			}
			product.doBitMap(url);
			return product;
		}
	}
}

As you can see, both Creator classes are pretty simple. Most of the work is done in the concrete product, and in it you can see the way in which ActionScript 3.0 Bitmap objects can be employed.

The Client

It took a while to work out how to bring in the loaded bitmap data through the Client, and once resolved, it turned out to be fairly simple. The Client must pass a string with the name of the bitmap graphic to load. I used three buttons to load an example of each type of graphic to illustrate its functionality with more than a single kind of bitmap graphic.

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

//Client
package 
{
	import flash.display.Sprite;
	import uifactory.*;
	import flash.events.MouseEvent;
 
	public class SamBitClient extends Sprite
	{
		private var bitMapSam:BitMapCreator;
		private var bitMapSamNow:BitMapProduct;
		private var btnMk:UICreator;
		private var fileType:String;
		private var fileNow:String;
		private var btnG:Sprite;
		private var btnP:Sprite;
		private var btnJ:Sprite;
 
		public function SamBitClient()
		{
			btnMk = new SpriteButtonMaker  ;
			//(for label,x,y,color,width,height)
			btnG = btnMk.factoryMethod("Bitmap GIF",10,10,0x456173,100,20);
			btnG.addEventListener(MouseEvent.CLICK,chooseSam);
			addChild(btnG);
			btnP = btnMk.factoryMethod("Bitmap JPG",10,35,0x456173,100,20);
			btnP.addEventListener(MouseEvent.CLICK,chooseSam);
			addChild(btnP);
			btnJ = btnMk.factoryMethod("Bitmap PNG",10,60,0x456173,100,20);
			btnJ.addEventListener(MouseEvent.CLICK,chooseSam);
			addChild(btnJ);
		}
 
		private function chooseSam(e:MouseEvent)
		{
			if (bitMapSamNow)
			{
				removeChild(bitMapSamNow);
			}
 
			fileType = e.target.text;
			switch (fileType)
			{
				case "Bitmap GIF" :
					fileNow = "samGif.gif";
					break;
 
				case "Bitmap JPG" :
					fileNow = "samJpg.jpg";
					break;
 
				case "Bitmap PNG" :
					fileNow = "samPng.png";
 
			}
 
			bitMapSam = new BitMapSamMaker  ;
			bitMapSamNow = bitMapSam.factoryMethod(fileNow);
			addChild(bitMapSamNow);
			bitMapSamNow.x = 130,bitMapSamNow.y = 20;
		}
	}
}

With all of that code, the whole operation in the Client is only the following two lines:

bitMapSam = new BitMapSamMaker;
bitMapSamNow = bitMapSam.factoryMethod(fileNow);

The rest is UI. The UIFactory is the one used in the previous post with minor modifications in color and font. (It is included in the download.)

More On Bitmaps

I’d like to follow up this post with another on ActionScript 3.0 Bitmap objects. However, instead of creating Bitmaps from files, I’d like to explore creating them using the BitmapData object and some of the other Bitmap-related classes in ActionScript 3.0. As always, we’re interested in your feedback.

In creating the Button Factory example (see previous post), I wanted to add more to it for a full UI factory. The problem is that the Creator participant returned a Sprite and I wanted to be able to assign text values to instances the factory created. So I needed to make some changes to the original factory to accommodate these changes—mainly by having the program return a TextField object instead of a Sprite. In the process I found a distinct advantage of using abstract classes instead of interfaces for a general interface.

The whole point of spending time with a design pattern is so that you can easily make changes and add different components without having to re-write the whole program. The original Button Factory included a label returned on a Sprite. The text for the label is passed in a parameter by the Client, but the returned button is stuck with the text on the button. You cannot change the text in the button instance. That’s fine for the button because you can add any label you want on instantiation. However, when your program is passing information displays in text fields, you need access to the text property of the TextField to display updated information.

To get started, you can click the Play button to see an example and the Download button to get all of the files:

You will find all of the materials from the Button Factory as well as the new classes. I think you’ll find this little UI factory to be fairly handy when you need buttons and text fields with some formatting in a hurry. Of course, you can add your own UI components easily without disrupting the program.

Adding a Second Factory Method

In order to return a TextField object, I needed to add a second factory method to the Creator (UICreator) and I had to add a new Product (UITProduct). Then I just added the concrete factory (TextDisplayMaker) and the concrete product (TextDisplay). Because I used an abstract class instead of an interface, I did not have to implement all of the methods, but instead I am able to use one of two different factory methods and can implement one or both, depending what I need for my UI. So first, here’s the new UICreator with the added factory method:

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

//Creator revised
package uifactory
{
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.errors.IllegalOperationError;
	// ABSTRACT Class (should be subclassed and not instantiated)
	public class UICreator
	{
		protected var product:UIProduct;
		protected var tProduct:UITProduct;
 
		// ABSTRACT Method (must be overridden in a subclass)
		public function factoryMethod(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
		//Second factory method added
		public function textFactoryMethod(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):TextField
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

Notice that the added factory method is identical to the first one except that it returns a TextField instead of a Sprite. Note also that the revised code imports TextField.

Next, I had to create a new Product—one that results in a useable TextField object and not a Sprite:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package uifactory
{
	import flash.text.TextField;
	import flash.errors.IllegalOperationError;
 
	// ABSTRACT Class (should be subclassed and not instantiated)
	class UITProduct
	{
		protected var ui:TextField;
 
		public function getUI(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):TextField
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

Again, you can see that the new abstract Product (UITProduct) is exactly the same as the UIProduct except that it imports a TextField and returns one instead of a Sprite.

Next, in looking at the factory for creating a concrete UITProduct, the TextDisplayMaker implements the same UICreator as one of the button products from the previous post, but it must use the new factory method, textFactoryMethod to return a usable text field. Otherwise it’s the same, and the lazy instantiation creates a new tProduct instead of a product, which is the property of the UIProduct.

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

package uifactory
{
	import flash.text.TextField;
	public class TextDisplayMaker extends UICreator
	{
		public override function textFactoryMethod(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):TextField
		{
			if (! tProduct)
			{
				tProduct=new TextDisplay();
			}
			return tProduct.getUI(msg,hor,v,col,w,h);
		}
	}
}

The text product itself has some twists that provide a flexible TextField object—one that can be either dynamic or input. It also has variable text formatting, but the message text is implemented by the Client. It implements the UITProduct.

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

package uifactory
{
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldType
	import flash.display.Sprite;
 
	public class TextDisplay extends UITProduct
	{
		private var txtFormat:TextFormat;
 
		public override function getUI(msg:String,align:Number,v:Number,col:uint,w:Number,h:Number):TextField
		{
			ui=new TextField();
			txtFormat=new TextFormat();
			txtFormat.font="Verdana";
			txtFormat.color=0x000000;
			txtFormat.size=11;
			txtFormat.blockIndent=5;
 
			ui.defaultTextFormat = txtFormat;
 
			switch(msg)
			{
				case "DYNAMIC":
				ui.type=TextFieldType.DYNAMIC;
				break;
 
				case "INPUT":
				ui.type=TextFieldType.INPUT;
				break;
			}
			//Type will be INPUT or DYNAMIC
			//ui.type = TextFieldType.msg;
 
			ui.selectable = false;
			ui.border=true;
			ui.multiline=true;
			ui.borderColor=0xbbbbbb;
			ui.background=true;
			ui.wordWrap=true;
			ui.backgroundColor=col;
			ui.x = align;
			ui.y = v;
			ui.width = w;
			ui.height = h;
			//ui.text=msg;
			return ui;
		}
	}
}

The concrete text product has a good deal of flexibility, allowing for either INPUT or DYNAMIC text fields. In order to show how it works with the earlier version of objects in the same UIFactory, the following Client uses a button from the original Button Factory (see previous post) and the new text factory and products from this current post.

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

//Client
package 
{
	import uifactory.*;
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.events.MouseEvent;
	import flash.events.FocusEvent;
 
	public class UIClient extends Sprite
	{
		private var btnMk:UICreator;
		private var display:UICreator;
		private var inDisplay:UICreator;
		private var btn:Sprite = new Sprite  ;
		private var displayNow:TextField = new TextField  ;
		private var inputNow:TextField = new TextField  ;
		private var passOn:String;
 
		public function UIClient()
		{
			btnMk=new SpriteButtonMaker();
			//(for label,x,y,color,width,height)
			btn = btnMk.factoryMethod("Click 4 Text",40,40,0x53933f,120,50);
			btn.addEventListener(MouseEvent.CLICK, passText);
			addChild(btn);
 
			//Input text
			inDisplay=new TextDisplayMaker();
			inputNow = inDisplay.textFactoryMethod("INPUT",40,100,0xFFB03B,150,48);
			inputNow.addEventListener(FocusEvent.FOCUS_IN,eraser);
			inputNow.text = "Enter your text here:";
			addChild(inputNow);
 
		}
 
		private function eraser(e:FocusEvent):void
		{
			e.target.text = "";
		}
 
		private function passText(e:MouseEvent):void
		{
			passOn = inputNow.text;
			display=new TextDisplayMaker();
			displayNow = display.textFactoryMethod("DYNAMIC",40,160,0xCEF09D,250,100);
			displayNow.text = passOn;
			addChild(displayNow);
 
		}
	}
}

The purpose of this post is to illustrate how simple it is to make changes within a design pattern without disrupting previous work you have done. Also, I hope that some of you will extend the UI factory even further and share them with us. Happy Programming!

A UI Factory for Buttons and Labels

The other day I was looking at an ActionScript 3.0 program, and the developer used a ‘UI Factory.’ I looked at it, and while the program did indeed get UIs from the UIFactory class, it wasn’t a design pattern. Instead the UI Factory was just a single class with a bunch of methods for building different parts of a UI. Included in the factory, though, was a call to another class that also was part of the overall UI.

Basically, the call from one factory product to another made the requesting product a client. So, I thought, why not create a factory method design pattern where one part of a product called another to complete the product? The design pattern would be a straightforward Factory Method pattern, and the call from within the pattern would follow the same call through the Creator as a call from a general Client class would be. In this way, I would be able to use the same interfaces (abstract classes) for calls within the pattern as well as from outside the pattern by an external Client class.

A Button and Label Factory

The basic process is the same used in the post describing Lazy Initialization on this blog. The difference is that one product uses another product in the factory process. To get started, take a look at Figure 1 that shows how an external client and the UIButton both make requests through the UICreator. The external client can get either a button or just the label, but when a button is requested, it then requests a label to go with it.

Figure 1: Request by button and external client for a label

The button uses a Sprite object for the base of a graphic gradient shape using a round rectangle. The label is put into a Sprite as well and then added to the button. The Sprite is inherited from the same UIProduct class.

Creators and Products

Just like any other Factory Method, the pattern uses abstract classes for both the UICreator and the UIProduct. The following listing shows that both abstract classes have methods that use the same set of parameters.

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

//Creator
package 
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
	// ABSTRACT Class (should be subclassed and not instantiated)
	public class UICreator
	{
		protected var product:UIProduct;
 
		// ABSTRACT Method (must be overridden in a subclass)
		public function factoryMethod(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}
 
//Product
package 
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	// ABSTRACT Class (should be subclassed and not instantiated)
	class UIProduct
	{
		protected var ui:Sprite;
 
		public function getUI(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

The “abstracting” of the classes provides a good deal of flexibility and bindings are loose. The concrete implementations are only two of a larger planned UI set. However, it’s not difficult to add any concrete UI you want.

The Concrete Label Maker and Product

First, take a look at the concrete label and label creator. The creator uses lazy initialization, and the concrete label product uses TextField and TextFormat objects for the label product.

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

//Concrete Label Creator
package 
{
	import flash.display.Sprite;
	public class SpriteLabelMaker extends UICreator
	{
		public override function factoryMethod(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			if (! product)
			{
				product=new SpriteLabel();
			}
			return product.getUI(msg,hor,v,col,w,h);
		}
	}
}
 
//Concrete Label Product
package 
{
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldAutoSize;
	import flash.display.Sprite;
 
	public class SpriteLabel extends UIProduct
	{
		private var txtLabel:TextField;
		private var txtFormat:TextFormat;
 
		public override function getUI(msg:String,align:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			ui=new Sprite();
			txtFormat=new TextFormat();
			txtFormat.font="Arial Black";
			txtFormat.color=0xffffff;
			txtLabel = new TextField();
			txtLabel.defaultTextFormat = txtFormat;
			txtLabel.text = msg;
			txtLabel.autoSize = TextFieldAutoSize.LEFT;
			txtLabel.selectable = false;
			txtLabel.x = align / 2;
			txtLabel.y = h/4;
			ui.addChild(txtLabel);
			return ui;
		}
	}
}

By including both TextField and TextFormat objects, the look and feel of the button labels have a good deal of flexibility. Currently set to create only white buttons, the color parameter (col) could be used to add more appropriate colors if needed.

The Concrete Button Maker and Product

Like the label, the concrete implementations of the creator and product abstract classes use the same set of method parameters. However, the button product acts as a client calling for a label product through the UICreator interface (abstract class). Both return a Sprite object, but when the button object appears, it always has a label with it. So a request for a button object is also a request for a label object. Labels, however, may be requested by a client without having to get a button object as well.

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

//Button concrete Creator
package 
{
	import flash.display.Sprite;
	public class SpriteButtonMaker extends UICreator
	{
		public override function factoryMethod(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			if (! product)
			{
				product=new SpriteButton();
			}
			return product.getUI(msg,hor,v,col,w,h);
		}
	}
}
 
//Button concrete Product
package 
{
	import flash.display.Sprite;
	import flash.display.GradientType;
	import flash.display.SpreadMethod;
 
	public class SpriteButton extends UIProduct
	{
		private var lbl:UICreator;
		public override function getUI(msg:String,hor:Number,v:Number,col:uint,w:Number,h:Number):Sprite
		{
			ui= new Sprite();
			var fill:String = GradientType.LINEAR;
			var spread:String = SpreadMethod.PAD;
			ui.graphics.beginGradientFill(fill, [col, 0x70c656],[1,1],[127,255],null,spread,"rgb",0);
			//Button shape (x,y,width, height, corner)
			ui.graphics.drawRoundRect(0,0,w, h, 8, 8);
			ui.graphics.endFill();
			ui.x=hor, ui.y=v;
			ui.buttonMode = true;
			ui.useHandCursor = true;
			lbl=new SpriteLabelMaker();
			ui.addChild(lbl.factoryMethod(msg,hor,v,col,w,h));
			return ui;
		}
	}
}

Both the graphic portion and label portion of the button use the ui property inherited and implemented from the UIProperty class. In that respect the button product is recursively formed. It is built by embedding the label Sprite into the button Sprite.

Finally, here’s an example of a Client. It creates two different buttons based on the arguments.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package 
{
	import flash.display.Sprite;
 
	public class UIClient extends Sprite
	{
		private var btnMk:UICreator;
		private var lbl:UICreator;
		private var btn:Sprite=new Sprite;
		private var btn2:Sprite=new Sprite;
 
		public function UIClient()
		{
			btnMk=new SpriteButtonMaker();
			//(for label,x,y,color,width,height)
			btn=btnMk.factoryMethod("Click Here",40,40,0x53933f,120,50);
			addChild(btn);
			btn2=btnMk.factoryMethod("Magic",40,110,0x0000cc,100,32);
			addChild(btn2);
		}
	}
}

Figure 2: Flexibility in Button Factory

One important feature I tested with this little design pattern was whether the buttons could indeed be used as buttons. Most importantly, I wanted to make sure that they could handle event listeners that in turn could handle events. Fortunately, they worked like any other button, and all that was necessary was to make sure that the buttonMode and useHandCursor properties were set to true. I have a feeling that this is a little application that I’ll be re-using a lot and tweaking a lot more!

In previous posts we’ve considered recursion, and while not rejecting recursion out of hand, it’s been roughed up a bit, especially by smart reader comments. (You can see posts on recursion here.) For those of you who may be new to the recursive concept, it refers to a method that calls itself.

In general, ActionScript 3.0 programmers tend to avoid recursion because recursive functions fill up the stack faster than a loop doing essentially the same thing, and loops are generally faster than recursive functions. Now that we really need to pay attention to speed for mobile development, should we waste time thinking about recursion when we need to be thinking about speed and multicore operations? I think we need to understand recursion, and use it when needed. More importantly, it is a useful tool for thinking about programming.

Basic ActionScript 3.0 Recursive Functions: Direct and Indirect

As a simple refresher, the following illustrates two examples of recursion in programming. A direct recursive function is one where the function calls itself and indirect recursion occurs where a function calls another function and then calls the calling function.

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

package 
{
	import flash.display.Sprite;
	public class Recursion extends Sprite
	{
		private static var cur:String;
		private static var counter:uint = 0;
 
		public function Recursion()
		{
			direct();
			indirect();
		}
 
		//Direct recursion occurs when a method calls itself
 
		private static function direct():void
		{
			if (counter<2)
			{
				cur = "Direct recursion";
				trace(cur+counter);
				counter++;
				//Self-calling method
				direct();
			}
		}
 
		//Indirect recursion occurs when a method calls a method 
		//that calls the calling method
 
		private final function indirect():void
		{
			if (counter < 4)
			{
				cur = "Indirect recursion";
				trace(cur+counter);
				counter++;
				//Calls method that calls this method
				indirectly();
			}
		}
 
		private final function indirectly():void
		{
			indirect();
		}
	}
}

The conditional statements inside the recursive functions keep the functions from a stack overflow error. It is identical to avoiding an infinite loop by making sure that a loop termination condition is placed in the loop statement.

Gödel, Escher, Bach: An Eternal Golden Braid (A metaphorical fugue on minds and machines in the spirit of Lewis Carroll)

Wanting to dust the cobwebs out of my head and get away from linear thinking, I inquired for a good starting point for pure mathematics. I was guided to Gödel, Escher, Bach (GEB) by Douglas R. Hofstadter. Published in 1979, it won the nonfiction Pulitzer Prize in 1980 and has been a perennial favorite of programmers, mathematicians, artists, musicians and others who want to give their minds a workout ever since. (See the WikiPedia entry for a quick overview. Also, MIT offers GES: A Mental Space Odyssey as part of their Open Courseware program.) Of particular interest for this post is Chapter V: Recursive Structures and Processes (Canon by Intervallic Augmentation). For Hofstadter, recursion is a general concept and can include such things as movies within movies, Russian stacking dolls and paintings inside paintings. (The image at the beginning of this post is borrowed from Escher’s famous illustration of two hands drawing one another—a recursive illustration.)

One type of recursion occurs in graphics where the pixels that define a shape (context) are defined by the context. For example, consider Figure 1. The dots that make up the circle shape are also positioned relative to the circle they define.

Figure 1: Dots' positions defined by the circle they define.

The dot (or pixel) is part of the images we seek to place on the stage, and their placement makes up the image that defines their position. You may be thinking,

So what?

How can I use this knowledge to become a better programmer or make my programs better? You can do it in the same way that Gamma and his associates looked a programming in a different way and came up with Design Patterns. Instead of asking,

What will make my program run faster and how can I optimize its performance?

They asked,

What kind of program structures do we need when programs change so that the other parts of the program will be unaffected by the change?

Perhaps instead of asking “How do I make a circle by lighting up pixels?”, we may ask, “How do circles position pixels?” They’re the same question, but they generate different ways of thinking about creating graphics in ActionScript 3.0. Of course, AS3 has built-in Graphics methods for creating circles; so you may not think about creating circles. (See Circle-Drawing Algorithms for an interesting discussion of circle creation.) However, in terms of problem-solving, you will find recursion again and again. Recursion is in the world, and linear thinking is not the only way to think about recursion. In some respects linear thinking distorts reality because it distorts recursion by unwinding it to fit into a linear plan.

Design Patterns as Cheat Sheets for Critical Thinking

Like recursion, a lot of the principles in the GoF book are nonlinear. For example the principle, Program to the interface and not the implementation, is a good example of nonlinear thinking. The fact that the Gang of Four took the time to work out the set of patterns they did for the different kinds of programming structures is very valuable because that means I don’t have to do it for myself. For example, if I have a bunch of algorithms that I know are going to change and interact with the rest of the program, I don’t have to figure out a flexible way to incorporate them into my program. I can snatch up a Strategy pattern and it has the structure laid out for me. In the same way, the concept of recursion is a structure that can be used to help solve a problem. I may end up using a loop, but I’m more likely to first think, “Is this a recursive structure?” If so, then I can add a recursive method (as I might in a Chain of Responsibility structure) and then eventually solve the problem using a switch statement inside a loop. In that respect, recursive methods are cheat sheets as well. We don’t have to reinvent new structures or rely only on linear ones when we sit down to program.

As our desktop screens soar to new heights in size, we find ourselves coping with smaller platforms for mobile viewing. To address this problem, developers simply move from one cell, grid or section to another. Each new cell becomes the full screen. For example, a 3 x 3 matrix has 9 cells (grid sections or just ‘grids’). The matrix can be seen as a “game universe” and each cell is the current “stage” for interaction. Some of you old-timers may remember the Star Trek games from the early days of desktop computing. Your starship would be an asterisk and you’d go from grid cell to grid cell chasing or chased by Romulans or Klingons, and when you came to the edge of a section you’d just change sections and with it came a new “stage.”

I have no idea of the programming behind those games, but the concept is perfectly clear. As you change sections, you get a new ‘map’ of that section. To get a sense of what’s going on, click the Play button to view the desktop version of the game, and then the Download button to get all of the code and objects in FLA and SWC files:

Movement Rules

To get started building this game, I wanted to begin with simple movement rules. So I decided that movement would only be up, down, left, right. No diagonal movement allowed. For example, if an object were in Grid 7, it could go either to Grid 4 or Grid 8. No movement to Grid 5 or off the grid allowed. The opponent character is randomly placed into one of the grids, and the player moves from grid to grid until he finds the opponent. Figure 1 shows an example:

Figure 1: The player's samurai and opponent meet in a grid cell

The four Japanese characters are buttons for movement direction—North (up), South (down), West (left) and East (right). The buttons are simple ones and use a TouchEvent to slip in images behind the button set and characters. A single “Attack” button does nothing more than animate the characters [for now]. Eventually, I want the movement of the individual samurai objects to move across each grid and then jump to the next grid once he reaches a border. I also want the character to move faster along roads than non-road terrain. For example, in Figure 2, the character would be able to move speedily along roads to the next grid cell moving north, south or east, but moving west (left) movement would be slower because the lack of a road. Also, he would be able to move at road speed across the bridge (bottom right), but he would move across the river with no bridge at a much slower rate if at all.

Figure 2: Movement options (iPhone screen shot)

At this juncture, all I have is the movement through grids and not within a grid. In order to facilitate movement, I’ve employed a State Design Pattern (See Class and File Diagrams in earlier posts). Each state class shows the options. For example, State 5 is right in the middle of the grid (see grid map at the beginning of this post.)

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 
{
	public class Grid5State implements IGrid
	{
		private var context:Context;
 
		public function Grid5State(context:Context)
		{
			this.context = context;
		}
 
		public function goWest():uint
		{
			context.setState(context.getGrid4State());
			return 4;
		}
		public function goEast():uint
		{
			context.setState(context.getGrid6State());
			return 6;
 
		}
		public function goNorth():uint
		{
			context.setState(context.getGrid2State());
			return 2;
		}
		public function goSouth():uint
		{
			context.setState(context.getGrid8State());
			return 8;
		}
	}
}

As you can see, all four directions are available to a player in Grid 5. However, if we look at Grid 9, the player can only go north or west as shown in the following 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

package 
{
	public class Grid9State implements IGrid
	{
		private var context:Context;
 
		public function Grid9State(context:Context)
		{
			this.context = context;
		}
 
		public function goWest():uint
		{
			context.setState(context.getGrid8State());
			return 8;
		}
		public function goEast():uint
		{
			return 9;
		}
		public function goNorth():uint
		{
			context.setState(context.getGrid6State());
			return 6;
		}
		public function goSouth():uint
		{
			return 9;
		}
	}
}

If the player tries to go south or east, the class simply returns to value of the current grid and the player goes nowhere. Likewise, no context is changed. A choice of north or west results in the appropriate change in context and the next grid cell is slipped in.

The Client, Context and State Interface

Like all State Design Patterns, the Client makes its calls through the context. In this case the Client is pretty big because it is also setting the state with buttons and whatnot. However, once in place, the navigation and attack buttons no longer need to be called because the backgrounds are slipped beneath them. You can see how this works in Client 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
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

package 
{
	import flash.display.Sprite;
	import flash.display.MovieClip;
	import fl.controls.Button;
	import flash.display.SimpleButton;
	import flash.events.TouchEvent;
	import flash.ui.Multitouch;
    import flash.ui.MultitouchInputMode;
 
	public class Client extends Sprite
	{
		private static var sam1:MovieClip=new Sam1();
		private static var sam2:MovieClip=new Sam2();
		private static var context:Context=new Context();
		private var grid:Sprite=new Sprite();
 
		private var foeGrid:uint = uint(Math.random() * (9 - 1) + 1);
		private var gridNow:uint;
 
		private static var attackBtn:Button=new Button();
 
		private static var westBtn:SimpleButton=new West();
		private static var eastBtn:SimpleButton=new East();
		private static var northBtn:SimpleButton=new North();
		private static var southBtn:SimpleButton=new South();
 
		private var grid1:Sprite=new Grid1();
		private var grid2:Sprite=new Grid2();
		private var grid3:Sprite=new Grid3();
		private var grid4:Sprite=new Grid4();
		private var grid5:Sprite=new Grid5();
		private var grid6:Sprite=new Grid6();
		private var grid7:Sprite=new Grid7();
		private var grid8:Sprite=new Grid8();
		private var grid9:Sprite=new Grid9();
 
		public function Client()
		{
			grid = this["grid" + context.randomStart()];
			addChildAt(grid,0);
			sam1.x = 350,sam1.y = 220;
			addChild(sam1);
			sam1.gotoAndStop(1);
			sam2.x = 400,sam2.y = 100;
			sam2.gotoAndStop(1);
			setControls();
		}
 
		private final function setControls():void
		{
			Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
			northBtn.x = 67,northBtn.y = 5;
			northBtn.addEventListener(TouchEvent.TOUCH_TAP,northNow);
			addChild(northBtn);
 
			westBtn.x = 5,westBtn.y = 80;
			westBtn.addEventListener(TouchEvent.TOUCH_TAP,westNow);
			addChild(westBtn);
 
			eastBtn.x = 150,eastBtn.y = 80;
			eastBtn.addEventListener(TouchEvent.TOUCH_TAP,eastNow);
			addChild(eastBtn);
 
			southBtn.x = 67,southBtn.y = 160;
			southBtn.addEventListener(TouchEvent.TOUCH_TAP,southNow);
			addChild(southBtn);
 
			//Animate
			attackBtn.width = 50,attackBtn.label = "Attack!";
			attackBtn.x = 15,attackBtn.y = 360;
			attackBtn.addEventListener(TouchEvent.TOUCH_TAP,attackNow);
			addChild(attackBtn);
		}
 
		private final function northNow(e:TouchEvent):void
		{
			if(gridNow==foeGrid)
			{
				removeChild(sam2);
			}
			removeChild(grid);
			gridNow = context.doNorth();
			if (gridNow==foeGrid)
			{
				addChild(sam2);
			}
			grid = this["grid" + gridNow];
			addChildAt(grid,0);
		}
 
		private final function westNow(e:TouchEvent):void
		{
			if(gridNow==foeGrid)
			{
				removeChild(sam2);
			}
			removeChild(grid);
			gridNow = context.doWest();
			if (gridNow==foeGrid)
			{
				addChild(sam2);
			}
			grid = this["grid" + gridNow];
			addChildAt(grid,0);
		}
 
		private final function eastNow(e:TouchEvent):void
		{
			if(gridNow==foeGrid)
			{
				removeChild(sam2);
			}
			removeChild(grid);
			gridNow = context.doEast();
			if (gridNow==foeGrid)
			{
				addChild(sam2);
			}
			grid = this["grid" + gridNow];
			addChildAt(grid,0);
		}
 
		private final function southNow(e:TouchEvent):void
		{
			if(gridNow==foeGrid)
			{
				removeChild(sam2);
			}
			removeChild(grid);
			gridNow = context.doSouth();
			if (gridNow==foeGrid)
			{
				addChild(sam2);
			}
			grid = this["grid" + gridNow];
			addChildAt(grid,0);
		}
 
		//Toggle button
		private static function attackNow(e:TouchEvent):void
		{
			if (e.target.label == "Attack!")
			{
				sam1.gotoAndPlay(1);
				sam2.gotoAndPlay(1);
				attackBtn.label = "Cease!";
			}
			else
			{
				sam1.gotoAndStop(1);
				sam2.gotoAndStop(1);
				attackBtn.label = "Attack!";
			}
		}
	}
}

One of the features in the Client class that I don’t like is the use of conditional statements in the calls to the different directions. I found that the “Foe Samurai” was a bit of a problem. He’s only allowed in the random cell that has been selected, and if I didn’t remove the sam2 object, he’d get over stacked whenever the player object (sam1) entered the cell. There’s probably some more elegant way to deal with that issue, but I didn’t see it.

I decided to use grid numbers—unsigned integers—in the hope of making the code more efficient. The grid number is knitted to a “grid” from a Sprite class stored in the Library. All grids are instantiated and assigned values at the outset and so they’re not re-instantiated; just added and removed from the stage–sort of like the magic trick where the table cloth is pulled quickly from a table and all the dishes and silverware remain on top.

The IGrid interface and Context class are pretty simple. The interface has methods for the four directions:

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

package 
{
	//Interface
 
	public interface IGrid
	{
		function goWest():uint;
		function goEast():uint;
		function goNorth():uint;
		function goSouth():uint;
	}
}

Given the polymorphism that goes into each of these methods with the nine concrete states, it’s really nice to have this kind of interface. It’s a mix of flexibility, simplicity and possibilities.

The Context is also fairly simple, but it is at the heart of the State pattern because it keeps track of the current state. By doing so, no matter what state (grid cell) the samurai is in, not only does it know what cell it in, the connected concrete State class provides all the options available—without a single conditional statement.

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

package 
{
	//Context class
 
	class Context
	{
		private var grid1State:IGrid;
		private var grid2State:IGrid;
		private var grid3State:IGrid;
		private var grid4State:IGrid;
		private var grid5State:IGrid;
		private var grid6State:IGrid;
		private var grid7State:IGrid;
		private var grid8State:IGrid;
		private var grid9State:IGrid;
		private var stateNow:IGrid;
		private var rndNow:uint;
 
		public final function Context()
		{
			trace("States Set");
			grid1State = new Grid1State(this);
			grid2State = new Grid2State(this);
			grid3State = new Grid3State(this);
			grid4State = new Grid4State(this);
			grid5State = new Grid5State(this);
			grid6State = new Grid6State(this);
			grid7State = new Grid7State(this);
			grid8State = new Grid8State(this);
			grid9State = new Grid9State(this);
 
			rndNow=uint(Math.random() * (9-1) +1);
			stateNow = this["grid"+rndNow+"State"];
		}
 
		public final function randomStart():uint
		{
			return rndNow;
		}
		public final function doWest():uint
		{
			return stateNow.goWest();
		}
 
		public final function doEast():uint
		{
			return stateNow.goEast();
		}
 
		public final function doNorth():uint
		{
			return stateNow.goNorth();
		}
 
		public final function doSouth():uint
		{
			return stateNow.goSouth();
		}
 
		public final function setState(stateNow:IGrid):void
		{
			this.stateNow = stateNow;
		}
 
		public final function getGrid1State():IGrid
		{
			return this.grid1State;
		}
		public final function getGrid2State():IGrid
		{
			return this.grid2State;
		}
		public final function getGrid3State():IGrid
		{
			return this.grid3State;
		}
		public final function getGrid4State():IGrid
		{
			return this.grid4State;
		}
		public final function getGrid5State():IGrid
		{
			return this.grid5State;
		}
		public final function getGrid6State():IGrid
		{
			return this.grid6State;
		}
		public final function getGrid7State():IGrid
		{
			return this.grid7State;
		}
		public final function getGrid8State():IGrid
		{
			return this.grid8State;
		}
		public final function getGrid9State():IGrid
		{
			return this.grid9State;
		}
	}
}

Note that all of the grid state properties are typed as IGrid types—that’s Programming to the interface instead of the implementation. This provides the properties with far more flexibility and reduces binding. Likewise, the return types on the getter functions were all typed to the IGrid interface, and so changes are easy because objects are not bound to the implementation.

Some (More) Mobile Tweaks

In the original version of this app, I used the SimpleButton timeline with different states for Up/Over/Down/Hit. I noticed that the Over state did not work but the buttons did—sort of. However, the movement was gummy and I often had to tap the button several times. I removed all of the states except for Up state and the movement event handling went much smoother. I could probably just as well use Sprite objects for buttons and I may change that.

Another feature that I want to work on is a New Game button of some sort. Given the sparse real estate on a mobile device I may have to have some kind of popup menu with different options for a new game, attacking and defending. I’d like to clear out memory and re-set where the “opponent” samurai goes—fresh start the whole thing.

Finally, I’m going to have to integrate intra-cell and inter-cell movement. All movement within a cell will uses the current State pattern so that when the samurai reaches the border it will jump to the next cell. This kind of movement may require an additional set of state classes, but right now I’m not sure. Likewise, I want to set it up so that simultaneous movement of the player samurai and the robot samurai can attack/defend. The Symmetric Proxy Pattern (Chapter 13) can possibly be employed so that each combat movement is judged simultaneously.

When working with high level and complex structures like Design Patterns, the focus is squarely on the relationship between objects—classes, inheritance, composition, implementation, interfaces and related concepts and structures. The “details” are the details of these various relationships and how they work in concert. Using Algorithm 1 or Algorithm 2 is only pertinent insofar as it relates to a method or property that needs to be loosely bound to some other object. If you start thinking about algorithm details as a primary concern and fretting over internals, you can easily lose sight of the larger structures that are under development and never really understand Design Patterns.

Seismic Shift

Every now and again we encounter a seismic shift in the way things are done, and you have to make adjustments.(Some of you may remember the Commodore 64 that went the way of the Dodo Bird. At one time it was the most popular personal computer on earth, but if you insisted on sticking with it, you probably don’t have any clients for your services.) In my own case, shift to mobile devices forced me to spend some quality time with the event processes in ActionScript 3.0. Going to the base, I reviewed how the Display List is handled in Flash and by AS3. Then I went to look at the AS3 Event Flow and among the several articles I read, one of the best is Jody Hall’s. Adobe has several good ones as well, and I’m sure many more are available that some of you may want to share.

On to Gestures

I wrote some gesture events and handlers. The results were unsatisfactory. It wasn’t that they didn’t work, but after one would work, another would not. Very baffling and frustrating. My goal was to create a ‘workbench’ where I could try all kinds of gesture events, but I had very poor luck with just about everything at some point. So I backed away and tried an application with only two gestures; neither available with MouseEvent. One was Rotate and the other Zoom. Christian Cantrell has a good article on using gestures, and in addition to getting some good information on using gesture events, I also got a nice little piece on using gestures with bitmaps. (I had been having a devil of a time with Sprite objects in the Library with gestures.) Click the download button below to get the source code and FLA files for Flash Pro 5.5, 5 and 4 along with the image files and ActionScript 3.0 code:

In my last post, I was convinced that TOUCH_TAP from TouchEvent works better than CLICK from MouseEvent with a mobile device. That conclusion was not based on the inner-workings of events and event handling, but rather from testing the different event handlers using my iOS device, a 4S iPhone. In the Adobe documentation, they point out that it might be better to use a MouseEvent rather than a TouchEvent or GestureEvent. It depends on the app, device and device OS. That pretty much makes it an empirical question.

In this application, there was no choice to use MouseEvent because it does not contain the required finger-flipping gestures I can make on my iPhone—GESTURE_ZOOM and GESTURE_ROTATE. Likewise, TouchEvent did not have the kinds of gestures; so I had to use TransformGestureEvent. The following code shows how it is employed in a simple picture flipping/zooming app:

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 
{
	import flash.display.Bitmap;
	import flash.display.Sprite;
	import flash.events.TransformGestureEvent;
	import flash.ui.Multitouch;
	import flash.ui.MultitouchInputMode;
 
	[SWF(width=640, height=960, frameRate=24, backgroundColor=0xcc0000)]
	public class PicFlip extends Sprite
	{
		[Embed(source = "vanBillz.png")]
		public static var BillzImage:Class;
		private static var billzBitmap:Bitmap = new BillzImage();
		private static var carrier:Sprite = new Sprite();
 
		public function PicFlip()
		{
			carrier.x = 320, carrier.y = 550;
			carrier.addChild(billzBitmap);
 
			billzBitmap.x = (320 - (billzBitmap.bitmapData.width / 2)) * -1;
			billzBitmap.y = (480 - (billzBitmap.bitmapData.height / 2)) *-1;
 
			this.addChild(carrier);
 
			Multitouch.inputMode = MultitouchInputMode.GESTURE;
			carrier.addEventListener(TransformGestureEvent.GESTURE_ZOOM, doZoom);
			carrier.addEventListener(TransformGestureEvent.GESTURE_ROTATE, doRotate);
		}
 
		private final function doZoom(e:TransformGestureEvent):void
		{
			carrier = e.target as Sprite;
			carrier.scaleX *=  e.scaleX;
			carrier.scaleY *=  e.scaleY;
		}
 
		private final function doRotate(e:TransformGestureEvent):void
		{
			carrier = e.target as Sprite;
			carrier.rotation +=  e.rotation;
		}
	}
}

I tested it on an iPhone, but there’s no reason it won’t work perfectly well on an Android or some other mobile device. Further, I found it to be very responsive. The zooming seemed to work quite well with bitmapped graphics, and so I assumed that it would work just as well, if not better with a vector object in the Library. So I put together a little test symbol using the drawing tools in Flash and stored it as Sprite class in the Library. (By the way, in case you were not aware, to make a Sprite class in the Library, when you create a New Symbol, just classify it as a MovieClip and in the Base Class window change the type from flash.display.MovieClip -> flash.display.Sprite. The Library icon turns from Blue to Green to indicate it is now a Sprite.)

I used 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

package 
{
	import flash.display.Sprite;
	import flash.events.TransformGestureEvent;
	import flash.ui.Multitouch;
	import flash.ui.MultitouchInputMode;
 
	public class PicFlipLib extends Sprite
	{
		private static var carrier:Sprite = new Sprite();
		private static var billzVector:Sprite=new BillzVector();
 
		public function PicFlipLib()
		{
			carrier.x = 220, carrier.y = 350;
			carrier.addChild(billzVector);
 
			this.addChild(carrier);
 
			Multitouch.inputMode = MultitouchInputMode.GESTURE;
			carrier.addEventListener(TransformGestureEvent.GESTURE_ZOOM, doZoom);
			carrier.addEventListener(TransformGestureEvent.GESTURE_ROTATE, doRotate);
		}
 
		private final function doZoom(e:TransformGestureEvent):void
		{
			carrier = e.target as Sprite;
			carrier.scaleX *=  e.scaleX;
			carrier.scaleY *=  e.scaleY;
		}
 
		private final function doRotate(e:TransformGestureEvent):void
		{
			carrier = e.target as Sprite;
			carrier.rotation +=  e.rotation;
		}
	}
}

One of the features that seemed to make a difference was that instead of having the event listener connected directly to the Library Sprite (BillzVector), I used an object container Sprite, carrier. Figure 1 shows the zoom and rotation on an iPhone 4S. This was used with both the bitmap and the vector Sprite objects, and they both worked quite well.

Figure 1: Both rotation and zoom worked fined with the vector-based Sprite

Back to Design Patterns

I was going to post my final matrix motion solution, but I got jammed up with event handling. Next time, I should be able to post the next stage in my Samurai game. It uses a State design pattern to move through nine cells in a 3 X 3 matrix. Everything was working well except that my event handlers were not as crisp as I wanted. I’ll have a chance to see now whether the time-out with AS3 event handlers was enough. The Design Pattern does its job; I just was not getting the event handlers to do theirs. In the next post you’ll be able to see whether they are all working well together in a mobile environment.

MouseEvent Works but TouchEvent Works better

I suppose old habits die hard, especially when those habits still work. (Some programmers are fond of saying, If it ain’t broke, don’t fix it! and the similarly dull-witted proverb, Don’t re-invent the wheel!) Well, with mobile devices, you’d better think about breaking old habits, and I put myself at the top of the dullard list for taking so long to make some adoptions. One of the first changes to make when creating mobile apps is to use the TouchEvent instead of the MouseEvent. In working on a game, I merrily kept using MouseEvent until I noticed that my apps kept getting stuck in the mud when I put them on a mobile device. So, I decided to give TouchEvent a try. Naturally, I couldn’t test in Flash Pro CS5.5; so I had to wait until I launched it in my iPhone. When I did, the difference was night and day. The sluggishness disappeared.

The good news is that MouseEvent and TouchEvent classes work pretty much the same as far as programming them into an app. I have no idea what’s going on with either under the hood, and I shouldn’t have to concern myself with those issues other than to know that one works better with mobile devices than the other. To get started, we’ll take a look at the sequence for setting up for TouchEvents, and while almost identical to MouseEvent, there are programming differences. First, though, click the Play button to see the little testing app on your computer. You can also download the Flash 5.5 Fla file and Client class by clicking on the Download button.

As you can see it’s a simple little app to move a “Samurai” character left and right; up and down. The buttons are in Japanese, and if you read Japanese, you’ll realize that the characters look like a first-grader’s attempts to learn how to write in Japanese. (Feel free to make some better simple buttons using Japanese characters and send them along with any comments you may have.)

Possible Controversy: After I had finished this post, I ran across the following:

http://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-6ffb37601221e58cc29-8000.html

In it is a note of caution:

Note: Listening for touch and gesture events can consume a significant amount of processing resources (equivalent to rendering several frames per second), depending on the computing device and operating system. It is often better to use mouse events when you do not actually need the extra functionality provided by touch or gestures. When you do use touch or gesture events, consider reducing the amount of graphical changes that can occur, especially when such events can be dispatched rapidly, as during a pan, rotate, or zoom operation. For example, you could stop animation within a component while the user resizes it using a zoom gesture.

That certainly makes sense, but I found that even using TOUCH_TAP, it was a quicker and far more responsive than listening for a CLICK event. There’s only one way to resolve this issue; try it yourself with a mobile app on a mobile device–any one you want. Use the Comment section to report what you’ve found. The sample app is as good as any for a trial, but feel free to create one of your own choosing.

As Chico Marx remarked in Duck Soup, Well, who you gonna believe, me or your own eyes? Believe your eyes and give it a whirl!

Just the Right Touch

Setting up the TouchEvent includes three imports:

• import flash.events.TouchEvent;
• import flash.ui.Multitouch;
• import flash.ui.MultitouchInputMode;

That contrasts with the single MouseEvent import required when using the mouse event. However, prior to using the TouchEvent class you have to set up your mobile context with the following line:

Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;

That statement focuses the input mode to touch instead of a mouse event. I was unable to get the TouchEvent to work without the statement; so, don’t forget to include it in your program.

Finally, you need an event listener, and it has the same format as a mouse event except you use TouchEvent. Also, instead of using CLICK, use TOUCH_TAP, as the following illustrates:

upBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);

With that knowledge, you’re all set to set up an app using TouchEvent.

Many Ears; One Handler

One of the big memory hogs in programming, especially noticeable in mobile devices, is event listening. Each event listener sets up a series of operations that have to keep listening for an event. Having a single event won’t help, but it’s a step in the direction of having a single listener (which will help). The following Client sets up an example of using the TouchEvent. All of the buttons are SimpleButton objects and the background is a big Sprite. Likewise, Sam3 is a Sprite that you can move around using tap on your mobile device.

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

package 
{
	import flash.display.Sprite;
	import flash.display.SimpleButton;
	import flash.events.TouchEvent;
	import flash.ui.Multitouch;
	import flash.ui.MultitouchInputMode;
 
	public final class Client extends Sprite
	{
 
		private static var leftBtn:SimpleButton=new Left();
		private static var rightBtn:SimpleButton=new Right();
		private static var upBtn:SimpleButton=new Up();
		private static var downBtn:SimpleButton=new Down();
		private static var bkground:Sprite=new Background();
		private var sam3:Sprite=new Sam3();
 
		public function Client()
		{
			addChildAt(bkground,0);
			setControls();
			setSamurai();
		}
 
		private final function setControls():void
		{
			Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
			upBtn.x = 825,upBtn.y = 19;
			upBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(upBtn);
 
			leftBtn.x = 740,leftBtn.y = 106;
			leftBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(leftBtn);
 
			rightBtn.x = 873,rightBtn.y = 105;
			rightBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(rightBtn);
 
			downBtn.x = 825,downBtn.y = 202;
			downBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(downBtn);
		}
 
		private final function setSamurai():void
		{
			sam3.x=(960/2); sam3.y=(640/2)+100;
			addChild(sam3);
		}
 
		private final function moveNow(e:TouchEvent):void
		{
			switch(e.target.name)
			{
				case "instance11":
				sam3.y -=5;
				break;
 
				case "instance1":
				sam3.x -=5;
				break;
 
				case "instance6":
				sam3.x +=5;
				break;
 
				case "instance16":
				sam3.y +=5;
				break;
 
			}
		}
	}
}

I set it up to be viewed from a landscape perspective because of a larger project I’m developing. Also, as you can see in the moveNow method, there are no “brakes” on the movement, and so the character can move anywhere, including right off the stage. Currently, I have a nicely working global movement system set up using a State Pattern, and I’d like to integrate both local and global movement into a single movement. Not only would this cut down on the number of listeners, but it would also provide a more interesting game. Figure 1 shows how it looks on an iPhone, and I’d like any feedback if tried on Android or other non-iOS devices.

The 960 x 640 size is compressed to fit in an iPhone environment

You also might want to swap out the TouchEvent for a MouseEvent and try it again in a mobile device. You’ll find that it gets “stuck” after a few clicks. As always, we’re interested in your comments and feedback.

Reaching out to Single Class for Event Handling

The first time I read Scott Petersen’s article on optimizing code for iOS devices, I got it wrong in terms of what he was trying to do in one of the optimizations. In re-reading it, I discovered an interesting structure Scott included, and while not a speed tweak in and of itself, I thought it deserved a short discussion and example.

The idea is to have one object with several methods handle all event requests. A single method handles a single request. As you know, event-requests expect one parameter–the event-object listening for the event. Once initiated, the event.target object can be used to determine an appropriate course of action. To see how this works, I put together a simple class for handling requests. It does nothing more than trace back the label of the UI that makes the initial request.

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

package 
{
	import flash.events.MouseEvent;
 
	public final class OneNav
	{
		public final function navNorth(e:MouseEvent):void
		{
			trace(e.target.label);
		}
 
		public final function navSouth(e:MouseEvent):void
		{
			trace(e.target.label);
		}
		public final function navEast(e:MouseEvent):void
		{
			trace(e.target.label);
		}
		public final function navWest(e:MouseEvent):void
		{
			trace(e.target.label);
		}
	}
}

With the OneNav class, the Client can then address all event handlers to the same class (object) and just append the specific method to the object. The general format is:

listeningObj.addEventListener(MouseEvent.CLICK,actionObj.actionMethod);

So now the developer can have everything to be handled in a single class with methods taking care of the details. If the details change, the developer can just go change the methods to reflect the changed details. To test it out, I’ve included the following Client 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

package 
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public final class Client extends Sprite
	{
		private var btnNorth:Button=new Button();
		private var btnSouth:Button=new Button();
		private var btnEast:Button=new Button();
		private var btnWest:Button=new Button();
		private var navNow:OneNav=new OneNav();
 
		public function Client()
		{
			btnNorth.addEventListener(MouseEvent.CLICK,navNow.navNorth);
			btnNorth.x=50;btnNorth.y=50;
			btnNorth.label="North";
			addChild(btnNorth);
 
			btnSouth.addEventListener(MouseEvent.CLICK,navNow.navSouth);
			btnSouth.x=50;btnSouth.y=80;
			btnSouth.label="South";
			addChild(btnSouth);
 
			btnEast.addEventListener(MouseEvent.CLICK,navNow.navEast);
			btnEast.x=50;btnEast.y=110;
			btnEast.label="East";
			addChild(btnEast);
 
			btnWest.addEventListener(MouseEvent.CLICK,navNow.navWest);
			btnWest.x=50;btnWest.y=140;
			btnWest.label="West";
			addChild(btnWest);
		}
	}
}

In some respects, this technique can add more work for the developer as he tries to figure out how to get the events to spark something on the viewing area even if he’s using a design pattern. This particular implementation reflects work I’ve been doing on the navigation portion of a game I’m developing, but the technique could apply to virtually any project. I would have to have the OneNav method call a State Pattern to get the appropriate image to show up on the stage. The would take a bit of doing. However, for some other kind of application, it might be just the thing you need.

A Final Word

One of the speed tweaks that Scott points out in this same article is using final in marking classes and methods. If you’re not subclassing a given class, you can mark it final as done in the Client class. Marking a class final allows compile-time determination of the exact function being called. When some methods of a class can be overridden, you cannot mark the class final but you can mark the individual method as final, as was done in the OneNav class.

As a matter of fact, I cannot think of a single use case where I would subclass a Client class, and so, it’s probably a safe bet to mark all Client classes as final. When developing with ActionScript 3.0 for mobile devices, every single speed tweak matters.

JavaScript can do Design Patterns

I’ve always liked JavaScript, but after going through this last project of creating a design pattern with JS, I find that I like ActionScript 3.0 even more than I did before. The biggest problems that I encountered with JavaScript is that different users slipped in different frameworks (e.g., Prototype.js) and didn’t seem to mention it. My goal was to create a JS design pattern with pure unadulterated JavaScript—not using JQuery, JSon or some other helpful framework. Now, don’t get me wrong—I appreciate a good framework as much as the next guy. However, when I’m trying to create a design pattern for a general language like JavaScript, I’d rather not have to have readers run out and get one framework or another. I wanted this to work with Plain Vanilla JavaScript. So that’s what you’re going to get.

To get started, I took a look at some articles on JavaScript and classes, inheritance and OOP in general. Then I looked at some implementations of JavaScript with a Chain of Responsibility pattern. A lot of them didn’t make a bit of sense, and that’s when I realized that they were slipping in different “helpers,” and so I went back to the most basic JavaScript OOP I knew of–the 1999 book, JavaScript Objects by Nakhimovsky and Myers. Starting there, I pretty much followed that Chain of Responsibility pattern we had in Part I of this two-part series. However, instead of a mobile browser detector, I created a “Help Desk.”

Before continuing, take a look at the “Help Desk” app made with the JS CoR:

Figure 1: JavaScript Chain of Responsibility Help Desk

Inheritance is a ‘IS-A’

First I made an abstract Handler class using a single concrete and single abstract method. It seemed to me that classes in JavaScript could be abstract simply by adding a method with no content. I came up with the following class:

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

function Handler()
{ 
	//Handler 'abstract class'
} 
 
Handler.prototype.setSuccessor=function(successor)
{ 
	this.successor=successor;
} 
 
Handler.prototype.handleRequest=function(req)
{ 
	//Abstract method overridden in concrete implementation
}

I realize that it looks strange compared to more mature OOP languages like ActionScript 3.0 (not to mention Java and C++), but remember, I’m using pure native JavaScript. You create the class by the simple expedient of a function. Then, I create the methods for the class by using a Class.prototype. The class Handler now has the setSuccessor and handleRequest methods, just as we had in the ActionScript 3.0 version. So, while it looks a little goofy for creating classes and their methods and properties, that’s how it’s done.

So far so good, and it’s not rocket science. However, the next part gets a little dicey and may pop a few brain nodes. When you extend a class in JavaScript, you first instantiate the parent class. As we all know, you do not instantiate abstract classes or any other interface. They’re extended or implemented. However, that’s not the case with JavaScript. Take a look at this first child class of Handler:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

//AS3DP inherits handler
AS3DP.prototype= new Handler();
 
function AS3DP()
{
	//AS3DP 'class'
}
 
AS3DP.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="as3dp")
	{
		document.write("Naturally you want to read <em>ActionScript 3.0 Design Patterns</em> and visit our blog at as3dp.com.");
	}
	else if(this.successor != null)
	{
		document.write("Not AS3DP<br/>");
		this.successor.handleRequest(this.req);
	}
}

If you recall, basic design pattern principles, a child class “Is-A” parent class. When a JavaScript object (like AS3DP) is instantiated, it is done by declaring itself as a new Handler(). So rather than becoming a child of the parent through extension, JavaScript uses the object prototype to declare itself as an instance of the parent. It’s actually easier to see that a child class indeed “Is-A” parent because the prototype declares itself as such.

As we have seen, the methods and properties have been created outside of the class constructors. Instead of being in the class, they are in the prototype. For now, you can think of the class as the “concept of an object” and it creates and stores the properties for that concept in prototypes. So, knowing that, we can create the rest of the concrete handlers:

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

//Game inherits Handler
Game.prototype= new Handler();
 
function Game()
{
	//Game 'class'
}
 
Game.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="game")
	{
		document.write("As the states change, you want a good state machine like the State Design Pattern.");
	}
	else if(this.successor != null)
	{
		document.write("Not State pattern<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//Algorithm inherits Handler
Algorithm.prototype= new Handler();
 
function Algorithm()
{
	//Algorithm 'class'
}
 
Algorithm.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="algorithm")
	{
		document.write("The Strategy Design Pattern lets you access different algorithms directly without having to use conditional statements!");
	}
	else if(this.successor != null)
	{
		document.write("Not Strategy pattern<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//Factory inherits Handler
Factory.prototype= new Handler();
 
function Factory()
{
	//Factory 'class'
}
 
Factory.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="factory")
	{
		document.write("The Factory Method design pattern will unlink the request to build an object from the actual object creation.");
	}
	else if(this.successor != null)
	{
		document.write("Not Factory<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//ToInterface inherits Handler
ToInterface.prototype= new Handler();
 
function ToInterface()
{
	//ToInterface 'class'
}
 
ToInterface.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="tointerface")
	{
		document.write("The first principle is to <em>Program to the interface and not the implementation.</em> When you declare a new object, type it to the object's parent class; not the object itself.");
	}
	else if(this.successor != null)
	{
		document.write("Not Program to Interface<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//Truth inherits Handler
Truth.prototype= new Handler();
 
function Truth()
{
	//Truth 'class'
}
 
Truth.prototype.handleRequest=function(req)
{
 
	document.write("You know I can't handle the truth! Go visit a muse, a swami, or 3-year old.<br/>");
 
}

As you no doubt have noticed, this Chain of Responsibility implementation is not about mobile devices and their languages. Instead, it’s a “Help Desk” that I think is more typical of what you may actually use a CoR pattern for—either in JavaScript or ActionScript 3.0.

All that’s left is to do with the JavaScript is to create instances of the different handlers and set the chain of successors. The “client” that makes the requests is the HTML5 UI.

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

//'Instantiate Concrete Handlers'
var as3dp = new AS3DP();
var game=new Game();
var algorithm=new Algorithm();
var factory=new Factory();
var tointerface=new ToInterface();
var truth=new Truth();
//Set successors
as3dp.setSuccessor(game); 
game.setSuccessor(algorithm); 
algorithm.setSuccessor(factory);
factory.setSuccessor(tointerface);
tointerface.setSuccessor(truth);

You can set up the successors in any way you want except the last one has to be to the Truth class. It has no successor and is meant to be the caboose of the chain. Before going on, place all of the JavaScript into a single file and save it as “HelpDesk.js” and put it in the same folder (directory) as the HTML5 program that follows.

The HTML5 Client

Like most work with JavScript, the UI is in HTML. This is no different. All it does is to call the top of the chain (AS3DP instance) and make a request. All of the requests look like the following:

onclick=”as3dp.handleRequest(‘algorithm’);

The click handler calls the top of the chain, and the Chain of Responsibility just chugs on through until it finds what you want. Here’s the whole HTML5 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

<!DOCTYPE HTML>
<html>
<head>
<style type="text/css">
body {
	font-family:Verdana, Geneva, sans-serif;
	color:#1D232;
	background-color:#dddcc5;
	font-size:12px;
}
h2 {
	font-family:"Arial Black", Gadget, sans-serif;
	font-size:24px;
	text-align:center;
	color:#611427;
}
form {
	color:#6A6A61;
}
h3 {
	background-color:#611427;
	color:#958976;
	font-size:18px;
}
</style>
<script type="text/javascript" src="HelpDesk.js">
</script>
<meta charset="UTF-8">
<title>Billz Help Desk</title>
</head>
 
<body>
<header>
  <h2>Billz Help Desk</h2>
</header>
<article>
<header>
  <h3>&nbsp;Chain of Responsibility: JavaScript</h3>
</header>
<section> This is a simple Chain of Responsibility (CoR) application. Each button represents a different request that the CoR will handle. In this case, the help is in the form of a 'Help Desk' and the CoR finds the appropriate response to the query.<br/>
  <br/>
  <form>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('as3dp');" />
    How do I learn about design patterns for ActionScript 3.0 <br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('game');" />
    I'm making a game where states keep changing. What would be a good design pattern for dealing with changing states?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('algorithm');" />
    My app involves a lot of problem solving with different algorithms? What's a good pattern for dealing with multiple algorithms?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('factory');" />
    Whenever I create a new object with my Client object, I build up dependencies. Is there a pattern to avoid such dependencies?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('tointerface');" />
    What is a primary guiding design pattern principle?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('truth');" />
    I want to know the truth!<br/>
  </form>
</section>
<br/>
<section>The CoR pattern works sequentially so that as it moves through the chain, you can see each rejected attempt to find the correct handler. (Normally, you wouldn't see those rejected handlers.) It is a very easy pattern to update and add additional handlers.</section>
</article>
</body>
</html>

So, now you’re all set to use JavaScript for design patterns. The plain vanilla JS has limitations doing OOP, but you can harness it and bend it to your OOP will. The many different frameworks that work in conjunction with basic JavaScript will make it look more like an OOP language, but you can get by without. There’s a lot to be done with even the most unadorned JavaScript, and I tested the app on an iPhone, and it works fine. However, I’ll bet that several of you can find better ways to handle either the JavaScript or HTML5 (or both) with design patterns, and we’d like to hear from you. Naturally, if you have a favored framework that makes OOP work more efficient, let us know—even better send a design pattern example.