JavaScript can do Design Patterns

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

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

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

Figure 1: JavaScript Chain of Responsibility Help Desk

Inheritance is a ‘IS-A’

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

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

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

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

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

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

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

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

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

The HTML5 Client

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

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

The click handler calls the top of the chain, and the Chain of Responsibility just chugs on through until it finds what you want. Here’s the whole HTML5 code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

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

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

After Mom, Ask Dad, and then the Dog

To get started on the quest to see whether useful design patterns can be created with JavaScript, I thought it’d be a good idea to go from the known to the unknown. In this case, those familiar with this blog know ActionScript 3.0 design patterns, and the unknown (for some at least) is JavaScript. Well, I suppose just about everyone who reads this blog knows something about JavaScript, but several may not have been involved with either JavaScript OOP or design patterns. By creating an ActionScript 3.0 app using a pattern and then going through the app step-by-step, readers may be better able to understand how we might approach design patterns using JavaScript. I decided to use the Chain of Responsibility (CoR) pattern to go through the types of mobile operating systems that we examined in the previous post. In this way, we can create something both familiar and practical.

Every time I use the Chain of Responsibility pattern, I feel that I’m swatting a fly with a weapon of mass destruction. I see all of these classes, and I’m thinking that I could have done the same thing with a switch statement or something even slicker. Then I need to remind myself why I’d use the CoR in the first place.

The Chain of Responsibility separates the handling of an event from the request to handle it.

In a broader context, this allows the developer to make changes to either the request or the handling of the event without disrupting some other part of the program. It’s quite simple as well. Just imagine several people lined up with different kinds of expertise and/or authority. A request is issued, and once it reaches the person with the right expertise or authority, it is handled. The request is separated from the way it will be handled. That’s up to the expert. Figure 1 shows the class design:

Figure 1: Chain of Responsibility Pattern

Getting Started with CoR

For details about ways to setup and use CoR see our original discussion . The focal points are in the following:

• An interface (an abstract class or interface) establishes a handler operation
• Each request handler has a separate class derived from the handler interface
• Each handler class has a successor which is another handler class
• The last handler in the chain has no successor
• As soon as a handler can handle the request, the chain stops and the handler takes care of the request.

You may be thinking that this is not very efficient since it requires a sequential path. We’ve considered ways to get around a sequence (see our posts on Skip Lists), but for now we’ll stick with the traditional CoR and use a sequential search through the list of handlers.

The Chain of Mobile Operating Systems

This CoR simulates finding one of several types of mobile OS. Given the type of OS, it looks for ways to handle each one optimally. In the JavaScript version of this, we want to have it select a CSS file or another JS file to best use the kind of mobile device involved. The concrete handler classes are the objects used to deal with whatever requirements are necessary. In the example, each handler simply traces out “Set up for xxOS,” where “xx” is the found mobile OS. It also traces out which handlers were rejected so that you can better see how the chain works. Since Android is at the top of the chain, you see no rejections, while Windows CE at the bottom of the chain displays the whole chain.

It might be helpful if you take a look at the whole concept of Linked Lists. The Chain of Responsibility is something like a linked list, but instead of linking lists, it links handlers.

The Client class makes the initial request and sets up a simple requesting UI for testing the application. It makes requests using a string. I just used the lowercase ID of the main mobile OS types as the “request-to-handle.” After making the request, the “chain” takes over. In this example the top of the chain is the Android, but it could be any of the others as well. The developer has complete control over the sequence.

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

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import fl.controls.Button;
	import fl.controls.TextInput;
	import fl.controls.Label;
	import flash.text.TextFieldAutoSize;
 
	public class Client extends Sprite
	{
		//Handlers + Request
		private var android:Handler= new Android();
		private var iphone:Handler= new IPhone();
		private var blackberry:Handler= new Blackberry();
		private var series60:Handler=new Series60();
		private var windowsce:Handler=new WindowsCE();
		private var cannothandle:Handler=new CannotHandle();
 
		//UI
		private var btn:Button=new Button();
		private var iput:TextInput=new TextInput();
		private var lbl:Label=new Label();
 
		public function Client()
		{
			setupChain();
			setupUI();
		}
 
		private function setupChain():void
		{
			//Sequence set up here
			android.SetSuccessor(iphone);
			iphone.SetSuccessor(blackberry);
			blackberry.SetSuccessor(series60);
			series60.SetSuccessor(windowsce);
			windowsce.SetSuccessor(cannothandle);
		}
 
		private function setupUI():void
		{
			//This simulates getting the mobile OS from the using system
			lbl.autoSize = TextFieldAutoSize.LEFT;
			lbl.text="Enter name of mobile device: (Use lower case.)";
			lbl.x=50,lbl.y=30;
			addChild(lbl);
			btn.x=50, btn.y=75;
			btn.label="Start the chain";
			btn.addEventListener(MouseEvent.CLICK,requestOS);
			addChild(btn);
			iput.x=50,iput.y=50;
			addChild(iput);
		}
 
		private function requestOS(e:MouseEvent)
		{
			android.HandleRequest(iput.text);
		}
	}
}

For the end of the chain, I added a “CannotHandle” class that extends the Handler interface. This functions something like a default option in a switch statement. If none of the handlers can handle the request, you need to provide the user with some kind of feedback.

