Archive for the 'Examples' Category

Hitchhiker’s Guide to ActionScript 3.0: Dragging through the Galaxy—Part 1

Published on September 9, 2009 in Closer Look and Examples. by William B. Sanders 11 Comments
A Closer Look

A Closer Look

I have no idea how things pop into my head or why. However, they do, and like unscratched itches, if I don’t attend to them they stay put. One such idea that cropped up was…

How do you drag a live video across the screen?

I have no idea why someone would want to do that either; so don’t ask. For 95% of you reading this, the answer is simple, but for the 5% of you in rehab this post may be of some use—at least until the pink elephants go away.

Because this is a Design Pattern blog, I should include some design pattern. I could slap a Singleton in front of it, but I pretty well shot my chances of doing that with my ongoing persecution of that miserable pattern. So I need to pose my question in a broader context,

What design pattern could be used to drag anything across the screen?

Well, put that way, we can make a more interesting project. This short post simply examines how to embed and drag a non-Sprite object in a Sprite object. In Part II, we’ll see how to create a design pattern that easily allows production of objects and placing them into a Sprite instance for dragging anything.

Hitch Your Wagon to a Sprite

Back in the days before ActionScript 3.0, about the only thing you could address on the stage was a MovieClip instance—or a derivative of a MovieClip. For some of us, the lesson was too well learned, and I often think, MovieClip instead of Sprite. Anyway, you can address a Sprite just as well and you don’t have the Timeline to go along for the ride. The trick back in the day was to dump anything you wanted to go along with the MovieClip into the movie clip. So if you had a graphic symbol, for instance, that you wanted to drag, you’d just put it into the MovieClip object and drag the movie clip. However, because the key methods of startDrag() and stopDrag() are part of the Sprite class, you can use the Sprite to do the same thing.

Continue reading ‘Hitchhiker’s Guide to ActionScript 3.0: Dragging through the Galaxy—Part 1′

  • Share/Bookmark

Artists, Animators and ActionScript 3.0

Published on August 25, 2009 in ActionScript, Examples and OOP. by William B. Sanders 26 Comments

Artists and Graphic Designers

designer

For me, graphic designers and artists are angels. No matter how I try, I can only get so far in graphic design. Tools like clip art, templates, and Kuler help me achieve not awful , but that’s it. (I can even screw up clip art.) So, for anything serious, I’ve got to work with graphic artists. That’s no problem—I like working with angels.

Some graphic artist have made the transition to some version of ActionScript, but with ActionScript 3.0 most complained that they were getting left behind. Early Flash had few ActionScript options and a system for entering code that didn’t require any programming background at all. With ActionScript 2.0, things got better for developers, but designers started voicing concern over increased complexity. With ActionScript 3.0 and the loss of the ability to put code into buttons and MovieClip objects directly, some graphic artists became furious with Flash over what they saw as a betrayal. It was like a carload of kids on the way to do something fun ditched the artists and designers on the roadside.
Continue reading ‘Artists, Animators and ActionScript 3.0′

  • Share/Bookmark

Wrong Way Warrior: Getting Flexibility with Design Patterns—Part II

Published on August 19, 2009 in ActionScript, Design Patterns, Examples, Principles and Strategy Pattern. by William B. Sanders 10 Comments

Gentle Reader: This is the second part of a two-part set of posts. For this one to be useful, please take a look at Part I. Also, I’m not an expert on military operations or organizations; so if there’s any error in a basic infantry platoon, feel free to correct me. I am aware, however, of the 7-1 ratio of Service to Combat units in the modern military, and that this is only a simple component of a far more sophisticated structure—that’s why I selected it!

In the first installment of the Wrong Way Warrior, we saw how an OOP developer put together a simple proof-of-concept using what he thought was a prudent approach to a battle simulation. He’d provide the Warrior with certain characteristics and then subclass those characteristics to concrete warriors that would share the capabilities of the parent class. In addition, the concrete warriors would be given a movie clip representation of the warrior.

After the first design was sent to the customer, the response was less than favorable. It was described as “a children’s game” at best. The military advisor described it as a caveman battle plan where all of the combatants are similarly armed with a club to attack adversaries. The problem was that it was bound to a fairly static design, and it would be impossible to be used for a simulation that had more complex behaviors. However, the other submissions were not much better, and so the customer provided a simple organization within the military to simulate—the basic infantry platoon. After all, they’re paying your company $1.5 million to develop the simulation. (This was news to the developer!) Figure 1 shows the organization in terms of a new set of movie clips:
platoon
Figure 1: Movie clip representation of platoon
Continue reading ‘Wrong Way Warrior: Getting Flexibility with Design Patterns—Part II’

  • Share/Bookmark

The Wrong Way Warrior: Where OOP Alone is Not Enough—Part I

Published on August 15, 2009 in Design Patterns and Examples. by William B. Sanders 11 Comments

In preparing for this year’s OOPSLA conference where my session will focus on demonstrating good practices by showing examples of poor practices, I was reminded of the first chapter of the Freemans’ wonderful book, Head First Design Patterns (O’Reilly). To introduce the reader to design patterns in Java, the Freemans set up an example where a developer got in trouble because his program could not be expanded or changed without taking the whole thing apart and putting it back together again. In their wisdom, the Freemans wanted to kick things off with practical reasons for using design patterns—not just because doing so is the right thing to do.

In some recent discussions, I’ve heard references to OOP and design patterns as a religion or mockingly called “doing it right” as though design patterns are some kind of moral imperative by obsessive-compulsive developers rather than practical solutions to programming problems. Any kind of programming solution should be a solution that does a good job of solving a problem and nothing more. Discussions of OOP and design patterns as the right way to get things done has no resonance with me at all; so I’m the wrong person to suggest that faith in design patterns is sufficient reason to use them.
Continue reading ‘The Wrong Way Warrior: Where OOP Alone is Not Enough—Part I’

  • Share/Bookmark

Friends with Benefits: Refactoring with Multiple Design Patterns—Part I

Published on June 16, 2009 in ActionScript, Design Patterns, Examples, Factory Method and State. by William B. Sanders 6 Comments

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:
twodps1

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.
Continue reading ‘Friends with Benefits: Refactoring with Multiple Design Patterns—Part I’

  • Share/Bookmark