Flash animations are great. Unless you are testing and you have to watch the same animation, over and over. That gets real old real quick. But, with just a smattering of code and a few frame labels you can breeze through that animation and get to the point that you are testing on.

It’s very easy. You just create a Keyboard listener that looks at the key you pressed and then does something. In the example case you see here you can press the 1, 2, 3, or 4 key to skip to specific points in the animation. (Click on the animation first to give it focus.)

Download example here.

Or you can hit the forward-arrow key to gotoAndStop on the next keyframe if you want to look very closely at what your animation is doing. And of course the back-arrow key jumps back one frame.

To jump back to the beginning of the animation hit the backspace key. If you are doing this in the Flash IDE you need to publish and then select: Control -> Disable Keyboard Shortcuts, in order for the backspace and Enter keys to work.

Another nice benefit to this approach is that you can drag those keyframes with the frame labels around and the keyboard shortcuts will still jump to them without any changes to the code.

If you are using this for testing purposes you might want to remember to disable the keyboard listener before you go public. The easiest way to do that is to comment out the last line: // Key.addListener(skipListener);

Suppose you use a loop and the createEmptyMovieClip method to create some MovieClips like so:

If you ran this code and hit Ctrl+L you would see that you have created 5 empty MovieClips.

Level #0: Frame=1
Movie Clip: Frame=0 Target=”_level0.clip_0″
Movie Clip: Frame=0 Target=”_level0.clip_1″
Movie Clip: Frame=0 Target=”_level0.clip_2″
Movie Clip: Frame=0 Target=”_level0.clip_3″
Movie Clip: Frame=0 Target=”_level0.clip_4″

Presumably you would then attach some assets or load something into these clips.

In such instances it’s pretty common that you will write code to deal with user interactions with these clips. If so you’ll need to know which clip is being interacted with. It’s probably best to dynamically create variables on the clip that will help you identify it but you know what? You already have. You have the MovieClips name clip_#. So what you really need to know is what is the index number at the end of the MovieClips’ name.

That’s easy enough to find using the split(”_”) method as such:

this._name.split(”_”)[1];

That works well enough assuming you used an underscore during the creation of the MovieClips. What if you used a hyphen or even no separator at all?

I’ve had to deal with this often enough that I created a utility class to deal with it. Here’s the general code removed from the class that you can use or you can download the Find class which has this method plus a lot of others for helping you find MovieClips by size, _alpha, position, etc.

Note that this function returns a Number not a String. So if you have a clip named clip_01 then what you will get back by calling mcIndex(clip_01) is the Number 1.

Have you ever noticed that when you use the playhead control to scrub through a video that when you release it the video plays smoothly from the frame you see however the playhead will jump, sometimes a lot, just a little bit forward.

I first noticed this when working on my videoGenerator code and it was driving me nuts. Finally, I went to youTube.com and a few other Flash video sites and tested their video. You know what? I got the same result.

That lead me to believe that maybe it wasn’t my code but something to do with Flash video. Turns out I was right.

First, a quicky on how Flash video, and many other video formats, are encoded. If you could look at the individual frames of a video stream you would notice that most of them are incomplete pictures. For sure the very first frame will be complete but the next few frames after that will only be the parts of the picture that have changed from the first. After a hand full of frames you get another complete picture and then the process starts over again. These complete frames are called key frames. The more key frames you have the larger your filesize will be. However, if you don’t have enough the video quality begins to suffer. Especially when the video content is changing a great deal during every frame, like an action scene. (You can read all about how to best choose your key frame values here.) I’m going to get on with how this affects scrubbing the video.

Very simply, when you are scrubbing over Flash video - moving the playhead around - the Flash player can only show you the key frames. It can’t show you the incomplete frames in between. Here’s a good example of how that looks. The video below is simply a white bar that moves across the video window. You can use the scrubber to move back and forth through the video and see the jumpiness. I included multiple versions with different key frame values so that you could see the effect.

Note: these videos were all encoded at 15 frames per second. A key frame interval of 15 ends up being 1 keyframe/second and a key frame interval of 5 ends up being 3 keyframes/second.

Also, to see the effect that I’m talking about here you have to move the playhead very slowly. If you move it quickly the jumpiness is a result of the Playing trying to catch up with you and has nothing to do with key frame placement.

The file sizes for these videos are as follows:

interval of 1 = 1,350 KB

interval of 5 = 351 KB

interval of 10 = 224 KB

interval of 15 = 181 KB

interval of 90 = 109 KB

interval of auto = 124 KB

You can see that having a very small interval blows up the file size but at a certain point having a very large interval does little to save file size.