The Abstract and Concrete Handlers

In this application the interface is an abstract class, named Handler. The abstract method, HandleRequest() takes a string argument and checks if it’s the appropriate class to handle the request, and if not, passes it on to the successor. The last concrete Handler object is always the CannotHandle class.

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

package
{
	//Abstract class
 
	public class Handler
	{
		protected var successor:Handler;
		protected var mobileType:String;
 
		public function SetSuccessor (successor:Handler):void
		{
			this.successor=successor;
		}
 
		public function HandleRequest (req:String):void
		{
			//Provide details in subclasses
		}
	}
}

With ActionScript 3.0, you have to make up abstract classes by including at least one method that you want to be abstract and must be overridden when implemented. In this case the HandleRequest(reg:String) method expects to be overridden. On the other hand, the SetSuccessor method that expects a concrete handler as an argument is inherited all set to use. Just add an argument. In deciding where to implement the SetSuccessor method, I decided to use the Client. In this way the developer can clearly see the order of the chain. Further, if changes are made, the CannotHandle class can easily be moved to the end of the chain without having to change the sequencing within the concrete handler classes.

The two handler properties, successor and mobileType are used to identify the successor class (object) and store the name of the operating system, respectively. All that’s left is to provide the concrete implementations which involves two steps:

1. Overidding the HandleRequest() method and adding whatever you want the class to do if it’s to handle the request.
2. Sending the search off to the successor if it cannot handle the request.

That’s not exactly rocket science. This is a very easy design pattern to implement. I added a private method to each class, sendBack() that represents a more complex handling of any request outside of the conditional statement that identifies the handler as the appropriate one for the request. The more differentiated and complex the handlers, the more that you can appreciate the CoR. You can add anything you need to handle a request without having to worry about the requester (Client) or the other ways available to handle a request. Further, when you add or change a handler to the chain, it will not disrupt the rest of the program.

The following six classes represent concrete handlers. All of them are almost identical other than having different mobile OS’s to sort out. The CannotHandle concrete handler is just a caboose the both mark the end of the chain and let the user know that his request cannot be handled. It has no successor and the sendBack() function tells the user that her request cannot be handled.

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

//Android
package
{
	public class Android extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="android")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not Android");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//iPhone
package
{
	public class IPhone extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="iphone")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not iPhone");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//BlackBerry
package
{
	public class Blackberry extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="blackberry")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not Blackberry");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//Series60
package
{
	public class Series60 extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="series60")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not Series60");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//Windows CE
package
{
	public class WindowsCE extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="windowsce")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not WindowsCE");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//CannotHandle
package
{
	public class CannotHandle extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			mobileType = "Rats! We looked and couldn't find that mobile OS. \n"
			mobileType += "We'll just have to get to work and see if we can \ndevelop a way to handle it for you.";
			sendBack();
 
		}
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}

Testing the Chain

Figure 2: UI provides a way to test the chain.

If an OS near the end of the chain is selected, you can see all of the links in the chain used to find the correct handler. Figure 3 shows what occurs if “windowsce” is requested. Had “android” been the search OS, it would have popped up without any links in the chain showing it was not found.

Figure 3: Output showing steps in sequence and feedback.

Finally, if the request cannot be handled, an important development step is to add a handler that tells the user that his OS cannot be found. The final handler in a chain has no successor, and you definitely do not want to link back to the beginning of the chain! That would set up an infinite loop. Figure 4 shows the feedback when a request cannot be handled:

Figure 4: Feedback for an unhandled request.

JavaScript is the Next Link

In Part II, I’d like to step through these same classes using JavaScript prototype classes and see if we can use the same pattern. I think that if each concrete handler can configure the screen for a particular mobile device, it would be quite useful. As new devices are added, such as iPad, Kindle Fire, and various other tablets, you will find that the flexibility afforded by the Chain of Responsibility. To get ready for Part II, go over the ActionScript 3.0 version and make sure everything makes sense. Send in comments if you have a question.

Face the Facts: We've got to deal with Mobile

At this point in time I can easily create a script to determine whether a browser is mobile or non-mobile. I want to get to the point where I can put together a Chain of Responsibility pattern so that I have a flexible design for tweaking a specific kind of mobile device (e.g., calling up appropriate CSS). This requires OOP JavaScript, and so I had to revisit my old JavaScript work. One of the best books on both OOP and JavaScript is Javascript Objects: Object Use and Data Manipulation with JavaScript by Alenander Nakhimovsky and Tom Myers published by Wrox in 1998. It was written by a couple of professors at Colgate University and is pitched at a pretty high level that most readers of this blog will appreciate. (You can still get it from Amazon, and it’s a gem to have no matter what language you favor.) Another good book that deals with JavaScript objects is Douglas Crockford’s JavaScript: The Good Parts (O’Reilly, 2008). Crockford understands JavaScript down to the metal and has great explanations and examples.

So the question is:

Can JavaScript handle OOP and Design Patterns?

To find out, I started writing some prototype classes but found I’d have to spend some more time trying to cobble something together that was both reasonable (it maintains the DP value of flexibility, update and reuse) and real (I didn’t want to make a phony DP with hack classes.) However, it didn’t take long to put together a little code that works to filter out both different mobile devices and non-mobile devices. My plan is to take this code and change it so that I can do the same thing with a Chain of Responsibility design pattern. Here’s the code:

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

