For any major project, you couldn’t pull me away from classes and an external editor. Nowadays it’s Eclipse and Flex Builder. Before that it was FlashDevelop, and before that PrimalScript. In general, I hate coding in the Flash IDE.
But often enough, when I’m doing some quick experiment or proof of concept, nothing beats opening up Flash creating a new movie, slamming some code down on the timeline, and pressing Control/Command-Enter. No concern about workspaces and projects. You don’t even have to save the damn file. “untitled-1.swf”! Amen!
Half the time I do that, that’s as far as it goes. But sometimes those quick experiments pan out into something I want to develop further. Then I’m left with the task of scraping that timeline code out of the Actions Panel, and turning it into a class. With my recent Mandelbrot experiment, I realized that there are things you can do to make that conversion process easier, if and when it comes.
Most of these go back to good practices I tried to follow way back in AS1 before I was even writing classes, and everything was on the timeline.
0. All imports right up top.
1. All timeline vars right after imports. Use var, and type your data.
2. ALL code within functions. ALL code. NO stray statements on the timeline. Sometimes when you are just messing around, you’ll wind up with a mishmash of functions and statements. Gather up all those loose statements and put them into functions.
3. All the statements that are just there to set things up go into an init function.
4. Now you are allowed one statement on the timeline itself: init(); The stuff in the init function should be designed to run only once. “init” means “initialize”, which means, “set to the value or put in the condition appropriate to the start of an operation”. If you find yourself calling init() again, pull some of that stuff out into a “reset” function or something of the sort, and that’s what you call multiple times.
This leaves you with something like this:
[as]import flash.display.BitmapData;
import some.other.class;
import some.other.package.*;
var something:SomeType;
var somethingElse:SomeOtherType;
init();
function init():void
{
// body of init
}
function doSomething():void
{
// body
}
function doSomethingElse():void
{
//body
}[/as]
That’s timeline code, but hell, it’s almost starting to look like a class. Not only is it well organized and easy to read, but when the time comes to convert it to a class, there are a few simple steps to get it there:
1. Wrap the whole thing in a package statement.
2. Wrap everything after the imports in a class statement that extends MovieClip or Sprite.
3. Add indentation to taste.
4. Add private to all your vars and functions.
5. Wrap the call to init() in a constructor. (Or remove the call to init, and turn the init function into your constructor. I prefer to keep the constructor as just a call to init.)
6. You might have to add some more imports, as the IDE auto-imports a lot of common stuff.
If all goes well, you should have a working document class.
I’m using FlashCS3/FlashDevelop combination. Even when I’m doing just some little experiments with Flash I find my self opening FlashDevelop. That is just because once I got used to it’s great code hinting it’s hard go back. The thing is that it makes coding so much faster. Even though doing stuff with a class file requires always some extra coding.
But to make things bit faster I have put up a default class file with some default imports and that works fine for me. I agree that it would be so much convenient to just use the Flash AS-panel for small experiments but I guess I’m too comfortable with FlashDevelops code hinting.
I’ve been thinking if it would be possible to make an extension for Flash to make the hinting more comprehensive.
Great post, Keith. This approach to timeline coding is very close to working with classes, but still remains quick and simple. Definitely, best practices for coding in the IDE.
Just a side note: The automatic imports used by Flash CS3 are kept here:
Adobe Flash CS3//Configuration/ActionScript 3.0/implicitImports.xml
If you want to force yourself to include all the necessary imports in Flash Authoring (as would be necessary in separate class files) you could comment out the imports in that file… or, conversely, add commonly used packages to prevent the need to import most anything at all. As Keith said, “nothing beats opening up Flash creating a new movie, slamming some code down on the timeline, and pressing Control/Command-Enter.” And part of that ease comes from those automatic imports.
That is correct, senocular. But just as you press Control/Command-Enter in Flash, you can do the same from FlashDevelop by pressing F6.
Very good to know. Thanks for sharing.
The way you describe how to add code in time line is just exactly the way do it here. We use a comment layout such as:
//——————-
// INCLUDES – IMPORTS:
//——————-
// PARAMETERS:
//——————-
// ACTIONS:
init();
//——————-
// FUNCTIONS:
function init() {
}
//————-
// ‘Public’:
//————-
// ‘Private’:
As you will notice we also add public and private divisions for functions. Obiously they will not affect when compiling but it makes the process easier if you want to make all that code a class.
Reading this make me thing about that:
We really had to do the switch, but i’m still missing things that could be done in Director/Lingo as far as quick prototyping is concerned.
– Live interpreter
– List/Property List
– Castlib for media management
With the richness of the api and also controls/components of flash/flex you can really build advanced application way faster… but when we talk about starting a quick project to just test a simple algorithm… flex is a real pain! 😉
We need rapid prototyping abilities! I wish there was a live interpreter at least in the developpement environnement and also that JSFL would be integrated using actionscript without having to f* with having to handle complex quotes excaping to be able to pass commands through mmexecute! (just like you where able to create window tools in Director using Lingo).
@ Eric:
Wait for Thermo buddy!
When you say “all code” needs to be in a function, why not put the vars into the init() function?
(Newb question I know!)
if you put the vars in the init function, they would be local to that function. other functions wouldn’t be able to use them.
Thanks KP. That makes sense!
Hi Keith,
I’ve been putting off getting into class-only development for years – I’m a timeline junkie! But having come back to Flash from a break in PHP I’ve bitten the bullet.
What you described is verbatim what I do, so that’s a good start!
What I DON’T understand though, is why I’ve had to wrap some functions in my init with Delegate to make them work:
// set 2 button handlers
// Buttons are on the timeline
// Handlers (prevImage, nextImage) are in the class
public function initialize(path:String, files:Array, name:String){
btn_prev.onPress = Delegate.create(this, prevImage);
btn_next.onPress = Delegate.create(this, nextImage);
}
The delegate thing was guesswork, really, but it worked.
Can you explain why?
Thanks,
Dave
ps. Is AS2.
just the explanation I was googling for. I’ve been watching AS from middle range for some time – I get as far as functions. One of the most frustrating things for a newb like me is how do I get all (nested) movie clip actions A) on the first frame and B) initialized properly.
Even understanding root and relative paths, sometimes stuff seems to not work until you past the code directly in the clip.
That’s when I wave the chicken.
Syntax aside (that’s sinking in – i went to art school) it would be awesome if there was a book as clear as your explanation, with a sort of diagram/flow chart based decision tree schematic for visual peoples.
Also, decompiling scripts sheds light on things – I wish Flash had that built in.