Learning Actionscript is like putting together a puzzle, as are many things. You start with the obvious stuff first - the edges.

So you have a few basics down and then you need to do a project that requires you to use code that you’re unfamiliar with. So you learn just enough to get the job done. It may not be organized code and it may make a seasoned developer cry if they see it but it works - that’s what matters, right? This is like finding a few pieces of a puzzle that fit together but you don’t know where they belong in the overall picture.

So you keep adding on these little groups and sometimes you discover that they fit with a part that you know well. Like fitting a group of assembled pieces to the edge of the puzzle. More and more the picture is coming together.

Of course, those little groups of understanding fade away if you don’t use them often enough.

The real problem with learning Actionscript is that you can’t really see the big picture until you know it pretty well. When you’re starting out you might read about objects, arrays, whatever and you don’t know if that’s a huge part of the puzzle or if it’s a little part of the puzzle that’s easy to understand.

There is also room for confusion between what is Actionscript and what is really the Flash Players DOM (Document Object Model). You see, there really isn’t all that much to Actionscript. You have your variable types, if/then, for/loops, a few other odds-and-ends and your done. Maybe a few chapters of a book at best.

The Flash DOM on the other hand is huge and growing with every new release. The DOM includes things like, ._alpha, ._x, ._y, getNextHighestDepth(), XMLSocket(), the list goes on-and-on.

So Actionscript is what the language can do, like loop through an array, and the DOM is what the Player can do, like change the _alpha of a MovieClip.

My suggestion is to concentrate on understanding Actionscript first and then filling in the blanks of the Flash Player DOM as you go.

With that said here’s a general list of the things you need to learn and understand in what order.

1. Creating variables : There aren’t that many variable types in AS. Initially you should feel comfortable with Number, String, and maybe Boolean.
2. Functions and scope : First get used to creating and using functions. As soon as you feel good about creating functions you should learn how to pass parameters - variables - to a function and then later how to return a value from a function.
3. Arrays : Learn them. Love them.
4. Conditionals : Lets go loop-de-loop
• for loops : for-loops go hand-in-hand with arrays. You’ll see.
• if-then : if this then do that. The cornerstone to any language.
• if-then/else : just to cover all your bases.
• if-then/else if : the other condition
• switch/do-while/while/ : you won’t use these all that much but when you need them they really come in handy.
• Tertiary “?” operator : you could go your whole life without ever using this thing but when you learn it you’ll love it. Essentially it’s a very concise version of an if-then/else conditional.
5. Objects : Once you have everything in Actionscript nailed down solid you’ll still be learning all the in-and-outs of objects. And don’t confuse objects with Object Oriented Programming. First you learn how to manipulate existing objects. Later, you’ll create your own - that’s the OPP part.
6. Types : A String is not the same type as a Number, duhhh.
7. For-in loops : Previously you learned how to loop through a sequence of numbers, like count from 1-to-10. For-in loops run through an Objects properties. Very handy and very powerful.
8. Listeners and events : “Listen . . . do you smell something?” :-) Events are happening all the time. You just need to listen to them and do something about it.
9. Object Oriented Programming : You know about using objects now get ready to create them.
10. Design Patterns : An extension of OOP. If you get this far you are now an Actionscript guru.

I had the question posed to me:

First and foremost the user should have a good experience. If you always make your decisions based on that then you’ll get it right most of the time. Another thing to keep in mind, and this applies to any user input, only ask what you need to know. If there is something that you want to know but is not essential to the task then don’t ask.

For instance, if you’re working on a site for an online grocery store then resist asking for things like the users favorite vacation destination just so you can target ads to them. I know, I know, you would never do such a thing but believe me, someone in marketing will ask for something equally inappropriate. I find it useful to carry rubber bands with me to meetings like this so that I can shoot people for asking for things like that. :-)

With that said here are a few suggestions:

If the site is all HTML then stick with HTML forms. Conversely, if your site is all Flash then do the forms in Flash.

Go with what you know. If you’re comfortable with one or the other then go with that. You’re more likely to create something that the user likes if you like what you are using to create with. Basically, if you can’t stand working in HTML then by all means, don’t use HTML to create your forms. You’ll be more likely to cut corners just to get it done.

Flash is obviously more expressive that HTML. If you want to create something that goes beyond the typical experience that people have with HTML forms then there’s your answer: Flash.

Advantages to Flash forms:

• You can control the font.
• Both Javascript and Actionscript are equally adept at client side validation. However, in the Flash environment you have more options for providing feedback to the user.
• I would give Flash a slight nod when it comes to maintaining state with the use of Local Objects.