// JavaScript Document
var sniffer=new Object();
var agentNow=navigator.userAgent.toLowerCase();
sniffer.android=(agentNow.search("android")>=0);
sniffer.series60=(agentNow.search("series60")>=0);
sniffer.iphone=(agentNow.search("iphone")>=0);
sniffer.blackberry=(agentNow.search("blackberry")>=0);
sniffer.windowsce=(agentNow.search("windows ce")>=0);
var counter=0;
var flag=new Object();
flag.nonMobile=true;
for(var mobile in sniffer)
{
	if(sniffer[mobile])
	{
		switch(counter) {
		case 0:
		document.write("android<br/>");
		flag.nonMobile=false;
		break;
		case 1:
		document.write("series60<br/>");
		flag.nonMobile=false;
		break;
		case 2:
		document.write("iphone<br/>");
		flag.nonMobile=false;
		break;
		case 3:
		document.write("blackberry<br/>");
		flag.nonMobile=false;
		break;
		case 4:
		document.write("windows ce<br/>");
		flag.nonMobile=false;
		break;
		}
	}
	counter++;
}
if(flag.nonMobile)
{
		document.write("Non-mobile or unrecognized device.");
		document.write("<br/>");
}

Before you say anything (or think anything), I realize that this code is about as flexible as a rebar (AKA: reinforcing bar), and if you’re into JavaScript, you can think of 10 ways that this can be done better. However, the goal is to see if this can be refactored into a design pattern. Here’s my plan:

1. Set up a dummy Chain of Responsibility that links the different kinds of responsibilities.
2. Have each responsibility be actions taken for different kinds of mobile devices or a desktop.
3. Use JavaScript objects to do the work of the concrete handlers

However, before I get started on this project, I’d really like to hear from you and even better, see what you can do with this challenge. So between now and the next post on this topic, let’s hear from you! Also feel free to add different kinds of mobile devices such as tablets and other phone OSs.

As ActionScript 3.0 grows and changes, we can apply the old design patterns and begin looking for new patters to accommodate some changes.

AIR for Androids, iOS and Blackberry

Currently, the focus of most of the posts on this blog have been design patterns using ActionScript 3.0 with an occasional visit to some interesting structures such as dependency injection and skip lists. Now, a lot of the discussion will shift to newer statements and elements that make up the Flex/Flash family of APis and platforms. In particular you will want to take a look at the AIR 3 reference guide. Herein lie the statements, packages and namespaces that make up a lot of the new features we need to consider. Adobe helpfully marks each AIR class with a little red triangles with balls on the points. In creating an AIR app, whether for a mobile device or computer, there are differences depending on the hardware device. Once we’ve covered several and created sample examples, we can cast them into design patterns. So, consider this next set of posts to be a temporary detour that will take the knowledge set forward but keep the utility of what has passed.

Removing Decorations can be Tricky

The 2010 film, “Repo Men” is about a dark future where body parts are purchased much like homes. You get the needed part (like Steve Jobs got his liver) and pay for it with a mortgage. If you fall behind in your payments, the Repo Men come and take it away so that it can be sold to another customer. It turns out that removing a decorator from a component in the Decorator Design Pattern is about as draconian. All along I had imagined it about as simple as removing ornaments from a Christmas tree. Apparently others have issued similar claims, but try and find a decent example, and you’re likely to come up blank. I finally was able to track down an example in O’Reilly Media’s Head First Labs, and it works; sort of. First, though, consider why adding and removing decorations is worthwhile investigating.

Why Removing Concrete Decorations is Important

Now that I’ve been programming madly to get ActionScript 3.0 to work with mobile devices (the iPhone in particular), I’m finding that creating graphic objects is sloooow. The idea behind developing games with patterns like Decorator is that I can take a component and add and remove decorations without having to recreate the object with all of elements that go with it. I can just add and subtract concrete decorators and leave the component as is. This would seem much faster because I’m instantiating less. (Yes, the Flyweight pattern would be another for adding some speed to the process.) Of course you don’t have to be developing for mobile devices; it’s just as handy for computers.

Removing One Decoration Works Fine

I tried out the fix suggested in Head First Labs, and it works dandy. Go ahead and download all the files (they’re two sets in a single zip file; one for removing a single decorator and another for multiple) and then click the Play button to see how a single removal works:

All downloads are now on the University of Hartford’s MWDD Download Page. Select the last window to the right (ActionScript 3.0/Flash) and click on the bottom link and then click the Download button.

donE
The movement to the left and right was to show how the decorated component is a “single object,” but even that is a bit of fakery. Here’s the code:

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

package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class Component;
	{
		protected var armor:Sprite;
 
		public function getarmor():Sprite
		{
			return armor;
		}
		//remove
		public function removeArmor():Component
		{
			return this;
		}
	}
}

In the Component abstract class, you can see the addition of a single added method, removeArmor(). What you may be scratching your head about is why a Component object is returned. That’s what’s decorated, no? Shouldn’t it be zapping a decoration? What the function appears to be doing is stripping the component of all decorations. But let’s move on to the Decorator, both abstract and concrete:

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

