Recently I had a conversation with a few members of my team about Flash and we all agreed that there are a thousands of ways to do something in Flash and only a few to do it right. Unplanned and poorly organized Flash projects can dampen productivity and really make life difficult for the developer that inherits the code after you write it.  Below is an introduction to best practices when developing Flash.  It will make your life easier and your Flash developer friendships last longer.

Create classes for every object

Procedural, function-based, timeline code has been a bad practice ever since I can remember, yet I still find it in many projects I come across from other developers. It’s really hard to keep track of as your application grows, and a nightmare to come back to after long break, if there are upgrades or changes that need to be made after launch. Do yourself a favor and follow the Object Oriented Analysis and Design principles of encapsulation and modularity. You really should understand all of the concepts of OOAD so put in the reading time. It’ll save you countless hours of future FLASHtrations.

What I like to do is set up my objects in Flash and use frame labels and instance names for the various movie clips that are contained within, then link them to an external ClassName.as file through the object properties screen in the library. You can reference them in your as file by doing something like this:

package com.library.ui{
 
	import flash.display.MovieClip;
	import flash.text.TextField;
 
	public class TextInput extends MovieClip{
 
		protected var _txtInput:TextField;
 
		public function TextInput(){
			super();
			_txtInput = TextField(this['txtInput']);
		}
		public function getText():String{
			return _txtInput.text;
		}
		public function setText(s:String):void{
			_txtInput.text = s;
		}
	}
}

Notice in the above code that I’m simply linking to an existing TextField object, TextField(this['txtInput']), within the movie clip, rather than creating one dynamically via new TextField(). This allows me to leave the text formatting, positioning and other design related properties completely separate from my logic and allow me to focus on what I do best, while letting a Flash designer/Animator worry about the rest. Simple, clean, and elegant.

Leverage “the Flash way” of getters and setters

If you notice above, I created a getText and setText which follows standards for coding Class property accessor methods. Flash’s standard TextField and many other objects don’t follow this standard, and in the interest of keeping your objects interchangeable with the ones in Flash, you should adopt the flash way of writing these methods. Let’s look at what the above code would look like with these changes. I will also add some other TextField methods I plan on using:

package com.library.ui{
 
	import flash.display.MovieClip;
	import flash.text.TextField;
 
	public class TextInput extends MovieClip{
 
		protected var _txtInput:TextField;
 
		public function TextInput(){
			super();
			_txtInput = TextField(this['txtInput']);
		}
		public function get text():String{
			return _txtInput.text;
		}
		public function set text(s:String):void{
			_txtInput.text = s;
		}
		public function get restrict():String{
			return _txtInput.restrict;
		}
		public function set restrict(s:String):void{
			_txtInput.restrict = s;
		}
		public function get maxChars():int{
			return _txtInput.maxChars;
		}
		public function set maxChars(n:int):void{
			_txtInput.maxChars = n;
		}
		public override function set tabIndex(i:int):void{
			_txtInput.tabIndex = i;
		}
		public override function get tabIndex():int{
			return _txtInput.tabIndex;
		}
	}
}

What this allows you to do is use this class just like you would any standard flash TextField inputs:

...
import flash.text.TextField;
import com.library.ui.TextInput;
...
var tf:TextField = new TextField();
tf.text = "foo"; //sets the TextField's text to "foo"
 
var myTextInput:TextInput = new TextInput();
myTextInput.text = "bar"; //sets the encapsulated TextField's text to "bar"
 
trace(tf.text + myTextInput.text); //output is "foobar"
...

Use inheritance

Object inheritance is something I love about programming. It really allows me to build well encapsulated objects that do something really well, then later when I need slightly modified versions, I can just inherit from the original and extend the functionality. Lets take our above example and extend it to be a custom number input.

package com.library.ui{
	public class NumberInput extends TextInput{
		public function NumberInput(){
			super();
			_txtInput.restrict = '0-9';
			_txtInput.maxChars = 2;
			_txtInput.multiline = false;
		}
		public override function set tabIndex(i:int):void{
			_txtInput.tabIndex = i;
		}
		public override function get tabIndex():int{
			return _txtInput.tabIndex;
		}
	}
}

Keep your code organized in packages

You may or may not have noticed the package name in the above object had several parts to it. It is split up into folders which keep related classes separate visually and programatically through packages. What I like to do is to start by creating a com folder to store all of my classes, then put a subfolder with the project name, for project specific classes, and a library folder where I put classes I tend to reuse across projects. These have subfolders to keep related elements organized like a ui, user interface, folder and similar. Here is an example:

com

• library
  • ui
    • TextInput
    • NumberInput
  • events
    • EventWithParameter
• myproject
  • ui
    • CustomTextInput (inherits from com.library.ui.TextInput)
    • CustomNumberInput (inherits from com.library.ui.CustomNumberInput)
  • Main (document class for myproject)

Keep your object library organized

Your library should be even more organized because objects often have numerous nested graphics and movie clips that can quickly create an unmanageable mess. How these are best organized is strictly a judgment call, but I can show you what’s helped me in the past:

Library

• UserInterface
  • Inputs
    • mcTextInput
    • mcNumberInput
  • MyCustomButton
    • mcMyCustomButton
    • Bitmaps
      • bg_idle.png
      • bg_hover.png
• Background
  • Bitmaps
    • background.png
    • office.png
  • mcFooter

This one will be greatly be appreciated by anyone that has to reuse or modify your code because it will save them lots of time figuring out which pieces go together.

Conclusion

Well, there you have it. This isn’t meant to be a comprehensive list but hopefully the suggestions here will help you on your way to becoming a better Flash developer. Good luck!