The only intrinsic argument I can think of against Flash forms is the old, “What if they don’t have the Flash player?” cliche. We’ll when you’re doing something that is leveraging the browser DOM heavily your more likely to find people who have browsers that aren’t up to snuff but do have the Flash player.

I think that if you say to yourself, “I want to create the perfect user experience for using my forms.” then you’ll want to go with Flash because of all it offers. But believe me, the Flash part will be easy. The UX (User eXperience) work will be the most time consuming part.

If you do go with Flash then keep in mind what version of the player you are publishing for. If you’re not using anything that requires the latest player then don’t publish for it. Go as low as you can. For a project like this that will likely be version 6 or 7, depending on the code.

Last thoughts, just about anything you can do with Flash forms you can do with HTML/Javascript. However, if you’re really going over the top and manipulating the interface as the user progresses through the forms then the HTML approach is going to become more and more problematic.

With HTML you’re going to have to test in multiple environments. My biggest concern would be how my perfect forms are going to work on browsers in 2-3 years down the road that aren’t even out yet. I’d be in a “Here’s Johnny” mood if I had a bunch of HTML/Javascript that IE7 just took a crap on. With Flash, you’re just about guarantied that what works now will work later.

I would have to say that getting my head around how listeners work in Actionscript might have been the toughest aspect of AS for me. But, once you get used to it, just like everything else, it’s simple to use.

To create a listener you need three things:
1-you create an object - new object().
2-you tell that object what to do when an event happens - event handler.
3-you get the object to listen for the event - addListener.

Here’s a real world analogy: suppose you want to make a phone ring when someone calls you.