//Abstract Class Decorator
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class Decorator extends Component
	{
		override public function getarmor():Sprite
		{
			return armor;
		}
		protected var char:Component;
	}
}
 
//Concrete Decorator Class
package
{
	import flash.display.Sprite;
	//Concrete decorator Shield
 
	public class DecShield extends Decorator
	{
		public function DecShield(char:Component)
		{
			this.char = char;
		}
		//Shield is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new Shield();
			armor.x=75,armor.y=250;
			return armor;
		}
		//remove Shield
		override public function removeArmor():Component
		{
			return char;
		}
	}
}

The char variable is a protected Component one inherited from the Decorator abstract class. What is “removed” is any decoration, and in this case, it’s the last decoration. In other words, it just returns the “naked” concrete component.

The base component is in the concrete component, Warrior. It’s just a Sprite stored in the library. (StickMan())

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

//Concrete component
package
{
	import flash.display.Sprite;
 
	//Concrete component
	public class Warrior extends Component
	{
		private var warrior:Sprite=new StickMan();
		public function Warrior()
		{
			armor=warrior;
		}
	}
}

So, the trick in this implementation of decoration removal is simply to return a component with no decorations; hence, ‘remove’ the decoration.

The Client class takes care of everything by first adding a graphic component, and then providing a single decoration and then removing that decoration.

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client class
	public class Client extends Sprite
	{
		private var warrior:Component=new Warrior();
		private var addBtn:Button=new Button();
		private var removeBtn:Button=new Button();
		private var moveBtn:Button=new Button();
		private var moveLBtn:Button=new Button();
		private var warriorSpirit:Sprite=new Sprite();
		private var warriorObj:Sprite;
		private var shieldObj:Sprite;
 
		public function Client()
		{
			warriorObj = warrior.getarmor();
			addChild(warriorSpirit);
			warriorSpirit.addChild(warriorObj);
			addBtn.x = 250,addBtn.y = 100;
			addBtn.label = "Add Shield";
			addBtn.addEventListener(MouseEvent.CLICK,addShield);
			removeBtn.x = 250,removeBtn.y = 140;
			removeBtn.label = "Remove Shield";
			removeBtn.addEventListener(MouseEvent.CLICK,removeShield);
			addChild(addBtn);
			addChild(removeBtn);
 
			moveBtn.label = "Move Right";
			moveBtn.addEventListener(MouseEvent.CLICK,moveRight);
			moveBtn.x = 250,moveBtn.y = 180;
			addChild(moveBtn);
 
			moveLBtn.label = "Move Left";
			moveLBtn.addEventListener(MouseEvent.CLICK,moveLeft);
			moveLBtn.x = 360,moveLBtn.y = 180;
			addChild(moveLBtn);
		}
 
		private function addShield(e:MouseEvent):void
		{
			warrior = new DecShield(warrior);
			shieldObj = warrior.getarmor();
			warriorSpirit.addChild(shieldObj);
		}
 
		private function removeShield(e:MouseEvent):void
		{
			warrior = warrior.removeArmor();
			warriorSpirit.removeChild(shieldObj);
			warriorSpirit.addChild(warrior.getarmor());
		}
 
		private function moveRight(e:MouseEvent):void
		{
			warriorSpirit.x +=  30;
		}
 
		private function moveLeft(e:MouseEvent):void
		{
			warriorSpirit.x -=  30;
		}
 
	}
}

You will also notice that the buttons that moved the objects to the left and right did so within a single sprite (warriorSpirit) where both the component and its decoration were placed as returned Sprite objects. While the decoration is composed in the pattern, it and the concrete component are in no way “locked” together as sprites. In order for them to be locked, they had to be placed in a wrapper sprite which was moved across the stage.

Adding more than a single decoration does not do well with removal

In making a game, you want to be able to add or remove decorations at will. You should be able to remove one, two or all without a problem. However, using the only decoration removal method I could find, I was unable to do so. When you try out the following implementation, here’s what happens: If you add one decoration and then remove it, everything works fine. However, if you add more than a single decoration before removing it, only the last one added will be removed. What appears to happen is that when the remove() method fires, it returns an undecorated component. The current one is replaced, but the previous decoration stays put as an independent entity. That’s why with only one decoration, everything seems to work ok.

Click the Play button to see what happens:

The only added class is a DecSword concrete decorator class to call up the Sword class and position it on the 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

package
{
	import flash.display.Sprite;
	//Concrete decorator Sword
 
	public class DecSword extends Decorator
	{
		public function DecSword(char:Component)
		{
			this.char = char;
		}
		//Shield is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new Sword();
			armor.x=90, armor.y=180;
			armor.rotation=20;
			return armor;
		}
		//remove Sword
		override public function removeArmor():Component
		{
			return char;
		}
	}
}

It’s identical to DecShield except for the different position instantiates the Sword sprite instead of the Shield.

