Ultrashock Tutorials > Flash MX > Getting your hands dirty: the practical approach  
 
by Peter Elst, peterelst.com

 
 
Getting your hands dirty: the practical approach
 
For many Flash developers there’s no greater pleasure than simply being able to start coding and not having to worry about the bigger picture. I myself have been the victim of this primal urge many a time, but as I tried to show you in the introduction article it’s important to resist this temptation and get yourself (and your client) a better idea of what exactly it is you’re trying to accomplish.

Flash MX Most Wanted Components

Peter Elst is
co-author of
 Flash MX 
 Most Wanted 
 Components 

 Check it out 
 at Amazon! 
Another important point when tackling a Flash MX project is of course the way you as a designer or developer work. There are some easy tips can help you work much more efficiently which will not only benefit yourself but the entire team you’re working with.

In this article I’ll give some more practical insight into Flash MX projects and discuss a few commonly used tactics for good Flash MX housekeeping.


Working with layers

When doing any kind of work with the timeline in Flash it is absolutely essential that you make effective use of layers to separate your content.

The first thing I would advise you to do when you start a new Flash project is add an “ActionScript” layer and lock it. Make sure you only use this layer for code purposes. If you’re using frame labels in that particular timeline you might also want to add a “Labels” layer when you start.

The very next thing you do is add a layer for each object you use in your project. Any object you use and want to be able to manipulate independently on the stage should have its own layer in your Flash project. This may result in quite a lot of layers in your timeline but that’s exactly where the new Flash MX layer folders feature comes in very handy. Using layer folders you can group specific layers and collapse them when not needed which results in a generally much cleaner and easier to use timeline.

 

Managing your library

The library panel could be seen as the hub for most Flash projects and can become rather cluttered if you’re not careful with it.

In my own experience I tend to use library folders quite a lot to manage my symbols. For each movieclip that contains other nested symbols I usually create a separate library folder which I give the same name is this initial movieclip. This approach makes it very easy for me to search for a specific symbol.

There are people that prefer working with a naming convention; generally this is done by giving a nested symbol a prefix that refers to its parent symbol.

Let’s take for example a movieclip named “menu” that has three nested button symbols. The folder approach to maintaining your library would have a folder named “menu” that holds all symbols used: menu, item1, item2, item3. The other approach would not use a folder but simply prefix the names: menu, menu_item1, menu_item2, menu_item3.

These are just two basic methods to managing your Flash library, there are no doubt various other approaches around. What method you choose to manage your library is not really very important as long as you use it consistently.

It may seem like a lot of work to manage a library but if you make a habit of doing it immediately after you create a symbol it really doesn’t require much of an effort. I’m sure you’ll be glad you did it when you’re extending a project or working with multiple nested symbols.

 

Naming conventions

Anyone who has worked with Flash for a decent amount of time and has some experience with ActionScript will probably have picked up on some sort of a naming convention for symbol instancenames, variables, …

Using naming conventions is a good way to work as it helps you identify what type of object you’re working with and makes your code much more readable for a fellow developer.

Macromedia has developed its own set of ActionScript naming guidelines which makes use of suffixes to define the type of the variable or instancename. The code-hint feature in the ActionScript panel also works with these naming guidelines which may be an additional reason for you to use them.

If you want to learn more on the ActionScript coding standards and naming guidelines you can read the following PDF document:

http://www.macromedia.com/devnet/mx/flash/whitepapers/actionscript_standards.pdf

 

Using external code

Keeping your ActionScript code in external files is always a good idea when working with multiple developers on the same project or doing any kind of versioning. It allows you to quickly update a particular piece of code on all machines without having to work with multiple FLA files and having to cut and paste code.

The enhanced OO functionality in Flash MX allows you to reference most anything from the comfort of the main timeline and it is therefore becoming more and more common to see an entire Flash application run from a single frame in the timeline.

An external ActionScript document is just a plain text document and typically has the extension “.as”. The external code can be included in your Flash project as such:

#include “myCode.as”

Note that there is no semi-colon at the end of this statement and that Flash assumes the file “myCode.as” to be situated in the same folder where the FLA file was saved.

A mistake that is often made is that the external code is thought to be actively linked to the published Flash movie. That is definitely not the case, the external code is simply compiled into the SWF and any changes you subsequently make to the external code will not be reflected in the SWF until the Flash movie is published out again.

My favourite ActionScript editor at the moment is Scite|Flash which has some very nice features and is available free of charge: www.bomberstudios.com/sciteflash
Alternatively you could go for Dreamweaver MX which also does a great job at editing the external ActionScript files or your own text editor of choice.


Commenting your code

If you’ve ever had to work with another developer’s code and had to deal with dozens of uncommented functions you realise the need for commenting your code.

Many of us have had experience with these types of situations and preach the art of commenting your code but surprisingly little Flash developers actually do it. I’ve caught myself multiple times just delivering code without having added any form of comments and I repeatedly have to force myself to set down and do it.

Adding comments is a very simple thing to do and it good commenting really doesn’t take a lot of time.

Writing a single-line comment in ActionScript can be done by starting the line with a double forward-slash.

// This is a single line of comment

If you need more than one line to comment you can use the following syntax:

/* This is a comment with
multiple lines of text */

Good comments basically just describe what a particular function does, they don’t need to explain the code.

 

Summary

The points I raised in this article should help you get started with the more practical aspects of working with Flash MX projects. You can see that it isn’t the case of following complex procedures or conjuring up a magic spell that will help you to successfully develop a Flash project. A few basic ground-rules and some good old common sense are the main ingredients for the cake and experience is the whipped cream. Enjoy!

 

 
©2003 Ultrashock.com - All rights reserved