Make Your Own Apps with Design Patterns

Having finally got my magical combination of permissions set up just so, the process began coming fairly easily. The problem is not Adobe, but rather getting the files from Apple just right. Once you get the files, you can use them over an over. One is a certificate file with a .p12 extension, and the other is a provisioning file. It looks like a lot of people are having the same problem because when I finally found a solution on the Web at StackOverflow several other developers indicated (with heart-felt thanks) that they were encountering the same problem. (The solution that worked for me was to start over and delete all provisioning profiles and login keychain.) So if you got your Apple iOS Developer ticket ($99 or free to University students/faculty), that’s just the first part. The next part is to hook up your iOS device (mine is a 3S iPhone) and using the Xcode development tools, go through a process that generates the files you need. The following image shows what these little gems look like. If you put those two files in with your AIR iOS files, it’s a piece of cake. (Go ahead and download the files as well.)

Same files can be used with different apps

Apple provides videos and a whole slew of tools and aids, and if you follow the instructions, you should be able to develop the right files. (Sad experience had led me to suggest that you take your time and follow instructions carefully.) Anyway, whether you get the certificate and provisioning files on the first time or whether you struggle like I did, once you’ve got them; they’re good for about four months. You can develop on either a Mac or Windows PC and re-use the same files on different apps. (I haven’t gone through the process that Apple has for getting an app in the App Store; so you’re on your own in that department.) The image on the right is a screenshot taken with an iPhone:

Animated tween, text and graphic

Step-By-Step

This section walks you through the process of working with a Flash Pro project set up for use with iOS. In the previous post on iOS, the sample project was to create banners that can be used in a Factory Method context by loading external .SWF files. On the iPhone, that didn’t work. The problem seemed to be the mobile device’s inability to grab the external .SWF files even though, the .SWF files were included in the General settings for the Included files window. So, using the same tweens, I created MovieClips and put them in the Flash Pro library and then set them up as classes. Then in the concrete product files, I just instantiated classes with the tweens instead of loading external .SWF files, and the rest of the program was unchanged. (That is where design patterns really shine—easy to make changes.)

Okay, now to step through the process. This was all done using AIR 3.0, Flash Player 11 public betas on a iMac running the new Lion OS. After you open a new AIR for iOS and write all of your code and add any graphics and text, the first step is to select the FLA file, make sure that nothing is selected on the stage and then click the little wrench icon next to the Player selection where it should indicate ‘AIR for iOS.’ That will open the AIR for iOS Settings window as shown in Figure 1:

Figure 1: General Settings of AIR for iOS

For getting started, choose Full screen instead of Auto orientation. Use the CPU for the Rendering processor, specify your device and choose the Standard resolution. The included files will be an .SWF and .XML file. Leave those alone, and for this app, you do not need to add any others.

For this next step, you’ll need both the certificate and provisioning files in the same folder with the other class files. So if you haven’t created those files and linked them to the device you’re testing it on; do so now. The click the Deployment button next to the General button at the top of the AIR for iOS Settings window. Figure 2 shows the deployment settings:

Figure 2: Deployment window

The password for the certificate is the one you entered when you created the certificate—not one associated with your computer. Use the search folder to find your Provisioning profile file. The App ID is the name you gave your initial FLA file—I’m in the habit of calling all of mine “Client,” but now I’ve got to think about what users will see on their mobile device..

This post does not get into the iOS deployment beyond the local development stage. So, select the “Quick publishing for device testing” or “Quick publishing for device debugging.” I selected the former because I chose to do the debugging using the standard Flash tools. After all I went through to get the certificate and mobile provision files to work right, I wasn’t about to tempt fate just yet and do more than the minimum.

This final step is fun. You can easily create your own iOS icon. Here’s what you need to do to get started:

1. Create a square image with your logo or some symbol you want to use to identify you application. Save it as a .PNG file. (In the image at the top of this post, you can see the two application icons using the Sandlight logo.) Be sure that the image has equal width and height.
2. Save three images in sizes 29 pixel square, 57 pixel square and 512 pixel square. Depending on the mobile device, you may want to create other sizes as well. I started off with the Adobe Illustrator version and saved each size as a PNG file.
3. Place the three image files in a folder named “icons” and place the icons folder in the directory where you are creating your mobile app.

In Figure 3, you can see the preview window showing the image used for the application described in this post.

Figure 3: Assigning icons for app image

Be sure to click each icon size for each of the three sizes and load the URL (icons/iconXX.png) before you click OK. Note also that two of the icons are settings for iPads, and so if you have an iPad, create image files for those as well.

Installing your iOS on your Mobile Device

Now you’re set to Publish your files required for an iOS mobile app. When you click “Publish” you will find that it takes a while to process everything. Once you’re finished, you will see all the files generated for your iOS device. Figure 4 shows the files you will see—including the all-important .IPA file.

Figure 4: Files used and generated

As you can see in Figure 4, one of the files is named BannerFactory.ipa. That is the file that will install your app onto your iOS mobile device. Connect your iPhone or iPad or iWhatever that runs on iOS, and double-click the IPA file and it will upload your app into the iTunes Apps folder. (On your iTunes, click Apps in the LIBRARY folder, and you should see your new application as shown in Figure 5.)

Figure 5: iTunes Apps folder

If you see your application icon and file, you’ve been successful—up to this point. The last step is to install your app onto your mobile device. The final step is to select your device and then check your application Sync. Figure 6 shows iTunes with your application selected (checkbox) and ready for Sync.

Figure 6: App set for installing in iPhone

Note in Figure 6 that the iOS device is selected under DEVICES in the left panel and that the new application (BannerFactory) has a check next to it. Click the Sync button (or Apply and then Sync) and if you have your device properly identified, you will see your icon and app on your mobile device.

Animated Banners are easy with Flash

I’ve never been a big animated banner fan. They are contrary to everything I know about good Information Design. However, done right, they can add pizazz to a page. The trick is to make sure that after the banner has performed its show once to stop it. Like a twice told joke; the animation is only interesting the first time. After that, the banner needs to serve as a branding decoration. Further, you can make your opening page a bit more interesting by having multiple banners randomly appear. Every time the visitor opens the mobile app, he/she can look forward to seeing a different banner appear. Using a Factory Method design pattern, that can be easy to create and (more importantly) update. In this post I want to get set up with a simple (but handy) Factory Method design pattern for calling up different banners; so it can be regarded as a beginner’s introduction to the Factory Method pattern.

The plan is to walk through an iOS implementation of ActionScript 3.0 in both Flash Pro and Flash Builder. However, first I want to get the design pattern squared away, and then we can provide total focus on the iOS issues. Further, if you would rather create an app using Android or Blackberry, you can just use the code and design pattern is this post and forget about the subsequent iOS posts that use the design pattern shown in this post. I did not provide the downloads for this post because I used a generic ActionScript 3.0 implementation, and so you can just cut and paste the code in the listings that are part of this post. (The downloads for the iOS implementations will be provided in subsequent posts.) To get an idea of what this does, click the Play button and refresh the HTML page to see how one of two animated banners appear.

The Factory Method in an iPhone

Here, I want to use the Factory Method, but I’m not going to explain it (again.) That’s been done here in our blog and in Chapter 2 in our book. Here I just want to explain how it is used to generate random banners for an iPhone (or whatever other mobile or non-mobile device you want to use it with.) The factory (Creator) instantiates any number of concrete Product instances. As implemented in this example, each concrete product requires a concrete factory instance. I added a helper class, RandomSelector to generate random numbers in a range. The Client pulls in a random value (between 0 and 1) and then using a switch statement calls a method to request a SWF file to play an animated banner. (Those among you who want to create your own SWF banner and pull it up instead of the ones you see in the example can do so easily.) Figure 1 shows the File Diagram of the Factory Method as used in this implementation to provide an overview.

Figure 1: File Diagram of Factory Method Implementation

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

package
{
	import flash.display.Sprite;
	public class Client extends Sprite
	{
		private var banner:ICreator;
		private var rs:RandomSelector=new RandomSelector();
		private var choose:uint;
		private var tucker:Sprite=new Sprite();
		public function Client()
		{
			/*Add more banners
			Change the first argument of randomChoose()
			to the total number of banners minus 1.  */
 
			choose=uint(rs.randomChoose(1,0));
 
			switch(choose)
			{
				case 0:
				doCartoon();
				break;
 
				case 1:
				doLogo();
				break;
			}
 
		}
 
		private function doCartoon():void
		{
			banner=new MakeCartoonBanner();
			tucker.addChild(banner.factoryMethod());
			tucker.x=25; tucker.y=113;
			addChild(tucker);
		}
 
		private function doLogo():void
		{
			banner=new MakeLogoBanner();
			tucker.addChild(banner.factoryMethod());
			tucker.x=25; tucker.y=113;
			addChild(tucker);
		}
	}
}

The one change made to the Client that will not be in the final version is the addition of the tucker Sprite object. The tucker object was added to position the display in the middle of the graphic iPhone that you saw when you clicked the Play button. In the iPhone implementation, it will use the 0,0 position and not need a positioning sprite.

The class for the random selections is a standard algorithm for generating ranged values. It could have easily gone into the Client class, but it has value for re-use and so is cast into a class.

1
2
3
4
5
6
7
8
9
10

package
{
	public class RandomSelector
	{
		public function randomChoose(top:Number, bottom:Number = 0):Number
		{
			return Math.floor(Math.random()*(1+top-bottom))+bottom;
		}
	}
}

The ICreator (Factory) interface and concrete factories instantiate their respective products. If you look at the Client, you will see that the banner object is typed as an instance of ICreator, and so it can be used with any of the concrete factories. For beginners, this is why programming to the interface instead of the implementation is important—it only commits to the interface allowing for loose binding and more flexibility.

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

//Factory interface
package
{
	import flash.display.Sprite;
 
	public interface ICreator
	{
		function factoryMethod():Sprite;
	}
 
}
 
//Concrete factory for Cartoon Banner
package
{
	import flash.display.Sprite;
 
	public class MakeCartoonBanner implements ICreator
	{
		private var logoNow:IProduct=new CartoonBanner();
		public function factoryMethod():Sprite
		{
			return logoNow.moBanner();
		}
	}
}
 
//Concrete factory for Logo Banner
package
{
	import flash.display.Sprite;
 
	public class MakeLogoBanner implements ICreator
	{
		private var logoNow:IProduct=new LogoBanner();
		public function factoryMethod():Sprite
		{
			return logoNow.moBanner();
		}
	}
}

Notice in the code for the concrete factories that the product objects are programmed to the IProduct interface rather than the concrete ones. So, both the Client class and concrete factory classes are typing variables to the interface instead of the implementations that they instantiate. As a fundamental principle to promote loose coupling, it is the first and most important design pattern principle to get into the habit of using.

Finally, the Product Interface and classes are pretty standard load and return objects. Each concrete product loads up an SWF file and sends the results to the Client. Instead of a SWF file, the same code would work with a graphic file as well. The IProduct interface has a single method, moBanner() that returns a Sprite. (‘moBanner’ refers to’ Mobile Banner’, but sounds more interesting.)

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