In addition to adding a sword decoration, it also changes the way that the sprites are placed on the stage in the Client class. It does not have the spriteWarrior sprite to acts as a holder for all of the decorations added to the stage. Instead, the concrete component and decoration sprites are placed directly on the 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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client class
	public class Client extends Sprite
	{
		private var warrior:Component=new Warrior();
		private var addBtn:Button=new Button();
		private var removeBtn:Button=new Button();
		private var addSwBtn:Button=new Button();
		private var removeSwBtn:Button=new Button();
		private var warriorObj:Sprite;
		private var shieldObj:Sprite;
		private var swordObj:Sprite;
 
		public function Client()
		{
			warriorObj=warrior.getarmor();
			addChild(warriorObj);
 
			addBtn.x=250,addBtn.y=100;
			addBtn.label="Add Shield";
			addBtn.addEventListener(MouseEvent.CLICK,addShield);
			addChild(addBtn);
 
			removeBtn.x=250,removeBtn.y=140;
			removeBtn.label="Remove Shield";
			removeBtn.addEventListener(MouseEvent.CLICK,removeShield);
			addChild(removeBtn);
 
			addSwBtn.x=360,addSwBtn.y=100;
			addSwBtn.label="Add Sword";
			addSwBtn.addEventListener(MouseEvent.CLICK,addSword);
			addChild(addSwBtn);
 
			removeSwBtn.x=360,removeSwBtn.y=140;
			removeSwBtn.label="Remove Sword";
			removeSwBtn.addEventListener(MouseEvent.CLICK,removeSword);
			addChild(removeSwBtn);
		}
 
		private function addShield(e:MouseEvent):void
		{
			warrior=new DecShield(warrior);
			shieldObj=warrior.getarmor();
			addChild(shieldObj);
		}
 
		private function removeShield(e:MouseEvent):void
		{
			warrior = warrior.removeArmor();
			removeChild(shieldObj);
			addChild(warrior.getarmor());
		}
 
		private function addSword(e:MouseEvent):void
		{
			warrior=new DecSword(warrior);
			swordObj=warrior.getarmor();
			addChild(swordObj);
		}
 
		private function removeSword(e:MouseEvent):void
		{
			warrior = warrior.removeArmor();
			removeChild(swordObj);
			addChild(warrior.getarmor());
		}
	}
}

By using removeChild(obj), it would be possible to remove the sprite objects of the shield and sword from the stage, but I do not believe it would remove them as a decoration from the component. Currently, the removeChild() function targets whichever sprite-object-as-decorator was the last created decoration.

Be The Repo Man!

I’ve been butting my head against this issue for a while, and I have a feeling that either I’m missing something quite obvious or I’m very close to a solution that still eludes me. So here’s a chance for you, the reader, to work out a way to retrieve the decorations from the component in any order. So be the Repo Man (or Woman) and see if you can work out a solution.

Change orientation with device position

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

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

Re-Decorating

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

Figure 1:Decorator File Diagram

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

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

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

The Client

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

1
2
3

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

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

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

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

Publishing for Mobile

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

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

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

Figure 2: Open a New ActionScript Mobile Project

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

Figure3: Mobile Settings

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

Figure 4: Specify Platformsettings

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

Figure 5: Include additional or different paths if requires

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

Figure 6: Run Configurations

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

Figure 7: Setting Certificate and Provisioning files

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

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

Figure 8: Completed Window

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

Figure 9 Drag .ipa package into iTunes Apps Library

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

Figure 10: Adding the app to an iOS device

Adding the State Design

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

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

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.

Flexible Design Pattern Re-used with Flash Builder Development

A couple of days ago, we had an example for beginners creating a mobile application using Flash Professional. We used an Android example because everyone can get the tools they need for emulating an Android. (By the way, partnering up with Google-Android and Flash was a brilliant move by Android. Being an “Apple Guy,” I thought I’d be doing nothing but apps for my iPhone and iPads; however, Android made it a lot easier to develop apps for Android using some kind of ActionScript 3.0 development tool, and Blackberry’s not far behind. So I am very happy to know that iOS is now available, but they’ll just have to wait their turn for a beginner’s post.) As promised, I wanted to create a beginner’s example using Flash Builder. This example uses the same Strategy Pattern as the Flash mobile tutorial. However, as you will see, there are some key differences when dealing with Flash Pro and Flash Builder. Also, I hope you see that a very different logo (FB instead of Sandlight) and text. All that was changed for this difference was swapping the image used for the logo and the text in the external text file. Also, I had to change some settings in the BringText class, but that too was easy and didn’t upset the program. Why? Because it was a design pattern!

Stepping Through Flash Builder Mobile

This is going to be the same walk-through with Flash Builder as with Flash Pro but with a few differences. The Flash Builder work flow is slightly different, but you will find more similarities than differences. Before we get going download Flash Builder 4.5.1. (You can use the 30-day free trial version.) You can probably work with FB 4 with all of the updates, including the Android SDK, but everything in this example was done with FB 4.5.1. (If you are a student or faculty, you can get a free educational version of FB if you contact Adobe with your student or faculty ID. Faculty can get it free for their classrooms and labs as well.) Install to the defaults. Go to Adobe Labs download and install both Adobe AIR 3 (beta) and Adobe Flash Player 11 (beta) and let’s get started:

First, open Flash Builder and select File > New > ActionScript Mobile Project. (Note: You will find both a Flex Mobile Project and an ActionScript Mobile Project; be sure to select ActionScript Mobile Project.) In the Project name window, name the project FBmoStrat as shown in Figure 1 :

Figure 1: New ActionScript Mobile Project window

