ActionScript 3.0 Design Patterns

It’s Easy Once You Get Your Certificate and Provisioning Profile

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.)

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:

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:

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:

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.

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.

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.)

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.

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.

Surprise your Users!

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.

As you can see in Figure 1, the Client makes the requests through the ICreator (factory) interface, the concrete factories instantiate the concrete products, which load the SWF files for display. The RandomSelector class sits off by the side providing a random value.
Read more…

Join the Campaign to Stamp Out Ugly!

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:

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).

In looking at Figure 2 code snippets, notice how many times that Creator or Product are used. Both reflect the wholly abstract interfaces in the program. By making references to the interfaces (or abstract classes), the binding between the Client and the requests is very loose. By having loose binding through abstractions, the developer can better update and change the program. The only part of the objects exposed are those that are required. If the concrete products change, the Client is not tightly bound to the concrete elements because the requests hold references to the abstract interfaces and not the concrete participants. (Read on to see how these are all put together!)
Read more…

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

Lazy Bones

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

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

 

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

The other day I was re-reading Chandima’s description of key OOP concepts used in the Factory Method design pattern. It is beautifully encapsulated in a little over a half a page (page 84). The Factory Method allows you to separate the creation of objects from their use. It says a bit more, but it is a nice piece in both describing a design pattern principle and explaining what the Factory Method does. This led to re-reading the Factory Method chapter in Design Patterns: Elements of Reusable Object-Oriented Software—the Gang of Four’s book. Normally, I just go over the main points, but I came across a little passage that read:

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:

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.)

Read more…

Every Monday I have to separate out the paper, glass, aluminum, and plastic to recycle and take them up to the curb. This last Monday while engaged in this weekly ritual, I thought that recycling a design pattern might be an interesting exercise. Additionally, it’s the kind of design pattern advantage that can be used at work to save re-inventing the wheel when you have a similar development task. You may remember the Dragon Factory where we employed a Factory Method to set up an easy-to-use drag application. In the original Dragon Factory, both the Creator and Product participants had subclasses. However, with only a slight revision, it’s possible to create a little game for making different faces subclassing only the Product interface (abstract class). Figure 1 shows the File-Class Diagram:

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

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

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

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

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

A Tale of Two Factories: One New and One Reused

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.
Read more…

In the first part of this article, Friends with Benefits: Refactoring with Multiple Design Patterns—Part I you saw how a Factory Method design pattern was used to hold and deliver data to a DataProvider object. The Factory Method design pattern allowed for easy update by simply adding items to concrete products from a Product interface (DataSupply) or new concrete Product classes. New data can be added to the Concrete Products and the Client makes requests through the Creator interface. The request is filtered through the Concrete Creator to the Product interface to the concrete Product classes. Now, all we need to do is to refactor the player with a design pattern. However, before starting download the application (With 12 classes in the design patterns, a Client class plus three folders of videos, there’s a lot!) So first off, click here to Download All Files . You can see a working version of the player and multiple data sets here. These will help pull together all of the elements used in this project.

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:
Read more…

The Case of the Crowded Client

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.
Read more…