//Product Interface
package
{
	import flash.display.Sprite;
 
	interface IProduct
	{
		function moBanner():Sprite;
	}
}
 
//Concrete Product--Cartoon Banner
package
{
	import flash.display.Sprite;
	import flash.display.Loader;
	import flash.net.URLRequest;
 
	public class CartoonBanner implements IProduct
	{
		private var loader:Loader=new Loader();
		private var req:URLRequest;
		private var transporter:Sprite=new Sprite();
 
		public function moBanner():Sprite
		{
			req = new URLRequest("CartoonFace.swf");
			loader.load(req);
			transporter.addChild(loader);
			return transporter;
		}
	}
}
 
//Concrete Product--Logo Banner
package
{
	import flash.display.Sprite;
	import flash.display.Loader;
	import flash.net.URLRequest;
 
	public class LogoBanner implements IProduct
	{
		private var loader:Loader=new Loader();
		private var req:URLRequest;
		private var transporter:Sprite=new Sprite();
 
		public function moBanner():Sprite
		{
			req = new URLRequest("LogoGrow.swf");
			loader.load(req);
			transporter.addChild(loader);
			return transporter;
		}
	}
}

In looking at the code, there seems to be a lot of code for some pretty simple operations. I considered adding a string parameter to the factory method to call the required SWF file through a product. I could conceivably create a program with one concrete factory and one concrete product with all of the differences handled through the parameter. However, this design is a nice simple tool to use in working with an iOS design and having multiple concrete factories and products seems to be a better test of using a design pattern with iOS.

Preparation for the iOS Building

This post is designed to give you some time to familiarize yourself with the design pattern prior to putting it into an iOS application. To prepare for the iOS application, you have two routes:

1. Go to http://developer.apple.com/programs/ios/ and cough up $99/year to enroll in the iOS developer program.
2. Go to http://developer.apple.com/programs/ios/university/ and sign up for the iOS Developer University Program for free. This requires someone in your major/department (usually the dept chair) to sign off on it. It can be handled easily via email and constant whining.

If you don’t have an iOS Developer ticket, there’s not much point in even trying to get an Apple mobile app working. However, if you are considering the program but not want to fork over $99 just yet, you can wait until the next post to see how it’s done and whether it’s worth it.

Gentle Readers: When you click the Play button in this post, the UI that appears isn’t very pretty. That’s because I have no graphic design skills. By changing the requests in the Client class, you could easily make a much nicer UI. Why not give it a shot and send us your revised Client request set? You can even add new Concrete Creators and Products. Send in your refinements to our comment section. Either that or click Play and see Ugly!

The Concreteness of Abstraction

The first time I went to London, I picked up a Tube Map (Map of the London Underground) and was able to get where I wanted to go. The map of London’s tube is a masterpiece of clarity and abstraction. Based on electrical circuitry, it’s very easy to find one’s way around London even on a first visit. Likewise, Paris’ Metro has an almost identical type of map for it’s underground system, and it too is easy to find where you want to go. The secret is having just enough detail to use the system and not so much detail to make its use confusing. Further the coding is clear: different colors depict different named lines. Bakerloo is brown, Circle is yellow, Central is red and District is green. At a glance you see that arriving at Heathrow Airport, you take the Piccadilly line into town (purple) and switch lines wherever you see a white circle off the Piccadilly line. The details are not provided, and the Thames river does not run along the neat geometrical angles shown on the Tube Map. It’s just a reference point and lets you know whether you’re north or south of the Thames. The river’s or tube’s exact shape doesn’t matter; the whole thing is an abstraction of London’s subway system and a major feature of the city. The details would just get in the way of clarity.

Abstraction in OOP and Design Patterns works the same way. An object only exposes as much information as the client (requesting object) requires. The perfect abstract structure in a design pattern is an Interface because it is nothing but abstract methods. The only way to really appreciate abstraction is to see it in action; so this post concentrates on demonstrating abstractions in a fundamental design pattern—the Factory Method.

Two Interfaces and some Concrete Classes

The Factory Method requires a factory interface called Creator and a “product” interface called Product. The Creator interface provides a factory method function to create concrete instances of products through the abstract Product interface. In this implementation of the Factory Method Design Pattern, both abstract participants are interfaces (Creator and Product). Figure 1 shows the relationship between the participants in the design pattern:

Figure 1: Factory Method Design Pattern

In a step-through of the pattern you see the following:

1. Client wants a certain product. Makes request through the Creator (factory)
2. Concrete creator specifies the concrete product and instantiates an instance, returning it to the Client

It’s a very straightforward pattern, but often beginners will puzzle over why all the work simply to get a class instance? The answer to that question lies more in the larger implementations and re-use of the pattern than it does in the small example used here. However, a good general answer is that it loosely binds the product to the request. If you change the product’s contents, you should not have to change anything else in the pattern. The Client makes the request through an abstraction and really doesn’t care about the details of the product. If the product is changed, the exact same request brings up a different object. However, nothing has to be changed to access the new object. Use the buttons below to download and play the example:

Chapter 2 in our book, and other posts on this blog go into detail about the Factory Method. Here the focus is on abstraction, and the Factory Method is merely used to illustrate the power of abstraction. In order to show the range of products that can be generated from the same abstract interfaces, I used both component UIs and graphic background Shape objects as products.

Using Abstractions and Programming to the Interface

One of the key principles of design pattern programming is,

Program to the Interface and not the implementation….

In order to see both how abstractions are used and how relations work in the n the Factory Method pattern, Figure 2 shows code snippets related to each of the participants (classes and relationships).

Figure 2: Coded Elements of the Factory Method pattern

The Client, Creator and Product

This section shows the code for all of the participants. (You can download it all if you’d like to follow this post using Flash or Flash Builder by clicking the Download button above.) I’d like to start with the Client and then examine the abstract interfaces. We’ll start with the Client:

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 Client extends Sprite
	{
		private var bkdp:Creator=new MakeBackdrop();
		private var btn1:Creator=new MakeButton();
		private var btn2:Creator=new MakeButton();
		private var txtA:Creator=new MakeTextArea();
		private var txtI:Creator=new MakeTextInput();
 
		public function Client()
		{
			addChild(bkdp.factoryMethod(12,15,"0xcc0000"));
			addChild(btn1.factoryMethod(20,30,"Top"));
			addChild(btn2.factoryMethod(20,60,"Bottom"));
			addChild(txtA.factoryMethod(130,30,"Lots of text can go here!"));
			addChild(txtI.factoryMethod(20,100,"Input here"));
		}
	}
}

In looking at the Client, you can see that all requests are through the Creator interface. Because all of the concrete creators (factories) implement the Creator, the objects can be typed to the interface and not the concrete factories. Note that while the Client is requesting concrete Products, products are not even mentioned once. The factoryMethod() takes care of making the request that delivers the product. Think of it as requesting a cup of coffee from a barista. You put in your order for a Café Latte Uruguay Negro (my coffee house is more pretentious than yours). You don’t care about how the barista makes the cup of coffee you ordered; you just know to ask him for the specific product you want, and he’ll take care of it. The Client is doing the same thing.

The Creator (factory) interface is simple because it is abstract. You provide the framework, and the implementations will take care of the concrete elements.

1
2
3
4
5
6
7
8

package
{
	import flash.display.Sprite;
	interface Creator
	{
		function factoryMethod(ex:Number,why:Number,lbl:String):Sprite;
	}
}

As you will see in the concrete implementations of the Creator, you can do a lot of different things with the three parameters.

Next, the Product interface looks very similar to the Creator. In fact, other than different names for the interface and method, they’re the same. The don’t have to be, but in this case they just happen to be. However, as you will see, the implementations of each are different individually and as a group.s

1
2
3
4
5
6
7
8
9

package
{
	import flash.display.Sprite;
 
	interface Product
	{
		function uiProduct(ex:Number,why:Number,lbl:String):Sprite;
	}
}

Going back to the example of the London Tube Map, you can see that the abstractions have very little detail. One “sounds like” it makes something (factoryMethod()) and the other “sounds like” a product (uiProduct()). However, you have enough information to know that each does something different.

The Concrete Implementations: Factories and Products

The final step in working with the abstractions in the interfaces is to make them do something concrete. First, we’ll deal with the factories. The following code creates factories for each of the products:

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

//Make buttons
package
{
	import flash.display.Sprite;
 
	public class MakeButton implements Creator
	{
		private var btn:Product = new UiButton();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return btn.uiProduct(ex,why,lbl);
		}
	}
}
 
//Make backdrop
package
{
	import flash.display.Sprite;
 
	public class MakeBackdrop implements Creator
	{
		private var bkDrop:Product = new UiBackdrop();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return bkDrop.uiProduct(ex,why,lbl);
		}
	}
}
 
//Make TextAreas
package
{
	import flash.display.Sprite;
 
	public class MakeTextArea implements Creator
	{
		private var txtArea:Product = new UiTxtArea();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return txtArea.uiProduct(ex,why,lbl);
		}
	}
}
 
//Make TextInput
package
{
	import flash.display.Sprite;
 
	public class MakeTextInput implements Creator
	{
		private var txtInput:Product = new UiTxtInput();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return txtInput.uiProduct(ex,why,lbl);
		}
	}
}

As you can see, they’re all pretty much the same. They declare instances as a Product but instantiate them as concrete product implementations. There’s not a lot of variety; just the name of the instantiated concrete product.

The concrete products show a great deal of variation, though. This demonstrates the flexibility of abstractions and the loose bindings between a client object and the requested products.

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

//Button
package
{
	import fl.controls.Button;
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class UiButton implements Product
	{
		private var btnPack:Sprite=new Sprite();
		private var button:Button=new Button();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			button.label = lbl;
			button.addEventListener(MouseEvent.CLICK,btnBusiness);
			button.x = ex;
			button.y = why;
			btnPack.addChild(button);
			return btnPack;
		}
 
		private function btnBusiness(e:MouseEvent):void
		{
			trace("Whatever business you have in mind....");
		}
	}
}
 
//Backdrop
package
{
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class UiBackdrop implements Product
	{
		private var backdropHolder:Sprite=new Sprite();
		private var backdrop:Shape=new Shape();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			backdrop.graphics.beginFill(int(lbl));
			backdrop.graphics.lineStyle(0,0x0000cc);
			backdrop.graphics.drawRect(ex, why, ex+100, why+100);
			backdrop.graphics.endFill();
			backdropHolder.addChild(backdrop);
			return backdropHolder;
		}
	}
}
 
//Text Area
package
{
	import fl.controls.TextArea;
	import flash.display.Sprite;
 
	public class UiTxtArea implements Product
	{
		private var taPack:Sprite=new Sprite();
		private var txtArea:TextArea=new TextArea();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			txtArea.text = lbl;
			txtArea.width = 200,txtArea.height = 200;
			txtArea.x = ex;
			txtArea.y = why;
			taPack.addChild(txtArea);
			return taPack;
		}
	}
}
 