I used the default location and the default SDK, which was Flex 4.5.1. Click Next.

Second, when The Create an ActionScript Mobile AIR Project window appears with the Mobile Settings tab selected, you will see that all Target platforms (Apple iOS, BlackBerry Tablet OS and Google Android) are checked as shown in Figure 2.

Figure 2:Initial Create Window

Third, uncheck both the Apple iOS and BlackBerry Tablet OS. When you do that, the Permissions for Android appear as shown in Figure 3:

Figure 3: Android Permissions

Be sure that the Platform is Google Android and that the only permission checked is INTERNET. The default is to Automatically reorient the screen in the Application settings. Leave that default checked and click the Next button.

Fourth, in the Build Paths step, you will see a set of default selections you can leave alone except for the Main application file that you want to change from FBmoStrat.as to Client.as. Figure 4 shows the step correctly configured:

Figure 4: Build Paths step

If your Build Paths steps looks like Figure 4, click Finish. You should see the following script automatically generated:

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

package
{
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
 
	public class Client extends Sprite
	{
		public function Client()
		{
			super();
 
			// support autoOrients
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
		}
	}
}

The Stage Align and StageScaleMode built-in ActionScript 3.0 classes will help align the application when it is turned in different directions. The super() method invokes the parent class Sprite. You will be leaving the constructor function as is but add more materials for the Client class. Before doing that, go ahead and test the problem and download all of the files with the buttons below:

You still will need to test the file from Flash Builder and contend with one last set of settings. So gather up all of the files and read on before testing.

Testing from Flash Builder

Once you all of the classes in the project are saved in the Flash Builder src folder, along with the graphic file and text file, click the Run button to test the application. The first time you do this, you will see the Run Configurations window shown in Figure 5.

Figure 5: Run Configurations window

In the Launch method area, select the On desktop radio button, and select Mororola Droid 2 and click the Apply button. Finally, click the Run button.

The Strategy Design Pattern in a Mobile Context

If you read the post on creating this app using Flash Pro, there’s not much new here. This post is only meant to show how to add a design pattern into a mobile application using Flash Builder. If you use apps on mobile devices, you must be aware of the updating that your app goes through. Using the Strategy pattern, adding more concrete strategies is easy, and changing the graphic and text contents is equally easy. In other words, this is a very flexible tool to both create and update mobile applications just as it is with traditional applications. The following classes are little changed from the previous post using Flash Pro, but they are included for review and the small differences that could impact your understanding.

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

//Client
package
{
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
 
	public class Client extends Sprite
	{
		protected var context:Context=new Context(new BringGraphic());
		protected var contextTxt:Context=new Context(new BringText());
		protected var mobileSprite:Sprite=new Sprite();
		protected var textSprite:Sprite=new Sprite();
 
		public function Client()
		{
			super();
 
			// support autoOrients
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
			setLogo();
			setText();
		}
		protected function setLogo():void
		{
			mobileSprite.addChild(context.bringLoad("mobilelogo.png"));
			mobileSprite.x = 5,mobileSprite.y = 10;
			addChild(mobileSprite);
		}
 
		protected function setText():void
		{
			textSprite.addChild(contextTxt.bringLoad("mobile.txt"));
			textSprite.x = 5,textSprite.y = 150;
			addChild(textSprite);
		}
	}
}
 
//Context
package
{
	import flash.display.Sprite;
 
	public class Context extends Sprite
	{
		private var bring:IStrategy;
		private var bringObj:Sprite=new Sprite();
 
		public function Context(bring:IStrategy)
		{
			this.bring = bring;
		}
 
		public function bringLoad(url:String):Sprite
		{
			bringObj.addChild(bring.contentLoader(url));
			return bringObj;
		}
	}
}
 
//IStrategy interface
package
{
	import flash.display.Sprite;
	public interface IStrategy
	{
		function contentLoader(url:String):Sprite;
	}
}
 
//Bring Graphic--loads graphics and SWF files
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.display.Sprite;
 
	class BringGraphic implements IStrategy
	{
		private var urlReq:URLRequest;
		private var loader:Loader;
		private var objNow:Sprite=new Sprite();
 
		public function contentLoader(url:String):Sprite
		{
			urlReq = new URLRequest(url);
			loader=new Loader();
			loader.load(urlReq);
			objNow.addChild(loader);
			return objNow;
		}
	}
}
 
//BringText -- loads external text and xml files and formats text
package
{
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.net.URLLoader;
	import flash.net.URLRequest;
	import flash.events.Event;
 
	public class BringText implements IStrategy
	{
		private var textContainer:Sprite=new Sprite();
		private var urlNow:URLRequest;
		private var txtLoader:URLLoader=new URLLoader();
		private var txtFld:TextField=new TextField();
		private var txtFormat:TextFormat=new TextFormat();
		private var uLoader:URLLoader;
 
		public function contentLoader(url:String):Sprite
		{
			urlNow=new URLRequest(url);
			txtLoader.addEventListener(Event.COMPLETE, addTxtFld);
			txtLoader.load(urlNow);
			return textContainer;
		}
 
		private function addTxtFld(e:Event):void
		{
			uLoader=URLLoader(e.target);
			txtFormat=new  TextFormat();
			txtFormat.font="Verdana";
			txtFormat.size=24;
			txtFormat.color=0x000000;
			txtFld.defaultTextFormat=txtFormat;
			txtFld.multiline=true;
			txtFld.width=300;
			txtFld.height=300;
			txtFld.wordWrap=true;
			txtFld.x=10,txtFld.y=50;
			txtFld.text=uLoader.data;
			textContainer.addChild(txtFld);
		}
	}
}