First, (#1) create a phone.

var myPhone:Object = new Object();

Next, (#2) tell it what to do when a phone call comes in

myPhone.onCallRecieved = function():Void {
makeTheRingSound();
}

And finally, (#3) tell it to listen for an incoming phone calls.

phoneNetwork.addListener(myPhone);

This last part, (3) might be the most confusing aspect so I’ll go into it with a little more detail.

Think of it this way: there’s a phone network out there that everyone is connected to. If someone uses their phone to dial your phone number then your phone will ring. Obviously you have to have a phone, the object (#1) and your phone must know what to do when it receives a phone call (#2). But there’s a little more to it isn’t there. You can’t just buy a phone and turn it on. First, to get it to work you have to register it with the network and tell it what your phone number is. That way when someone dials your number the network can determine who is listening - your phone - and send you the message.

If you hadn’t done this last step then when someone dialed your number the network would still get the event but it wouldn’t know who to tell. Once you register with the network then it will know to broadcast an event to you when your number is dialed.

So once again, you have the object - phone - the thing in your phone that acts when it receives an onCallReceived event and finally you tell the network to let you know when someone dials your number.

General form of a listener:

Here is a very simple example of a listener in Actionscript. Use the arrow keys on your keyboard to move the ball up/down, left/right. The longer you hold down a key the faster/slower it will move. So holding down on the right-arrow for a few seconds will make it move right and then holding down the left-arrow for a few seconds will slow it back down. At any time you can hit the spacebar to stop the ball and return it to the center. (Note: you must click on the SWF - black square - to give it focus so that it receives the keyboard input.)

Here’s the code that makes this all work (download zip)

Here is what’s happening above. An object is created - listener. And that object is told what to do if it gets an event called onKeyDown. And finally we tell the Key class to notify our listener when the onKeyDown event happens.

Suppose you had a Flash movie that doesn’t have any of this code. What happens when we press a key then? Well, the Flash player knows that a key was pressed and it - the Key class - looks to see if any objects need to be notified. If there are no listeners then obviously it doesn’t send any notifications.

The onKeyUp is the other event that the Key class can notify an object about. Since our listener is receiving all the events that pertain to the Key class then it gets those notifications as well. However, we don’t have any code that tells our listener what to do about it so nothing happens.

You might ask yourself, “why don’t mouse events work the same way?” That’s because the Flash developers thought that it would be so common to have mouse events associated with MovieClips and buttons that they made it simple to use. Basically, things like MovieClips automatically listen for mouse events so all you need to do is supply the code for what you want to happen, as such:

myClip.onRelease = function():Void {
// do things when someone clicks and
// releases the mouse on this MovieClip
}

That’s the #2 part of our example above. Steps #1 and #3 are done for us to make our life/coding simpler.

There are all sorts of other classes that broadcast events that you might want to listen for. If you’re using the movieClipLoader class you might want to know when something has completed loading, or with a video that is streaming into your movie you might want to know when it has completed playing. You can also use a listener to tell when the stage has changed size, or when a webcam has changed it’s status. The list goes on and on. In fact, that’s what you want to look for in the Flash help files - on. Pick a class in the Actionscript Classes folder and look for methods that begin with on. Those are the events that it broadcasts so that you can write code to manage what happens when the event is triggered.

If you’re into Yahoo mashups this is the place to go: Flash Developer Center

I can’t stand books and tutorials that try to cover a huge project. I usually end up spending most of my time debugging because they weren’t clear about something or another. (Or perhaps because I’m stupid and can’t follow directions, but enough about me.)

What I like are books and tutorials that cover one simple thing, like: here’s how you load XML into Flash. It shouldn’t take more than a few lines of code to do that. What I don’t need is something like, “here’s how you load XML into Flash and make an MP3 player that can randomly select songs, and display album art, blah, blah, blah”.

With that in mind one of the best resources for learning Flash are the built in help files. They give you the essentials of a method/property and a very short example of how to use it. And it’s always something that you can copy/paste the code into an empty FLA and it will work.

One of the most useful features in the Actionscript editor is the ability to right-click on a keyword and select “view help” at the bottom of the menu. It will take you straight to the Flash documentation on that keyword. Invaluable. It’s something I do many times a day.

I try to follow that advice myself here on my blog. My primary interest in putting up Flash code here on my blog is for my own personal use. You have no idea how many times I’ve been writing code and realized, “hey, I wrote some code last year that does just what I’m trying to do now. Humm, where the frak is it.” Now I’m starting to load this stuff up on my blog so that I’ll have a reference to my own code to use. If it helps others then so much the better.

It’s also good to think about large projects as lots of little projects. I know that for myself I’ve gotten projects handed to me and thought, “Whaahhhh? Man, that’s going to be hard.” But once I sit down and start thinking about the little pieces it becomes much less daunting.

My best friend is looking to expand his skill set as a designer and get into the Flash business. Along the way I’ve given him some advise that I thought I would share. Here goes:

First things first are the books to read. I would start with the Flash 8 Bible by Robert Reinhardt and Snow Dowd. If you’re a designer then it’s likely that you’ve read the Photoshop Bible so you know what you’re in for. These books cover just about everything without getting you in over your head. These are sort of the “wading up to your waist” approach to learning a new app. What’s great is that you can come back to these books later as a reference.

I wouldn’t suggest trying to read the entire book right off the bat. I don’t have the book in front of me so I can’t say specifically what chapters to focus on. In general you want to thoroughly read the first half to two-thirds of the book that introduces you to the essentials of timelines, MovieClips, text fields, Actionscript and so on. You probably don’t need to bother with things like how Flash handles audio/video unless you need that for a specific project you’re going to work on.

However, I would certainly suggest that you at least scan everything in the book even if it doesn’t make sense to you. Later, when you’re working on a project and trying to figure out how to tackle an unknown you’ll be much better prepared if you have a basic understanding of all of the capabilities the Flash player has.

When you’re ready to move on to the next book you have a choice to make. With most of the Flash 8 Bible under your belt you’re ready to read the following books in either order.

A. Actionscript for Flash MX - The Definitive Guide, 2nd Edition

B. Flash 8 Actionscript Bible

I would lean towards the Actionscript for Flash MX book first because it’s very concise. (note: Flash MX is really Flash 7.) The second half of the book is a reference guide which isn’t meant to be read beginning to end. The first half of the book is the best review of Actionscript around.

You might be wondering why I didn’t suggest the “Actionscript for Flash 8″ book. That’s because sadly there isn’t one. However, it really doesn’t matter that much because both MX and 8 use Actionscript 2.0. That’s the important thing. All that has changed between MX and 8 is that the Flash player has added a few more capabilities but the essentials are still exactly the same.

The Flash 8 Actionscript Bible will cover all the new capabilities of the new Flash player that you missed in the AS Flash MX book. By now you might be feeling that you’re reading the same thing over and over again. That’s good. Redundancy is a great way to learn.

These three books are really all you need if all you’ll be doing is timeline based Flash projects. But if you want to experience the full power of Flash then you’ll want to step into the world of Object Oriented Programming (OOP). These last two books gave you an introduction to OOP but there is no question that Essential Actionscript 2.0 is the book to read to get the full measure out of Flash Actionscript.

Once you have a grasp of about 75% of the material in these books then I’d say that you are technically ready to do just about anything. Because by this time if you don’t know how to do something you know where to go to get that knowledge.

How well you deal with organizing your time and your timeline while working on Flash is a totally different subject. First aim for technical understanding. Organization will come with practice, a.k.a. trial and error. I’ll write more on that later.