//Text Input
package
{
	import flash.display.MovieClip;
	import fl.controls.TextInput;
	import flash.display.Sprite;
 
	public class UiTxtInput implements Product
	{
		private var tiPack:Sprite=new Sprite();
		private var txtInput:TextInput=new TextInput();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			txtInput.text = lbl;
			txtInput.x = ex;
			txtInput.y = why;
			tiPack.addChild(txtInput);
			return tiPack;
		}
	}
}

As you can see in the different implementations of the Product object, there’s an immense variation. The Factory Method uses abstraction to make it very easy for the Client to request what’s needed, provide loose binding, and do it while allowing enough room for variation to do whatever the developer wants.

The best part comes when I decide to change something. Suppose I decided I want to make my own TextArea object using a TextField, TextFormat and other coded objects so I don’t have to worry too much about component differences between Flash Professional and Flash Builder. I can simply change my implementation in the concrete product without affecting anything else. In other words, I can make huge programs without having to start all over from scratch.

Thanks abstraction!

Lazy Bones

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

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

Southern Brazil

New England

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

Talk to the Factory

The Factory Method design pattern is made up of a Creator (Factory) interface with concrete creators that instantiate concrete products represening implementations of a Product interface. The Creator contains an abstract FactoryMethod() operation that each concrete creator implements. Figure 1 shows a typical factory pattern with different shapes implied from the concrete creators and products. The shapes are representatives of any objects that the developer wants to request using the FactoryMethod() operations.

Figure 1: Factory Method Class Diagram

The class diagram accurately portrays the role of the concrete factories—they instantiate the products indicated by the dashed arrows. The factories are more like car dealerships than they are “factories.” The dealerships order (instantiate) a completely built car. They don’t build them—they get them. If you have parameterized products; then perhaps you can think of the instantiation process as one where the objects are “built” by the concrete factories that pass the arguments, but in this example, think of the concrete creator (factory) classes as “auto dealerships” and not “auto factories.”

Figure 2 shows how the client makes its request and the links between the participants:

Figure 2: Client makes request

To get a better idea of the details of the client’s request, look at Figure 3. The object being requested is a Brazillian state named Paraná (not to be confused with the fish, piranha or paraña). Note that the variable named pirana is typed as a Factory—the interface. Then the request is made by instantiating a concrete factory class, MakeParana, an implementation of the Factory abstract class. (Programming to the interface; not the implementation.)

Figure 3: Client makes request using a Factory object

To help get a better idea of how that request is made in the larger context of a Factory Method design pattern, Figure 4 shows just those classes involved in the request in a file diagram. The request is sent to the MakePirana concrete factory through the Factory interface (an abstract class). The factory instantiates a concrete Product instance named Pirana.

Figure 4: Files used in Pirana object request

If I wanted to change the character of the Pirana object to something else, the Client could care less. It just makes the request to the concrete factory object and lets the factory worry about instantiating the object. Let’s say that instead of the state of Pirana, I wanted to use the design pattern to get the state of Connecticut. I wouldn’t change the request to the factory; I’d change the object that the factory instantiates and returns to the Client.

The Abstract Factory and Product

Both of the interfaces in this implementation of the Factory Method are made up of abstract classes. The Factory class holds a reference to the Product class and an abstract factoryMethod() operation. The details of the factoryMethod() are left up to the concrete factories to implement. Figure 5 shows the Factory abstract class:

Figure 5: The Factory Interface (abstract class)

Nothing is declared and the protected variable, product is only declared as a Product type. Product, is an abstract class and so the product variable will have to be instantiated as a concrete implementation of Product and not Product itself. (You cannot instantiate an abstract class.)

The Product class is similar in that it is abstract and nothing is implemented. Figure 6 shows how it is built:

Figure 6: The abstract class Product

Originally, I had the Product class subclass Sprite, but I realized later that I did not need to do that. Each of the product objects were already children of the Sprite class, and so I had all of the properties and methods in the Sprite class I needed. By not subclassing the Sprite, the Product class is looser because it has no binding through subclassing. Importing the Sprite package is enough to reference the Sprite as the return type of the getObject() method and objectNow property.

Implementing the Concrete Factories (with Lazy Instantiation) and Products

All that’s left is to implement are the Factory and Product interfaces (abstract classes). The objects that are used to actually show images on the screen are Library Sprites. I just drew the different states (estados) using Flash tools and converted them into MovieClip symbols. Then, I converted the MovieClip classes into Sprite classes by changing the Base class from flash.display.MovieClip to flash.display.Sprite.

The concrete factory that calls the requested Parana state, checks to see if the product already exists, and if not, produces one. Then, using the product object it uses the getObject() method to get the requested product. Figure 7 shows how each of the concrete factories are coded–the only difference being that they instantiated different concrete products:

Figure 7: Concrete factory instantiates requested object

We can see the lazy instantiation in the conditional statement that is looking for an uninstantiated product, and if the product does not exist as an instance, it creates one. The product property is inherited from the Factory abstract class. The product is initialized in the Factory class as a Product type—that’s why you don’t see any data type assigned to the product in the concrete factory. So while the product is unimplemented, it has been initialized. This binds the product only to the Product interface and not any single product implementation. As a result, the product object can be used to instantiate any of the concrete properties. This is what makes programming to the interface and loose coupling so valuable.

Finally, we come to the concrete products. Each products extends the Product class and implements the getObject() function. The objNow property (inherited from the Product abstract class) instantiates a Sprite object from the Library. The Sprite can come from any source where a Sprite can be stored. The important fact is that the object is a Sprite and has key Sprite properties and methods. In this case, all we need are the horizontal (x) and vertical (y) properties. Figure 8 shows how the Parana product is created;

Figure 8: Concrete Product class

The important features of this example lies not what was done initially, but rather how it was reused to create a similar application for a different region. Likewise, the concrete factory and product classes follow the OOP single responsibility principle—each has a single responsibility that is loosely bound and re-useable. For example, the following two classes show how the same application was reused to create the New England version of the same program:

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

//Connecticut Factory
package
{
	import flash.display.Sprite;
 
	public class MakeConn extends Factory
	{
		public override function factoryMethod():Sprite
		{
			if(! product)
			{
				product=new ConnProd();
			}
			return product.getObject();
		}
	}
}
 
//Connecticut Product
package
{
	import flash.display.Sprite;
	public class ConnProd extends Product
	{
		public override function getObject():Sprite
		{
			objNow=new Conn();
			objNow.x=188.45, objNow.y=321.75;
			return objNow;
		}
	}
}

As you can see, the concrete factory and product are the same as those for the Brazilian states. The Factory and Product abstract classes are identical.

One Year of Programming Experience 20 times

You may have heard programmers proclaim,

I’ve been programming for 20 years, blah, blah, blah….

While such programmers may have a wealth of knowledge from their experience, they may have just been doing the same kind of programming for 20 years. Years ago, I heard a police officer remark about one of the older (and not too effective) officers as a

…guy who had 1 year experience 20 times.

Essentially the police officer who made that comment was saying that the old-timer never tried to keep up his skill levels with new knowledge. He just kept doing the same old thing again and again. That can happen at any age, and in computing, it’s a recipe for disaster.

When I discovered OOP and then Design Patterns, I realized that I had been like that old cop who kept doing the same thing over and over again. To be sure, I learned several new languages ranging from machine/assembly languages to high level languages like BASIC and even PostScript—and just about everything in between. However, while different computer languages have different lexicons, sequential and procedural programming are still S&P programming no matter what language you’re in.

To break those (bad) habits, design patterns and the OOP that goes with them, forced me to think in different ways approaching programming problems. Instead of thinking in terms of a series of steps, I started to think in terms of loosely bound objects communicating with one another. The only sequences were little ones inside the methods and assigned values to properties—and many of those were just for using other objects. The design patterns themselves became “cheat sheets” where I could more easily envision how objects could be arranged to communicate and achieve a goal.

This particular example somehow brought many of the lessons I’ve learned from design patterns home. It wasn’t until the last minute that I decided to make another regional map where I could demonstrate re-use of design patterns (Southern Brazil to Northeast US). Because I waited until the last minute, that was about all the time I had—that last minute. However, once I finished the graphic sprites, everything else fell into place. I just re-used the structures and the communication systems from the original app. It may sound funny to voice it, but programming to the interface really saved my bacon. Here I had a whole new set of objects I had to get singing in the same choir, but I knew that as long as I paid attention to the interface, everything would work together—that’s 27 classes scaled down to 17 for a new application.(That’s not even counting the Sprite classes with the graphics!) And everything worked out fine.

Try doing that without a design pattern. Spaghetti city!

Lazy Initialization

Just be careful not to call factory methods in the Creator’s constructor—the factory method in the ConcreteCreator won’t be available yet. (page 112)

The comment was directed at some issues in C++ which may or may not have any bearing on ActionScript 3.0, but just in case it did, I continued reading. The point being made was you can avoid these problems by accessing products only through accessor operations that create products on demand. So what are accessor operations? Generally these are public methods that you can call to initiate creation of a product.

Time Out! Before we get too far ahead of ourselves, you can download all of the .as files for the Factory Method example by clicking the following button:

The example is a simple one that creates three different shapes—ellipse, rectangle and triangle. Figure 1 shows how the Client arranged them to display a house in front a a pond with a cloud overhead:

Figure 1:Triangle, Ellipse and Rectangle Products

The program uses concrete creators to fetch shapes. The Client makes requests that size, color, and position the shapes.

Don’t Enslave Your Constructor Functions

This issue of the constructor functions reminded me of a post by Miško Hevery, the guy at Google who helps set Google’s programming standards. One of the key flaws in a program is where the constructor does real work. Besides violating the single responsibility rule, Miško goes on to explain the tell-tale signs that one has used his constructor function with outrageous disregard for both agile programming and loose coupling. As a result of reading Hevery’s work, a year or so ago, I began to seriously gear back on using a class’ constructor function; primarily by not including one in most of my classes. (My Client class is a glaring exception to the rule.) I’d usually have just the properties and operations (methods, functions) that I needed. The properties would initialize themselves—sort of. They’d be given an ID and then typed and that was all. The child classes could then use them in operations. Whenever I needed something, the Client would type a request to the interface (including abstract classes) and then make a request through concrete method in an operation. With the Factory Method, I make requests to the ConcreteCreator through the abstract Creator class.

In returning to GoF, they point out,

Instead of creating the concrete product in the constructor, the constructor merely initializes it to 0. (Page 112)

In this discussion, they note that Factory methods in C++ are always virtual functions. WTF?! (What’s That Function?!) Simply stated, any function that can be overridden in the child classes is a virtual one. Well, we can do that in ActionScript 3.0. In fact, that’s what we do in creating Abstract classes. (Why we can override and yet not have real Abstract classes is still a mystery to me.)

But what about the constructor function—especially in an Abstract class that you cannot instantiate anyway? Well, there’s an automatic constructor in all classes; so if we initialize a product like this:

protected var product:Product;

It will be automatically initialized in the Creator. Or will it? The answer is sort of. The accessor is going to return the product in the ConcreteCreator, but it first checks to see if it exists. Even though we initialized the product in the Creator which is inherited by the ConcreteCreator, it does not exist until a new instance is declared.

The process of first checking to see if the product exists before instantiating it is called…ta da!…lazy initialization!

So, while ActionScript 3.0 may not be exactly like C++ in how it manages memory, they appear to share lazy initialization. In our Factory Method design, the following shows the generic code for this kind of lazy initialization (in a ConcreteCreator class that has inherited the product property from the Creator class):

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

override public function factoryMethod():Object
{
	if (! product)
	{
		product=new ConcreteProduct();
		trace("new one");
	}
	else
	{
		trace("reusing existing product");
	}
	return product.getProduct();
}

The above code includes trace statements to see both new and existing products. All of the ConcreteCreator classes include this type of lazy initialization.

To understand how memory is allocated you need to understand something about garbage collection, and Grant Skinner’s post on this topic is an excellent resource. Likewise, Grant Skinner’s article on memory management is equally helpful in understanding the issues here that involve creating optimum code. Keep in mind that we’re dealing with lazy initialization, and garbage collection and memory management are the details of how existing objects are allocated memory space and how they come to be deallocated in the process of garbage collection. Assume that the Flash player will handle memory allocation (and deallocation) as best it possibly can, but we need to be cognizant of what we’re doing as well. In setting up our Factory Method, we have learned that initialization does not create an object.

A Simple Factory Method Program

I’ve created a simple Factory Method example that displays different objects. Each of the three objects is a Product subclass and each of the three objects has its own concrete creator, all subclasses of a Creator class. The Product and Creator classes are abstract and so we can think of them as interfaces—program to the interface and not the implementation. All of the object creation begins with the Client class with a call to the factory to create the desired object; so the Client needs to have control over object creation. Figure 2 shows the class diagram for the program:

Figure 2: Factory Method with Lazy Initialization

As you can see, it’s a pretty standard Factory Method design pattern, and if you’re just getting started with this pattern, it’s a good one to use as a generic base.

Creator Classes

Beginning with the Creator, we’ll work our way to the Client making requests. The Creator class is set up as an Abstract class where we can lazily initialize a product object:

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

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

The product instance initialization provides a type, instance name and accessor. As there is no constructor function, one is automatically created and so product is available as a property and can be passed to the Creator child classes—the ConcreteCreators.

The key method for creators is the factoryMethod. Here, I gave it five parameters one each for x and y position, color, and width and height. This gives the user more flexibility, but I have to admit that I’m not crazy about that many parameters. In the past, I’ve used a single array where all of the parameter values can be placed. The ConcreteCreators all implement the factoryMethod by setting up lazy initialization (checking a product to see if it exists before creating a new one). I’ve placed all of the three ConcreteCreators 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

//Create Rectangle
package
{
	import flash.display.Shape;
	public class RecMaker extends Creator
	{
		override public function factoryMethod(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			if (! product)
			{
				product=new RecShape();
				trace("new one");
			}
			else
			{
				trace("reusing existing product");
			}
			return product.getFigure(hor,v,col,w,h);
		}
	}
}
 
//Create Ellipse
package
{
	import flash.display.Shape;
	public class EllipseMaker extends Creator
	{
		override public function factoryMethod(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			if (! product)
			{
				product=new Ellipse();
				trace("new one");
			}
			else
			{
				trace("reusing existing product");
			}
			return product.getFigure(hor,v,col,w,h);
		}
	}
}
 
//Create Triangle
package
{
	import flash.display.Shape;
	public class TriMaker extends Creator
	{
		override public function factoryMethod(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			if (! product)
			{
				product=new Triangle();
				trace("new one");
			}
			else
			{
				trace("reusing existing product");
			}
			return product.getFigure(hor,v,col,w,h);
		}
	}
}

The manner in which lazy initialization is set up in each of the factoryMethod() methods shows when a new product is created and when an existing one is used. (If you want to clean it up, you can just use the first if statement and remove both the else clause and trace statements.)

Each of the creators returns a Shape object by calling the Product method, getFigure(). All of the concrete creator classes do pretty much the same thing, and their only difference is the concrete product each calls and returns.

Product Classes

The Product class is another abstract one with a single property and method. However, instead of a Product property, it has a Shape property. It is only initialized in the abstract class and then instantiated in the concrete products.

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