If someone would like to add their own logo and text about their company, services or products using this application, we’d like to show them off. It’d be a good use of the design pattern, and you’d get some worldwide notoriety for your company!

ActionScript 3.0 Design Patterns in Mobile Apps

The very first mobile app I want to build is one that I can give away to promote my company or my clients’ companies. Yes, I’d like to make lots of money with a mobile action game like Angry Birds, but in order to get started, I want something that I can easily update and change. It seems like every time I check my phone apps, I’ve got updates. What is one of the main features of Design Patterns? Easy updates! So, if you want to create mobile applications in ActionScirpt 3.0 that are easy to update, you’ll find design patterns your BFF!

This first one is built with Flash CS5.5. If you do not have Flash CS5.5; download the 30-day trial version. If you’re using Flash Builder, use FB 4.5.1. or download the trial version. (I hope to have a FB tutorial using this same example later in the week. In the meantime, take a look at Christian Peters’ mobile example for building an app using design patterns with Flash Builder.)

This first example uses a Strategy pattern with algorithms for loading external images (or .SWF files) and text. That is exactly what I need for a mobile app promoting my company. With the image loading capability, I can load my logo and any images that show off products and services. The concrete text strategy loads up data from external text files. So this ought to be the easiest app to update imaginable!

Easy Android

I was going to start off with an iOS example, but I realized that most of you probably didn’t want to shell out the $99 developer fee required by Apple for iOS development. So, instead I decided to use an Android example that you could test using an Android emulator. To get started, go ahead and download the source code and see what the app displays:

All of the Downloads have been moved to the University of Hartford’s Multimedia Web Design and Development Program page. The last entry under “ActionScript 3.0/ Flash” should have what you want. (I’m still working on it to include a short description of each entry–it’s in the database; just not on the screen).

When you run it, you will quickly see that a logo and block of text pops up. That’s it. Swap out your own logo and texts, and you’re in business. You can change any of the parameters in the BringText concrete strategy class to alter the text appearance, it’s placement and other features to suite your own tastes or business brand.

Starting from Scratch

Since this is a first time experience for beginners and mobile (which may include experienced ActionScript 3.0 programmers), we’ll step through the set-up beginning with the FLA file. So read on through the following steps:

First, download and install the Android SDK. If your system is not automatically selected, choose the correct OS. Install the SDK.

Second, install the Adobe AIR 3 beta and Adobe Flash Player 11 beta, both at Adobe Labs.

Third, download and install Flash CS5.5 trial if you don’t have it. (If you have Flash CS5 and have installed all of the updates, you ought to be ok.)

Fourth, in your root directory, create a folder named “Developer.” For example, on a Mac, you’d open up your Macintosh HD and add the Developer folder.( A hammer icon may automatically appear on the folder.)

Fifth, open Flash CS5.5 and select AIR for Android. Configure the screen for 320 x 470. (If you have an Android phone with a different screen size, configure it for your phone size.) Create a folder named MobileApp inside of the Developer folder, and save the file as AndroidStrategy.fla.

Sixth, with the stage selected, open the Properties panel. In the text window labeled “Class” enter the Class name “Client.”

Seventh, in the Properties panel in the Publish grouping, you should see AIR for Android next to “Player.” You will see a wrench icon to the right. Click the icon to open the AIR for Android Settings window. Figure 1 shows what you should see. If anything looks different, check to make sure you followed the previous steps.

Figure 1:General AIR for Android Settings

Eighth, in the AIR for Android window, click the Deployment tab (near the top of the window next to the General tab.) Figure 2 shows the Deployment selections. You will need to create a Certificate and Password. Click the Create button to create a certificate. You can use any names you want; something simple works fine. You can use the same certificate for other projects. I had placed the Android SDK in the Development folder and once I created the certificate, the full URL is:

/Developer/android-sdk-mac_x86/platform-tools/adb.p12.

If you do not see a “platform-tools” folder in your SDK folder, you’ll need to update your Android SDK by downloading the most recent release. (The earlier ones had the needed files in a different folder.)

Figure 2: Deployment Tab in AIR for Android Settings Window

Be sure to remember your password, and it helps to click the Remember password for this session so you don’t have to keep re-entering it. Set the Android deployment to Emulator release and don’t select any of the After publishing checkboxes. When you’re all finished click OK. You’re all set for a mobile app using design patterns!

Adding the Design Pattern

This final section uses a simple Strategy design pattern. (If you’re not familiar with the Strategy pattern, we have a saturated series on it as well as a simple introduction.) As noted at the outset, this implementation of the Strategy pattern pulls in graphics and text through Client requests. However, because of the pattern design, there’s minimal object binding, and any updates or changes will not unravel the whole program. Also, because it’s simple, it’s a good pattern to use to understand the basics of the Strategy pattern.

The Client

Without a UI, the pattern is quite easy. The Client simply requests what it wants using literal names for graphic images and the text in an external text file. The following shows the Client code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package
{
	import flash.display.Sprite;
	public class Client extends Sprite
	{
		protected var context:Context=new Context(new BringGraphic());
		protected var contextTxt:Context=new Context(new BringText());
		protected var mobileSprite:Sprite=new Sprite();
		protected var textSprite:Sprite=new Sprite();
 
		public function Client()
		{
			setLogo();
			setText();
		}
 
		protected function setLogo():void
		{
			mobileSprite.addChild(context.bringLoad("mobilelogo.png"));
			mobileSprite.x = 5,mobileSprite.y = 10;
			addChild(mobileSprite);
		}
 
		protected function setText():void
		{
			textSprite.addChild(contextTxt.bringLoad("mobile.txt"));
			textSprite.x = 5,textSprite.y = 150;
			addChild(textSprite);
		}
	}
}

The protected accessors have been employed so that when the app is developed in Flash Builder in the Flex element, it’ll feel right at home. However, in this Client, private access would have worked fine. This particular implementation of the Strategy returns Sprite objects containing both Text and Graphics, including other Sprite objects. As a result, even the text is added to the stage inside a Sprite. Notice that all requests go through the Context class.

The Context Class and Strategy Interface

Even though the pattern diagrams for the State and Strategy patterns are identical, the intent is quite different. Most important is the Context class in the Strategy design. It does not keep track of a current state as does the State pattern.

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

//Context Participant
package
{
	import flash.display.Sprite;
 
	public class Context extends Sprite
	{
		private var bring:IStrategy;
		private var bringObj:Sprite=new Sprite();
 
		public function Context(bring:IStrategy)
		{
			this.bring = bring;
		}
 
		public function bringLoad(url:String):Sprite
		{
			bringObj.addChild(bring.contentLoader(url));
			return bringObj;
		}
	}
}

In some respects the Context class in the Strategy resembles a factory because the request for strategies is made through the Context, but it does not really instantiate a concrete strategy as a factory would. The Sprite instantiated in the Context (bringObj) acts as a carrying container to return the requested strategy to the requesting class (Client in this case.) However, no concrete strategies are created.

The IStrategy interface has a single method to be implemented. The method is used to pass requests back to the requesting class.

1
2
3
4
5
6
7
8
9

package
{
	import flash.display.Sprite;
	public interface IStrategy
	{
		function contentLoader(url:String):Sprite;
	}
 
}

The IStrategy interface leaves a lot of flexibility for adding more concrete strategies for returning Sprite (or Sprite encased) materials to the client.

Concrete Strategies

Finally, the two concrete strategies both load external content. The first is an image/SWF loader and the latter is a text/xml file loader. It is simple and flexible:

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

//Graphic and SWF Loader
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.display.Sprite;
 
	class BringGraphic implements IStrategy
	{
		private var urlReq:URLRequest;
		private var loader:Loader;
		private var objNow:Sprite=new Sprite();
 
		public function contentLoader(url:String):Sprite
		{
			urlReq = new URLRequest(url);
			loader=new Loader();
			loader.load(urlReq);
			objNow.addChild(loader);
			return objNow;
		}
	}
}

The BringText class required an event handler function for insuring that the text was completely loaded. The event handler method is a convenient place to put the TextFormat object and properties. Once the text is pulled out of the text or xml file and placed into the formatted text field, it was packed up and put into a Sprite object ready to return to the Client.

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

//Text and XML Loader
package
{
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.net.URLLoader;
	import flash.net.URLRequest;
	import flash.events.Event;
 
	public class BringText implements IStrategy
	{
		private var textContainer:Sprite=new Sprite();
		private var urlNow:URLRequest;
		private var txtLoader:URLLoader=new URLLoader();
		private var txtFld:TextField=new TextField();
		private var txtFormat:TextFormat=new TextFormat();
		private var uLoader:URLLoader;
 
		public function contentLoader(url:String):Sprite
		{
			urlNow=new URLRequest(url);
			txtLoader.addEventListener(Event.COMPLETE, addTxtFld);
			txtLoader.load(urlNow);
			return textContainer;
		}
 
		private function addTxtFld(e:Event):void
		{
			uLoader=URLLoader(e.target);
			txtFormat=new  TextFormat();
			txtFormat.font="Verdana";
			txtFormat.size=24;
			txtFormat.color=0x000000;
			txtFld.defaultTextFormat=txtFormat;
			txtFld.multiline=true;
			txtFld.width=300;
			txtFld.height=250;
			txtFld.wordWrap=true;
			txtFld.x=10,txtFld.y=90;
			txtFld.text=uLoader.data;
			textContainer.addChild(txtFld);
		}
	}
}

As noted, this pattern is simple, but very handy. The classes are reusable and simple to update and change. Further, adding more classes is just as easy, and that means updating the mobile application is simple.

On to Flex and Flash Builder

The next step is to take the ActionScript 3.0 in this mobile application and do the same thing in Flash Builder. The Client class will have to reside in an MXML file instead of an AS file. Next up, we’ll see how to take this app and bundle it up using Flash builder. I’d also like to see other simple Flex/Flash Builder mobile design pattern examples that might help our readers—even implementations of this code in the Flash Builder IDE.