package
{
	import flash.display.Shape;
	import flash.errors.IllegalOperationError;
 
	// ABSTRACT Class (should be subclassed and not instantiated)
	class Product
	{
		protected var figure:Shape;
 
		public function getFigure(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

Each of the ConcreteProduct classes draws the desired shape by overriding the getFigure() method. and creates a new Shape instance from the figure Shape object it inherits. (Again we find lazy initialization.) I had thought of instantiating the Shape in the Product abstract class and then each method would not have to. However, I’d been warned by Miško Hevery’s article about using the new keyword in a constructor function let alone an abstract 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

//Draw Rectangle
package
{
	import flash.display.Shape;
 
	public class RecShape extends Product
	{
		public override function getFigure(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			figure=new Shape();
			figure.graphics.beginFill(col,.5 );
			figure.graphics.drawRect(hor, v, w, h)
			figure.graphics.endFill();
			return figure;
		}
	}
}
 
//Draw Ellipse
//Concrete Product
package
{
	import flash.display.Shape;
 
	public class Ellipse extends Product
	{
		public override function getFigure(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			figure=new Shape();
			figure.graphics.beginFill(col,.5 );
			figure.graphics.drawEllipse(hor, v, w, h)
			figure.graphics.endFill();
			return figure;
		}
	}
}
 
//Draw Triangle
//Concrete Product
package
{
	import flash.display.Shape;
 
	public class Triangle extends Product
	{
		public override function getFigure(hor:Number,v:Number,col:uint,w:Number,h:Number):Shape
		{
			figure=new Shape();
			figure.graphics.beginFill(col,.5 );
			figure.graphics.moveTo(hor,v);
			figure.graphics.lineTo(hor+w,v+h);
			figure.graphics.lineTo(hor-w,v+h);
			figure.graphics.lineTo(hor,v);
			figure.graphics.endFill();
			return figure;
		}
	}
}

That’s pretty much it. When I ran into a hitch, I decided to try and debug it by creating my own rectangle using the moveTo and lineTo methods. It was easy to add to this pattern; so, you can assume it’s been re-use and change tested.

The Client

Finally we come to the Client. Initially, I had planned to include a user interface, but I thought I’d let you create your own UI. (Why should I have all the fun?) All it does is to take the products and display them. If you want to make changes, it’s easy to do. All the requests are made through the Creator classes, and the only details that need concern us are getting the parameters straight.

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

package
{
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class Client extends Sprite
	{
		private var pond:Creator;
		private var house:Creator;
		private var roof:Creator;
 
		public function Client()
		{
			pond=new EllipseMaker();
			addChild(pond.factoryMethod(145,160,0x468966,300,120));
			//Add a cloud
			addChild(pond.factoryMethod(200,20,0xcccccc,100,50));
 
			house=new RecMaker();
			addChild(house.factoryMethod(250,100,0xFFB03B,75,50));
			//Add a door
			addChild(house.factoryMethod(270,120,0x8E2800,20,30));
			//Add a window
			addChild(house.factoryMethod(295,120,0x8E2800,20,20));
 
			roof=new TriMaker();
			addChild(roof.factoryMethod(285,75,0xB64926,50,25));
		}
	}
}

I’m sure that Miško Hevery would have a fit with the chores I gave the Client’s constructor class, but I decided that the Client doesn’t count because all it should be doing is making requests. As you can see, that’s all it does.

Seeing Lazy at Work

When you run the program, your trace output will be the following:

new one
reusing existing product
new one
reusing existing product
reusing existing product
new one

It first creates an Ellipse object and when it checks to see whether it exists or not, it finds a null; so it creates a new one. However with the next Ellipse, it finds that it exists, and so reuses it but changes the parameters. Then it creates one new Rectangle and then reuses it twice. Finally, it creates a single Triangle object but does not reuse it. The trace statements are a visual display of the lazy initialization.

Finally, just for the fun of it, see if you can figure out what the vintage Soviet poster says at the beginning of the post.(ленивое is the key!) You really should try your hand at adding more products and the creator classes that call them. While you’re at it, add a UI in the Client and really have some fun.

Take This One to Work

Figure 1: Factory Method with Single Concrete Creator

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

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

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

The Abstract and Concrete Factories

Because the main difference between this application and the Dragon app is the way in which the factory classes (Creator and FaceCreator) handle products, we’ll start with them. First, the Creator class provides the necessary interface as shown 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

package
{
	//Mr Face App
	//Asbstract class--serves as interface
	//Creator
 
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dragNow:Array;
 
		public function createDragable():Array
		{
			dragNow=getDragon();
			return dragNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function getDragon():Array
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

If you’re thinking, That looks a lot like the Creator class for the Dragon application, you’d be absolutely right. In fact, the only difference is that this Creator returns an Array object instead of a Sprite. That’s the purpose of re-use.

The big change is in the way the ConcreteCreator (FaceCreator) works in this design pattern. The abstract function is getDragon(), and so it has to be overridden and set up to instantiate each of the Product children (facial parts) and stuff them into an array. That array is then returned when 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

package
{
	//Concrete Factory
 
	import flash.errors.IllegalOperationError;
 
	public class FaceCreator extends Creator
	{
		private var faceOn:Array=[];
 
		override protected function getDragon():Array
		{
			var ears:Product=new Ears();
			faceOn.push(ears);
 
			var ears2:Product=new Ears();
			faceOn.push(ears2);
 
			var glasses:Product=new Glasses();
			faceOn.push(glasses);
 
			var nose:Product=new Nose();
			faceOn.push(nose);
 
			var eyes:Product=new Eyes();
			faceOn.push(eyes);
 
			var mouth:Product=new Mouth();
			faceOn.push(mouth);
 
			var hair:Product=new Hair();
			faceOn.push(hair);
 
			var head:Product=new Head();
			faceOn.push(head);
 
			return faceOn;
		}
	}
}

By using an array, the Client only has to request a single object rather than all of the Product children individually as was the case in the Dragon application. That’s it as far as the factory classes are concerned. Next, in looking at the Product and its children classes, you will see that not much has changed from the original designs.

The Product and Its Brood

First of all, take a look at the Product class used as an interface for all of the children classes. Again, the Product is an abstract class instead of an Interface, and it re-uses the same methods and properties.

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

package
{
	//Abstract class--serves as interface
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.errors.IllegalOperationError;
 
	public class Product extends Sprite
	{
		protected var base:Sprite=new Sprite();
 
		// ABSTRACT Method
		protected function placeParts(lr:uint,ud:uint):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function setPart(part:Sprite):void
		{
			addChild(base);
			base.addChild(part);
			base.addEventListener(MouseEvent.MOUSE_DOWN,dragPart);
			base.addEventListener(MouseEvent.MOUSE_UP,dropPart);
		}
 
		protected function dragPart(e:MouseEvent):void
		{
			this.startDrag();
		}
 
		protected function dropPart(e:MouseEvent):void
		{
			this.stopDrag();
		}
	}
}

There’s nothing new from the original in that Product class; so let’s move on to the concrete elements of the Product. The setup for this used Sprite classes stored in the Flash Library. (Creating a similar Library in Flash Builder should not be too difficult.) The setPart() method does most of the work, and the placeParts() method is overridden just to have an abstract method. (That was to demonstrate flexibility more than it was an essential function to override.)

Given that the abstract Product class is a workhorse, the child classes need only to call the Sprite class out of the Library. All Sprite classes end with a capital “S” to differentiate them from the Product subclasses themselves. For example, the Mouth class instantiates a MouthS class from the Library. Each of the face parts is a small subclass, and so all of them are placed together 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
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

package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Ears extends Product
	{
		private var ears:Sprite = new EarS();
 
		public function Ears()
		{
			setPart(ears);
			placeParts(100,100);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Eyes extends Product
	{
		private var eyes:Sprite = new EyesS();
 
		public function Eyes()
		{
			setPart(eyes);
			placeParts(100,150);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Glasses extends Product
	{
		private var glasses:Sprite = new GlassesS();
 
		public function Glasses()
		{
			setPart(glasses);
			placeParts(80,170);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Hair extends Product
	{
		private var hair:Sprite = new HairS();
 
		public function Hair()
		{
			setPart(hair);
			placeParts(100,200);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Head extends Product
	{
		private var head:Sprite = new HeadS();
 
		public function Head()
		{
			setPart(head);
			placeParts(120,150);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Mouth extends Product
	{
		private var mouth:Sprite = new MouthS();
 
		public function Mouth()
		{
			setPart(mouth);
			placeParts(100,200);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}

Using Flash Builder (Flex), just place the different graphic elements into separate classes using the same Library class names. Just be sure to subclass them from a Sprite.

The Lazy Client

I’ve come to believe that the less the client has to do, the better. That’s because the Client really should do nothing more than make requests. In some designs the Client is actually part of the design and has more to do. However, as a rule of thumb, the Client should only make requests and place elements on the DisplayList. In this application, that’s all the Client does 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

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var faceParts:Array=[];
		private var myFace:Creator=new FaceCreator();
 
		public function Client()
		{
			faceParts=myFace.createDragable();
			var saveFace:uint=faceParts.length-1;
 
			for (var count:uint =0; count <=saveFace; count++)
			{
				addChild(faceParts.pop());
			}
		}
	}
}

As you can see, the Client just requests the Array from the Creator and then sorts out the array. Now that’s not a lot to do!

Stupid dog tricks: #1 and #2. Just in case you wondered, you can instantiate an array by using aName:Array=[] instead of aName:Array= new Array(). You can do the same thing with an Object using oName:Object={}. Maybe it isn’t as clear as spelling out the object name, but we’re all entitled to a few stupid dog tricks. Those are mine.

Why Take This to Work?

The whole idea behind design patterns is to generate re-usable code that contains good OOP. I realize that a drag-a-face-part game isn’t going to impress your boss (if your boss is infantile, it might) but that’s not important. What is important is to emphasize the fact that as your applications become more complex, you’re either going to have to re-start building applications with every new contract, which will probably include several hacks, make-dos, and god-awfuls. When your customer wants change, it will take time and effort and blow the stuffings out of the current application. So maybe with a simple little face, you can dispel the idea that design patterns will add to a workload. They’re just there to help.

Also, I think that anyone over the age of 5 can do better graphics than I can. So, I’ve provided the entire application including both CS3 and CS4 versions for you to add your own beautiful graphics. (You wonderful graphics folks can send in a fixed-up FLAs with better graphics in the Library, and we’ll gladly add them on the front of this post!). Click the download button to get the whole enchilada:

This is my last post for 2009. See you all next year, and have a great holiday!

Take This One to Work

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

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

Next, I opened up the Design Pattern Catalog (which still needs to be finished) but includes all of the Creational Patterns. It provided the class diagram and other information about the Factory Method that I needed to get started on the project. Also, quite by chance the Design Pattern Catalog was developed using the Factory Method as well—in fact it uses two.

The Dragon Factory

One of the aids I’ve been using to develop design pattern projects is to create a class diagram made up of the files I’ll be using. This helps to give me an ongoing overview, and even though the files are devoid of content initially, they serve as a development map. Also, I like to start with the minimum number of elements needed. So I’ll need at least two different objects, or Product implementations. Since I’ve already got the Video, I’ll use it, and I’ll use the Shape object for the second hitchhiker object. Figure 1 shows the File Class Diagram for this project:

Figure 1: Dragon Factory File Class Diagram

In considering any Factory Method design pattern, GoF notes that you can select from two varieties. One variety is where the Creator is an abstract class and you subclass concrete creators as factory implementations . The other variety is to have a single concrete Creator class that serves as a big factory. (During the Soviet Era in the Russia, they had a huge truck factory the size of a small city that produced huge trucks in great quantities—sort of like the single concrete Creator class.) I opted for the abstract creator to keep the design looser. With a single Creator class I would have had to used conditional statements to farm out out the different types of objects, and as you will see I was able to keep the design if-free.

The Product Classes

The design called for two different objects, but I wanted to leave the door open for further objects that I could include in the design at a later date. Thus, the Product participant in the design pattern needed to be abstract, and so I used an abstract class. It set up one abstract method, a concrete property, and two concrete methods for dragging. The concrete property (named sled) is employed for giving the non-Sprite objects a ride. The abstract method provides flexibility in implementation for different objects. Given the difference between a Video object, including a Camera instance, and a Shape, the design needed that flexibility.

The following three listings show the abstract Product class (DragProduct) and the two implementations (DragVid and DragShape).

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

package
{
	//Abstract class--serves as interface
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.errors.IllegalOperationError;
 
	public class DragProduct extends Sprite
	{
		protected var sled:Sprite=new Sprite();
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function setElements():void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function doDrag(e:MouseEvent):void
		{
			this.startDrag();
		}
 
		protected function unDrag(e:MouseEvent):void
		{
			this.stopDrag();
		}
	}
}

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
{
	//Concrete Product
	import flash.display.Sprite;
	import flash.media.Camera;
	import flash.media.Video;
	import flash.events.MouseEvent;
 
	public class DragVid extends DragProduct
	{
		private const WIDE:uint=320;
		private const HIGH:uint=240;
		private var vid:Video = new Video(WIDE,HIGH);
		private var cam:Camera = Camera.getCamera();
 
		public function DragVid()
		{
			setElements();
			sled.addEventListener(MouseEvent.MOUSE_DOWN,doDrag);
			sled.addEventListener(MouseEvent.MOUSE_UP,unDrag);
		}
 
		override protected function setElements():void
		{
			cam.setMode(WIDE,HIGH,20);
			cam.setQuality(0,100);
			vid.smoothing=true;
			vid.attachCamera(cam);
			vid.x = 100,vid.y = 100;
			addChild(sled);
			sled.addChild(vid);
		}
	}
}

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
{
	//Concrete Product
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.events.MouseEvent;
 
	public class DragShape extends DragProduct
	{
		private var shape:Shape = new Shape();
 
		public function DragShape()
		{
			setElements();
			sled.addEventListener(MouseEvent.MOUSE_DOWN,doDrag);
			sled.addEventListener(MouseEvent.MOUSE_UP,unDrag);
		}
 
		override protected function setElements():void
		{
			shape.graphics.beginFill(0x009900);
			shape.graphics.drawEllipse(450, 10, 50, 50);
			addChild(sled);
			sled.addChild(shape);
		}
	}
}

In the two Product child classes (DragVid and DragShape) you can clearly see where the variation is in the subclass of object that is instantiated just like it shows in the Magic Table.

The Factory Classes

As noted above, I opted for the abstract Creator and relied on specific implementations for the factories that would individually create the different draggable objects. The abstract class that makes up the interface containes a single Sprite property and two methods; one public and concrete and the other, protected and abstract. The public method serves as a getter and the protected method returns the finished product. The following three listings show the Creator 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

package
{
	//Asbstract class--serves as interface
	//Creator
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dragNow:Sprite;
 
		public function createDragable():Sprite
		{
			dragNow = getDragon();
			return dragNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function getDragon():Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

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

package
{
	//Concrete Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class VidCreator extends Creator
	{
		override public function createDragable():Sprite
		{
			return(new DragVid());
		}
	}
}

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

package
{
	//Concrete Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ShapeCreator extends Creator
	{
		override public function createDragable():Sprite
		{
			return(new DragShape());
		}
	}
}

The Creator implementations simply call for either a DragVid or DragShape instance. You may be thinking, you could have used a single Creator implementation (concrete factory) to call for one or the other with a simple conditional statement. However, I try to avoid conditional statements and keep the design loose. Why tighten up your design when you don’t have to? (You’re not going to run out of silicon. )

The Lazy Client

I’ve decided that I don’t want the client doing too much. After all, the Client’s job is to make requests; not to create things from scratch. It’s here to eat the cake; not to bake it. As a result, the client we have for this little project is pretty simple 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

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var dragThing:Creator=new VidCreator();
		private var dragThing2:Creator=new ShapeCreator();
		private var rider:Sprite;
		private var rider2:Sprite;
 
		public function Client()
		{
			rider=dragThing.createDragable();
			addChild(rider);
 
			rider2=dragThing2.createDragable();
			addChild(rider2);
 
		}
	}
}

The Client implements each draggable object with just a few lines of code. It uses a Creator typed object to instantiate concrete factories. Then it uses the factories to call a method that cranks out the desired draggable products. Figure 2 shows what you can expect to see—as long as you have your camera hooked up.

Figure 2: Easily Amused Subject Contemplating Draggable Green Ball

If you’d like to give it a run, hook up your camera and click the “Play Button”:

Try dragging both objects—they drag just fine.

Why Take This to Work?

You might be thinking,

This doesn’t look useful…

It’s funny, the same thing was said about the electric motor and the Internet when they first came about. (It may have been packet switching, but you get the idea…) In their book, Head First Design Patterns, the Freemans have these little cut out pieces of paper you can use to help put different parts of design patterns and programs together. You’re supposed to move them around in different configurations to help you understand design patterns programming. You could do the same thing with a TextField probably. Oh, but I forgot! You can’t drag a TextField object. What was I thinking?

This is the first of three posts on the actual AIR ActionScript 3.0 Design Pattern catalog. Previously, I had discussed the thinking that went into the design of the Catalog, and here is the first actual AIR application with the Creational Patterns portion of the catalog all set up and ready to use. Figure 1 shows what each page looks like: (By the way, the actual image in the catalog is almost twice the size as what you see in Figure 1.)

Figure 1: Design Pattern Catalog Page

Before going on, you can download all of the source code and the AIR application by clicking the Download button. Additionally, you may want to access the Catalog Online.

I changed the color combinations. I concluded that Kuler’s 1944mustang color set was the best for this project because I needed a white background and I liked the orange for highlight. I used red for labeling on the diagrams, but it was used sparsely and provided a consistency.

After several false starts, I finally settled on the Factory Method, and by the time I was finished, I was glad I did. It’s an easy design pattern, keeps the classes loosely connected and is very flexible. In fact I used two Factory Method patterns—one was reused from an earlier application where the factory method was used to send DataProvider data to the Client. (See Refactoring with Multiple Design Patterns.)

The new Factory Method created instances of the pages assembled from several text fields and a graphic. Initially, I was going to have a single Product class and a different ConcreteProduct class for each pattern (23 in all), and that was exactly what I started doing. However, I soon discovered that the only thing that I needed to do was to pass a string parameter with the data name for each pattern, and a single ConcreteProduct class could handle the whole thing. Each of the classes representing a ConcreteProduct class was no smaller than the single general ConcreteProduct; so it did not necessitate bloating a class to cut down on the number of classes.

Finally, all of the data for the page are stored in folders for each individual design pattern. Each folder has a single PNG file and 12 text files. All of the contents of the 23 patterns have identical names and the pattern name is keyed to the folder name. Figure 2 shows an overview of the classes, the data folders and the Client connections to the data.

Figure 2: Files and Data Folders
As you can see in Figure 2, using multiple design patterns of the same type is no different than using single design patterns or different design patterns simultaneously. All you need is to have your Client hooked in where it needs to make the request.

Files, Files, Everywhere!

Figure 2 shows only five of the needed 23 folders have been completed. Fortunately, only five design patterns are part of the Creational category; so I get a break between stints of the mind-numbing chore of adding text to text files. Adding the remaining folders is a matter of copying and pasting the current ones and then changing most of the text content and replacing the PNG file with the class diagram. If you’re in a hurry for the rest of the patterns you can do it yourself—most of the summaries are direct quotes from The Gang of Four or paraphrased to save space. The same is true with the rest of the materials, but I added the kinds of things that are specific to ActionScript 3.0, and of course the code snippets are all ActionScript 3.0. Figure 3 shows the contents of each folder:

Figure 3: Text and Graphic files

Because all of the headers are the same, none of them have to be changed, and some of the text files are simply single words such as the name of the design pattern or the type of pattern. Using the WhatVaries AIR app, it’s easy to get what varies in each pattern as well. However, getting all of the text for components (participants), code examples and uses can be tricky because there’s only limited space for each.

While it may be tedious to enter all of the data for each and every design pattern, you’ll learn a lot—especially if you are using the Gang of Four’s book or ActionScript 3.0 Design Patterns. Also, there’s a lot of information on this blog you can use to fill out the data.

To add further design patterns here’s all you have to do:

• Copy and paste one of the current design pattern folders and all of its contents and then rename it using lower case no-space name. For example, the Chain of Responsibility can be named cor
• Add the label name and the data name of the design pattern in the CatData class. Use the same lowercase name for the data name as you used to name the folder for the pattern.
• Draw a class diagram with a width no greater than 500px and save it as a PNG file using the name, diagram.png in the folder where you have the other files for the pattern.
• Open the text files and change the content to reflect the characteristics of the design pattern. The files with “head” in the filename (e.g., codehead.txt) should be left unchanged but still have to be in the folder

That’s it. It also reflects what I like about design patterns. Once you get the basic structure set up; changes and reuse are easy.

The Page-Making Factory

Since we’re reusing a design pattern, you can review it at Refactoring with Multiple Design Patterns . However, to understand how the new use of the Factory Method works, each of the classes are reviewed here.

First of all, the Client is remarkably clean, and all requests, other than the initial one to provide data for the List component, relies on user-input in the List menu. Only a single conditional statement is used anywhere in this application, and it can be found in the Client where checking content in the DisplayObject. So you’ll find a very simple Client making requests for data and to see the content of a design pattern. The following listing shows what little code is required in the 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
39
40
41
42
43
44
45
46
47
48
49
50

package
{
	import flash.display.Sprite;
	import fl.controls.List;
	import fl.data.DataProvider;
	import fl.events.ListEvent;
 
	//Client Class
 
	public class Client extends Sprite
	{
		private var factory:Creator = new ConcreteCreator  ;
		private var catalog:DataProvider;
		private var list:List = new List  ;
		private var dp:String;
		private var dpDisplay:Sprite;
 
		public function Client()
		{
			setMenu();
		}
 
		private function setMenu():void
		{
			//Re-use Factory that provides data for DataProvider
			var create:DPCreator = new ConcreteDPCreator  ;
			var catalog:DataProvider = new DataProvider  ;
			catalog = create.selectData();
			//Set up the list
			list.setSize(126,650);
			list.x = 0,list.y = 0;
			list.dataProvider = catalog;
			addChild(list);
			list.addEventListener(ListEvent.ITEM_CLICK,choosePattern);
		}
 
		private function choosePattern(e:ListEvent):void
		{
			dp = String(e.item.data);
			//Only conditional in the entire program
			if (dpDisplay)
			{
				removeChild(dpDisplay);
			}
 
			dpDisplay = factory.makeDP(dp);
			addChild(dpDisplay);
		}
	}
}

As you can see, once the List menu is set up, the choosePattern() method does all the work. Further it is accomplished using very little code.

The next class is the Creator. It supplies the interface for the factory. As an abstract class, it cannot be instantiated, but you can include implemented methods. In this case, one method is implemented and the other is abstract.

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
{
	//Asbstract class
	//Creator
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dpNow:Sprite;
 
		public function makeDP(dp:String):Sprite
		{
			dpNow = chooseDP(dp);
			return dpNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function chooseDP(dp:String):Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

The factory itself is a subclass of the abstract Creator class. It must implement the abstract method, and really nothing else. Originally when I had planned on individual ConcreteProduct classes for each design pattern, I had a big switch statement with 23 cases. However, by adding a parameter to the Catalog constructor (the ConcreteProduct class), all that’s passed is a string based on the List selected item’s data value.

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

package
{
	//Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreator extends Creator
	{
		override protected function chooseDP(dp:String):Sprite
		{
			return(new Catalog(dp));
		}
	}
}

The Product and Concrete Product Classes

The big classes in this application are the two that handle the product elements. That should not come as a surprise because the product is pretty big—12 text fields with text and a graphic file. The abstract Product class has both abstract and implemented methods and lots of them. With 284 lines of code (including spaces and comments), this was the biggest abstract class I’d ever created. Half the methods are abstract and the other half are implemented. Essentially, it works like a giant getter/setter—or loader/placer to be more precise. Once each load is complete, a mirror function (method) “catches” the loaded materials and places it where it belongs on the DisplayObject (aka stage).

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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284

package
{
	import flash.errors.IllegalOperationError;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFieldType;
	import flash.events.Event;
	import flash.text.TextFormat;
 
	//Abstract class
	public class Product extends Sprite
	{
		private var loadCheck:URLLoader;
 
		private var txtFld:TextField = new TextField();
		private var typeFld:TextField = new TextField();
		private var sumHeadFld:TextField = new TextField();
		private var sumFld:TextField = new TextField();
		private var varyHeadFld:TextField = new TextField();
		private var varyFld:TextField = new TextField();
		private var usesHeadFld:TextField = new TextField();
		private var usesFld:TextField = new TextField();
		private var codeHeadFld:TextField = new TextField();
		private var codeFld:TextField = new TextField();
		private var comHeadFld:TextField = new TextField();
		private var comFld:TextField = new TextField();
 
		private var textFormat:TextFormat = new TextFormat();
		private const TEXTCOLOR:uint = 0x263248;
		private const TYPECOLOR:uint = 0xFF9800;
		private const HEADCOLOR:uint = 0x263248;
		private const BODYCOLOR:uint = 0x000000;
 
		protected function loadInfo(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadType(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadSumHead(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadSum(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadVaryHead(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadVary(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadUsesHead(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadUses(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadCodeHead(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadCode(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadComHead(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function loadCom(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		//Already Loaded
		protected function nowLoaded(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 18;
			txtFld.type = TextFieldType.DYNAMIC;
			txtFld.width = 300;
			txtFld.wordWrap = true;
			txtFld.textColor = TEXTCOLOR;
			txtFld.defaultTextFormat = textFormat;
			txtFld.text = loadCheck.data;
			addChild(txtFld);
			txtFld.x = 128,txtFld.y = 10;
		}
 
		protected function nowType(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 14;
			typeFld.type = TextFieldType.DYNAMIC;
			typeFld.width = 300;
			typeFld.wordWrap = true;
			typeFld.textColor = TYPECOLOR;
			typeFld.defaultTextFormat = textFormat;
			typeFld.text = loadCheck.data;
			addChild(typeFld);
			typeFld.x = 368,typeFld.y = 16;
		}
 
		protected function nowSumHead(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 14;
			sumHeadFld.type = TextFieldType.DYNAMIC;
			sumHeadFld.width = 175;
			sumHeadFld.wordWrap = true;
			sumHeadFld.textColor = HEADCOLOR;
			sumHeadFld.defaultTextFormat = textFormat;
			sumHeadFld.text = loadCheck.data;
			addChild(sumHeadFld);
			sumHeadFld.x = 148,sumHeadFld.y = 409;
		}
 
		protected function nowSum(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial";
			textFormat.size = 12;
			sumFld.type = TextFieldType.DYNAMIC;
			sumFld.width = 200;
			sumFld.wordWrap = true;
			sumFld.textColor = BODYCOLOR;
			sumFld.defaultTextFormat = textFormat;
			sumFld.text = loadCheck.data;
			addChild(sumFld);
			sumFld.x = 148,sumFld.y = 431;
		}
 
		protected function nowVaryHead(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 14;
			varyHeadFld.type = TextFieldType.DYNAMIC;
			varyHeadFld.width = 175;
			varyHeadFld.wordWrap = true;
			varyHeadFld.textColor = HEADCOLOR;
			varyHeadFld.defaultTextFormat = textFormat;
			varyHeadFld.text = loadCheck.data;
			addChild(varyHeadFld);
			varyHeadFld.x = 684,varyHeadFld.y = 409;
		}
 
		protected function nowVary(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial";
			textFormat.size = 12;
			varyFld.type = TextFieldType.DYNAMIC;
			varyFld.width = 175;
			varyFld.wordWrap = true;
			varyFld.textColor = BODYCOLOR;
			varyFld.defaultTextFormat = textFormat;
			varyFld.text = loadCheck.data;
			addChild(varyFld);
			varyFld.x = 684,varyFld.y = 431;
		}
 
		protected function nowUsesHead(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 14;
			usesHeadFld.type = TextFieldType.DYNAMIC;
			usesHeadFld.width = 175;
			usesHeadFld.wordWrap = true;
			usesHeadFld.textColor = HEADCOLOR;
			usesHeadFld.defaultTextFormat = textFormat;
			usesHeadFld.text = loadCheck.data;
			addChild(usesHeadFld);
			usesHeadFld.x = 148,usesHeadFld.y = 504;
		}
 
		protected function nowUses(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial";
			textFormat.size = 12;
			usesFld.type = TextFieldType.DYNAMIC;
			usesFld.width = 175;
			usesFld.wordWrap = true;
			usesFld.textColor = BODYCOLOR;
			usesFld.defaultTextFormat = textFormat;
			usesFld.text = loadCheck.data;
			addChild(usesFld);
			usesFld.x = 148,usesFld.y = 528;
		}
 
		protected function nowCodeHead(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 14;
			codeHeadFld.type = TextFieldType.DYNAMIC;
			codeHeadFld.width = 175;
			codeHeadFld.wordWrap = true;
			codeHeadFld.textColor = HEADCOLOR;
			codeHeadFld.defaultTextFormat = textFormat;
			codeHeadFld.text = loadCheck.data;
			addChild(codeHeadFld);
			codeHeadFld.x = 350,codeHeadFld.y = 409;
		}
 
		protected function nowCode(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Courier New";
			textFormat.size = 12;
			codeFld.type = TextFieldType.DYNAMIC;
			codeFld.width = 323;
			codeFld.height = 215;
			codeFld.wordWrap = true;
			codeFld.textColor = BODYCOLOR;
			codeFld.defaultTextFormat = textFormat;
			codeFld.text = loadCheck.data;
			addChild(codeFld);
			codeFld.x = 350,codeFld.y = 430;
		}
 
		protected function nowComHead(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 14;
			comHeadFld.type = TextFieldType.DYNAMIC;
			comHeadFld.width = 175;
			comHeadFld.wordWrap = true;
			comHeadFld.textColor = HEADCOLOR;
			comHeadFld.defaultTextFormat = textFormat;
			comHeadFld.text = loadCheck.data;
			addChild(comHeadFld);
			comHeadFld.x = 684,comHeadFld.y = 458;
		}
 
		protected function nowCom(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial";
			textFormat.size = 12;
			comFld.type = TextFieldType.DYNAMIC;
			comFld.width = 242;
			comFld.height = 164;
			comFld.wordWrap = true;
			comFld.textColor = BODYCOLOR;
			comFld.defaultTextFormat = textFormat;
			comFld.text = loadCheck.data;
			addChild(comFld);
			comFld.x = 684,comFld.y = 480;
		}
		//Load Image
		protected function loadImg(img:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
 
		}
	}
}

Each implemented method works the same. It gets the Event instance from the loading sequence (implemented in the Catalog class—a Concrete Product) and then puts it where it belongs and formats it.

Finally, the ConcreteProduct is the Catalog class. It loads all of the materials it needs and then uses the methods it inherited from the Product class to place the text and 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
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

package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.events.Event;
 
	public class Catalog extends Product
	{
		private var dp:String;
		private var nameText:String;
		private var typeText:String;
		private var sumHead:String;
		private var sumText:String;
		private var varyHead:String;
		private var varyText:String;
		private var usesHead:String;
		private var usesText:String;
		private var codeHead:String;
		private var codeText:String;
		private var comHead:String;
		private var comText:String;
		private var dpImage:String;
		private var url:URLRequest;
		private var loader:Loader;
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var typeLoader:URLLoader;
		private var sumHeadLoader:URLLoader;
		private var sumLoader:URLLoader;
		private var varyHeadLoader:URLLoader;
		private var varyLoader:URLLoader;
		private var usesHeadLoader:URLLoader;
		private var usesLoader:URLLoader;
		private var codeHeadLoader:URLLoader;
		private var codeLoader:URLLoader;
		private var comHeadLoader:URLLoader;
		private var comLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function Catalog(dp:String)
		{
			this.dp=dp;
			dp+="/";
			nameText = dp + "name.txt";
			typeText = dp + "type.txt";
			sumHead = dp + "sumhead.txt";
			sumText = dp + "summary.txt";
			varyHead = dp + "varyhead.txt";
			varyText = dp + "vary.txt";
			usesHead = dp + "useshead.txt";
			usesText = dp + "uses.txt";
			codeHead = dp + "codehead.txt";
			codeText = dp + "code.txt";
			comHead = dp + "comhead.txt";
			comText = dp + "com.txt";
			dpImage = dp + "diagram.png";
 
			//All of these function are below
			loadInfo(nameText);
			loadType(typeText);
			loadSumHead(sumHead);
			loadSum(sumText);
			loadVaryHead(varyHead);
			loadVary(varyText);
			loadUsesHead(usesHead);
			loadUses(usesText);
			loadCodeHead(codeHead);
			loadCode(codeText);
			loadComHead(comHead);
			loadCom(comText);
			loadImg(dpImage);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadType(txtInfo:String):void
		{
			typeLoader = new URLLoader();
			typeLoader.addEventListener(Event.COMPLETE,nowType);
			fileNow = new URLRequest(txtInfo);
			typeLoader.load(fileNow);
		}
 
		override protected function loadSumHead(txtInfo:String):void
		{
			sumHeadLoader = new URLLoader();
			sumHeadLoader.addEventListener(Event.COMPLETE,nowSumHead);
			fileNow = new URLRequest(txtInfo);
			sumHeadLoader.load(fileNow);
		}
 
		override protected function loadSum(txtInfo:String):void
		{
			sumLoader = new URLLoader();
			sumLoader.addEventListener(Event.COMPLETE,nowSum);
			fileNow = new URLRequest(txtInfo);
			sumLoader.load(fileNow);
		}
 
		override protected function loadVaryHead(txtInfo:String):void
		{
			varyHeadLoader = new URLLoader();
			varyHeadLoader.addEventListener(Event.COMPLETE,nowVaryHead);
			fileNow = new URLRequest(txtInfo);
			varyHeadLoader.load(fileNow);
		}
 
		override protected function loadVary(txtInfo:String):void
		{
			varyLoader = new URLLoader();
			varyLoader.addEventListener(Event.COMPLETE,nowVary);
			fileNow = new URLRequest(txtInfo);
			varyLoader.load(fileNow);
		}
 
		override protected function loadUsesHead(txtInfo:String):void
		{
			usesHeadLoader = new URLLoader();
			usesHeadLoader.addEventListener(Event.COMPLETE,nowUsesHead);
			fileNow = new URLRequest(txtInfo);
			usesHeadLoader.load(fileNow);
		}
 
		override protected function loadUses(txtInfo:String):void
		{
			usesLoader = new URLLoader();
			usesLoader.addEventListener(Event.COMPLETE,nowUses);
			fileNow = new URLRequest(txtInfo);
			usesLoader.load(fileNow);
		}
 
		override protected function loadCodeHead(txtInfo:String):void
		{
			codeHeadLoader = new URLLoader();
			codeHeadLoader.addEventListener(Event.COMPLETE,nowCodeHead);
			fileNow = new URLRequest(txtInfo);
			codeHeadLoader.load(fileNow);
		}
 
		override protected function loadCode(txtInfo:String):void
		{
			codeLoader = new URLLoader();
			codeLoader.addEventListener(Event.COMPLETE,nowCode);
			fileNow = new URLRequest(txtInfo);
			codeLoader.load(fileNow);
		}
 
		override protected function loadComHead(txtInfo:String):void
		{
			comHeadLoader = new URLLoader();
			comHeadLoader.addEventListener(Event.COMPLETE,nowComHead);
			fileNow = new URLRequest(txtInfo);
			comHeadLoader.load(fileNow);
		}
 
		override protected function loadCom(txtInfo:String):void
		{
			comLoader = new URLLoader();
			comLoader.addEventListener(Event.COMPLETE,nowCom);
			fileNow = new URLRequest(txtInfo);
			comLoader.load(fileNow);
		}
 
		//Load image
		override protected function loadImg(dpImage:String):void
		{
			url = new URLRequest(dpImage);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 128,loader.y = 34;
		}
	}
}

That’s the whole enchilada, and it is a big one. Both of the product classes are much bigger than I like, but the nature of the application requires it. However, even with all of the methods and instances in two different Factory Method class sets, there’s only a single conditional statement, and it’s in the Client—where it doesn’t count as part of the design pattern. (I could even eliminate it if I put in a dummy display sprite—but why go fanatic?)

Finishing Up

All that’s left are 17 more design patterns and some kind of splash page. I think that the splash page should have the different elements of the UML class diagrams—what the different arrows and symbols mean. If you can think of anything else, let us know. Also, play around with the AIR version and let me know if you have any additional features that you think would help. Also, if you want to pitch in and help fill in the different design patterns data, contact me and I’ll be glad to recruit you! (Is there such a thing as an online Hero Medal?)

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.

After I made my video player that I planned to use to illustrate refactoring a non-design pattern program into a design pattern one, I noticed how crowded the Client class had become. Most of the crowding was caused by creating and populating UIs and event handling functions. One class that I use a lot to populate UI components is the DataProvider. As I went through and edited and organized my videos from a vacation to Prague, CZ, the DataProvider kept growing. Using MP4 files converted into F4V files, I used very similar formats for the data portion of all of the DataProvider instance. Why not put the DataProvider data into a separate class? Then, I could just call an instance of the class with the data and not have to clutter the Client class with messy DataProvider information.

Lazy Programming can be a Lot of Work

After moving the DataProvider data to another class, I realized that I had two other projects using the video player that accessed the same kind of data. So, while I was at it, I might as well add classes for these other projects. In fact, why not add a common interface as well? Then I could program all data requests to the interface instead of the implementation. Further, I could add some separation between the DataProvider items and the Client requests by adding a factory, and if I were going to do that, I might as well go ahead and create a Factory Method design pattern. Then, whenever I wanted to add a class with data for different projects I could do so without having to worry about messing up the rest of the program. Each project was handled using a Concrete Product class.

The Big Picture

To begin with a clear idea of what is going on in this refactoring exercise, you’ll need to get the big picture. Figure 1 provides an overview of how the video player is to be refactored using two design patterns:

The video player is essentially a state machine, and in Part II of this post, we’ll look at how we’ll refactor the hack-job player into a state player.

Getting and Using the Data

Using a List component with ActionScript 3.0 code requires that a DataProvider object be assigned as a data source. The DataProvider object can be loaded with data in several ways—using the addItem() method, an array or XML files. For this project, I’ll be using the addItem() method, but you can substitute the other data loading techniques if you wish.

The DataProvider object requires two elements for this project. The first element is a label for the List component and the second is the URL to the video. The label element requires nothing more than a label indicating what video plays. Using Flash Media Interactive Server 3.5.2 (FMIS) and H. 264 format requires the following kind of reference:

    mp4: folderName/fileName.f4v

If you’re not familiar with Flash Media Server, no problem. This system works with a simple progressive download as well. So if you’d rather work with video files from a Web server, you can change the reference to:

      folderName/fileName.flv

(You cannot use F4V (H.264) files with progressive download).

So, the basic data-loading procedure is:

dataProvider.addItem( { label: "LabelName", data:" mp4: folderName/fileName.f4v " } );

In this first post, all I want to do is to look to see how the DataProvider is moved out of the Client and into a Factory Method design pattern.

Getting Data From the DataProvider Object

Initially, the Client contained the code for all operations involving the DataProvider. The List instance (list) was then assigned the DataProvider instance. The following shows code snippet the relevant features in the Client

1
2
3
4
5
6

var prague:DataProvider=new DataProvider();
prague.addItem( { label: "Panorama", data:"mp4:praguevid/panorama.f4v" } );
prague.addItem( { label: "Charles Bridge", data:"mp4:praguevid/charlesbridge.f4v" } );
prague.addItem( { label: "Old & New Town", data:"mp4:praguevid/newtown.f4v" } );
prague.addItem( { label: "Mucha Glass", data:"mp4:praguevid/mucha.f4v" } );
list.dataProvider = prague;

Once the data has been added to the List object, it is retrieved when an item in the list is clicked. The line,

   list.addEventListener(ListEvent.ITEM_CLICK,startPlay);

triggers a function used to get the URL for the video and play the selected video. The following operation shows how the selection and play events are handled:

1
2
3
4
5
6
7
8
9
10

private function startPlay(e:ListEvent):void
{
	if (ns)
	{
		//f4vid is a private string variable
		f4vid = e.item.data;
		vid.attachNetStream(ns);
		ns.play(f4vid);
	}
}

The key connection in the function is assigning the value of e.item.data to the string variable (f4vid). The data are used as the URL to play the selected video. That operation is fine the way it is and belongs in the Client as a request. What needs to be removed from the Client is the operation that populates the DataProvider.

Building a Factory Method for Populating and Returning a DataProvider: A Friend with Benefits

You might be asking yourself,

Is this really necessary? Why not just leave the DataProvider in the Client and populate it there?

The short answer is, of course not! It is not necessary, but you will find many benefits in doing so:

• Removes clutter from the Client
• Client can make request from external source
• Contents of DataProvider can be changed without breaking the rest of the program
• Other programs can use the same design pattern
• Adds flexibility for change and development

To get started, Figure 2 shows a chart diagram for this project dealing with a single concrete product—data for a series of videos.

Figure 2: Factory Method for a single set of data

In this case, the List object is in the Client class, but because it is the only object in the class that uses the data generated in the Factory Method design pattern, it is listed.

First, the Creator class provides the interface for all concrete creators. Most importantly is the factory method to be used in creating and delivering the DataProvider to the Client for use in the List component.

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
{
	//Abstract class
	//Creator
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dataNow:DataProvider;
 
		public function selectData():DataProvider
		{
			dataNow = createData();
			return dataNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function createData():DataProvider
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

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

package
{
	//Concrete Creator (Factory)
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreatorPrague extends Creator
	{
		private var ds:DataSupply;
 
		override protected function createData():DataProvider
		{
			ds=new Prague();
			return (ds.deliverData());
 
		}
	}
}

1
2
3
4
5
6
7
8
9
10

package
{
	import fl.data.DataProvider;
 
	//Product
	interface DataSupply
	{
		function deliverData():DataProvider;
	}
}

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

package
{
	import fl.data.DataProvider;
 
	public class Prague implements DataSupply
	{
		public function deliverData():DataProvider
		{
			var prague:DataProvider=new DataProvider();
			prague.addItem( { label: "Panorama", data:"mp4:praguevid/panorama.f4v" } );
			prague.addItem( { label: "Charles Bridge", data:"mp4:praguevid/charlesbridge.f4v" } );
			prague.addItem( { label: "Old & New Town", data:"mp4:praguevid/newtown.f4v" } );
			prague.addItem( { label: "Mucha Glass", data:"mp4:praguevid/mucha.f4v" } );
			return prague;
		}
	}
}

Finally, all that the Client needs is to request the data it needs. Because, only a single concrete product has been created, this is simply a matter of creating List and DataProvider instances. Then to populate the DataProvider with data, the Client requests the data by instantiating the desired concrete creator through the Creator interface (abstract class). The following listing shows the operations in the process:

1
2
3
4
5
6
7

var create:Creator=new ConcreteCreatorPrague();
var prague: DataProvider=new DataProvider();
 
prague=create.selectData();
 
var list:List=new List();
list.dataProvider = prague;

Under any circumstances you need to create a DataProvider instance, a List instance and assign a DataProvider object to the List object. Using the Factory Method pattern, the only line of code required to request the contents for the DataProvider is the following:

   prague=create.selectData();

You can have hundreds of elements in the DataProvider, but using the suggested pattern, you still just need a single line in the Client to access it.

Expanding The Concrete Products Shows the Benefits

After going through the process we have, you may be thinking, What benefits?. After all, the DataProvider class itself is a pretty handy class in its own right. Why complicate things?

For a single data source, it is a bit hefty, but when you look at a larger picture, you can see that this Factory Method program can be used as a reliable mechanism to add more data sources. Figure 3 shows an expanded version of the original pattern:

Figure 3: Factory Method for expanded set of data

Before you get started on this new set of classes, you might want to download the files here. The Product interface (DataSupply) is the same as the original. However, because the concrete creator has more than a single option from the concrete products now, we’ll have to add a parameter to the factory method for choosing the concrete product we want. However, as you can see in the following program, there’s not much that is changed from the original Creator 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

package
{
	//Abstract class
	//Creator
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dataNow:DataProvider;
 
		public function selectData(dataSource:String):DataProvider
		{
			dataNow = createData(dataSource);
			return dataNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function createData(dataSource:String):DataProvider
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

The concrete creator needs to be changed as well, both to add the new parameter and to set up a way to choose among the concrete products. It has been renamed, ConcreteCreatorVid to reflect that it is used in dealing with data that is used with the video player:

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

package
{
	//Factory
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreatorVid extends Creator
	{
		private var ds:DataSupply;
		override protected function createData(dataSource:String):DataProvider
		{
			switch (dataSource)
			{
				case "prague" :
					ds=new Prague();
					return(ds.deliverData());
					break;
				case "graduation" :
					ds=new Graduation();
					return(ds.deliverData());
					break;
				case "bloomfield" :
					ds=new Bloomfield ();
					return(ds.deliverData());
					break;
				default :
					throw new Error("Invalid video set specified");
					return null;
			}
		}
	}
}

Notice that the ConcreteCreatorVid holds a reference to the product interface (DataSupply) and then instantiates the concrete products (Prague, Graduation, Bloomfield) using an object typed as an interface. The Prague concrete product class does not change; so all that’s left is to create concrete product classes for the Graduation and Bloomfield video projects.

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

//Data for Graduation Project
package
{
	import fl.data.DataProvider;
 
	public class Graduation implements DataSupply
	{
		public function deliverData():DataProvider
		{
			var graduation:DataProvider=new DataProvider();
			graduation.addItem( { label: "Gathering", data:"mp4:graduationvid/gathering.f4v" } );
			graduation.addItem( { label: "Walking", data:"mp4:graduationvid/walk.f4v" } );
			graduation.addItem( { label: "Awarding Degrees", data:"mp4:graduationvid/degree.f4v" } );
			return graduation;
		}
	}
}
 
//Data for Bloomfield project
package
{
	import fl.data.DataProvider;
 
	public class Bloomfield implements DataSupply
	{
		public function deliverData():DataProvider
		{
			var bloomfield:DataProvider=new DataProvider();
			bloomfield.addItem( { label: "Introduction", data:"mp4:bloomfieldvid/intro.f4v" } );
			bloomfield.addItem( { label: "My Street", data:"mp4:bloomfieldvid/shadywalk.f4v" } );
			bloomfield.addItem( { label: "History", data:"mp4:bloomfieldvid/park.f4v" } );
			bloomfield.addItem( { label: "People", data:"mp4:bloomfieldvid/people.f4v" } );
			return bloomfield;
		}
	}
}

At this point you have all of the Factory Method classes. So now (finally!) we can look at a Client class that makes requests. Keep in mind that this is only one of two design patterns that this project is using. (In the next installment, we’ll refactor the a non-OOP video player into a State design pattern and incorporate this data-generating Factory Method design pattern.)

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

package
{
	import flash.display.Sprite;
	import fl.events.ListEvent;
	import flash.events.MouseEvent;
	import fl.controls.Button;
	import fl.controls.List;
	import fl.data.DataProvider;
 
	public class Client extends Sprite
	{
		private var btnPrague:Button=new Button();
		private var btnGrad:Button=new Button();
		private var btnBloom:Button=new Button();
		private var list:List=new List();
		private var create:Creator=new ConcreteCreatorVid();
 
		public function Client()
		{
			setUI();
			btnPrague.addEventListener(MouseEvent.CLICK,getPrague);
			btnGrad.addEventListener(MouseEvent.CLICK,getGraduation);
			btnBloom.addEventListener(MouseEvent.CLICK,getBloomfield);
		}
 
		private function setUI():void
		{
			btnPrague.x = 35,btnPrague.y = 160;
			btnPrague.label = "Prague";
			btnPrague.textField.background = true;
			btnPrague.textField.backgroundColor = 0xA19580;
			addChild(btnPrague);
			btnGrad.x = 35,btnGrad.y = 190;
			btnGrad.label = "Graduation";
			btnGrad.textField.background = true;
			btnGrad.textField.backgroundColor = 0xA19580;
			addChild(btnGrad);
			btnBloom.x = 35,btnBloom.y = 220;
			btnBloom.label = "Bloomfield";
			btnBloom.textField.background = true;
			btnBloom.textField.backgroundColor = 0xA19580;
			addChild(btnBloom);
			list.x = 35,list.y = 50;
			addChild(list);
		}
 
		private function getPrague(e:MouseEvent):void
		{
			var prague:DataProvider=new DataProvider();
			prague = create.selectData("prague");
			list.dataProvider = prague;
		}
 
		private function getGraduation(e:MouseEvent):void
		{
			var graduation:DataProvider=new DataProvider();
			graduation = create.selectData("graduation");
			list.dataProvider = graduation;
		}
 
		private function getBloomfield(e:MouseEvent):void
		{
			var bloomfield:DataProvider=new DataProvider();
			bloomfield = create.selectData("bloomfield");
			list.dataProvider = bloomfield;
		}
	}
}

As you can see, each button calls a function to load the List instance with a different set of data loaded into the DataProvider object. It’s just like the first version of the pattern except that a parameter has been added to select from among three data sets. Figure 4 shows the different outcomes in the List component:

Figure 4: Selected List object data

Both in our book and on this blog, you’ve seen other examples of the Factory Method design pattern; so this may not be new as far as a design pattern is concerned. However, it does show a different use of the pattern and how flexible it is. In the next installment, we’ll see how this pattern that provides UI data can be integrated with a State design to develop a video player that is set up so that adding more controls is quite simple.