Category: ActionScript

Pre-ActionScript 3, Flash could use setInterval. This method allows you to have a function called at a recurring time frame. So, you could have a “hello” function called ever 3 seconds.

setInterval(hello, 3 * 1000);
setInterval(someScope, "hello", 3 * 1000);

Both forms invoke the function “hello” every 3 seconds. I personally always used the 2nd form to avoid any weird scope issues and EXTREMELY easier to debug; there is no confusion over what scope the function is being invoked in.

You can stop the interval from calling your function over and over by clearing it. All intervals created return ID’s, which are a unique number identifying the interval. If you want to clear an interval, you have to keep the number around to clear it later. This number is returned when you call setInterval.

theID = setInterval(this, "hello", 3 * 1000);
clearInterval(theID);

Intervals are dangerous. If you forget to clear one, it can continue running in the background, leading to memory leaks and performance issues. Since there is no visual indication for intervals that do not call GUI related functions, and the API for them is small, they are hard to track down.

The 2 main ways to ensure in ActionScript 2 that you never have problems is to always call clearInterval right before you call setInterval with the same ID, or use Kenny’s interval management class.

Flash Player 8 introduced the setTimeout function. Most uses of setInterval were really for delaying the calling of functions. Because Flash is all about events, and programming in it is very asyncronous in nature, one tends to adopt the calling of functions in a similair fashion; you wait for other things to happen before you yourself call functions rather than immediately. Such as waiting for the screen to refresh, giving a CPU intensive operation additional time to cool down, or launching a hyperlink when your content is loaded. There are some issues in using it in a class, and it was mysteriously not documented, but Guy has some good info on it’s usage in the comments. You can also clear a timeout just like clearInterval via clearTimeout.

As of Flash Player 8.5, and thus ActionScript 3, setTimeout is relegated to being depreciated already. Damn… that function only lasted HALF a player version. That’s a first.

Both setInterval & setTimeout were moved to the flash.util.* package.

The new class to use for both use cases, repeatedly called functions and post-poned one shots, is the Timer class, also defined in the flash.util package. Both intervals and timeouts tended to pollute your class in their usage, more so intervals than timeouts. You usually had to not only keep a property that held your interval id, but also all the management code for making sure the interval was cleared, mixing both the function that’s run and the interval management in one.

Now that Timer is it’s own class, this is a lot cleaner. On the flip-side, it knows nothing of your code, however, so it’s up to you to call the function, which actually adds more de-coupling; you can choose to call the function or not, and still let the timer continue running. Or, you can just do it the old fashioned way, and have the listener function BE the function you want called.

One thing I don’t really like about it however is its name; it’s not really a Timer in the general sense of the word because it isn’t timing anything, at least that it exposes to you. Rather, it’s more of a beacon, and fires off just 1 event, “timer”. Granted, you could use the Timer class to create a timer.

Here’s a code snippet example from the docs commented:

// create a timer with a 1 second
// delay, that fires twice
var myTimer:Timer = new Timer(1000, 2);
// have your onTimer function listen
// for the timer event
myTimer.addEventListener("timer", onTimer);
// unlike an interval & timeout,
// she doesn't start ticking
// until you start it
myTimer.start();
// this function will run twice,
// every second,
// starting 1 second after you call start
function onTimer(event:TimerEvent)
{
        trace("onTimer: " + event);
}

The 2nd parameter to Timer, and also a public property, is the repeat count. This allows finer grained control on how many times the timer event is generated. You can set it to 1, 20, or 4,294,967,295 times… which would take 7 weeks assuming your function took 0 milliseconds to run.

What’s special about it, though, is 2 things. First, you can set it to 0, which is infinity. Basically, it’ll keep going until you stop it.

Second, it’s a public, writable property. Meaning, you can change the speed it goes WHILE it’s going, or while it’s stopped.

This goes for the delay as well. It, too, is a public property that you can change, speeding up or slowing down the running timer.

Frankly, I don’t think setTimeout is deprecated as they say it is. It feels a lot more elegant to me to just use 1 function to make an intentionally prolonged function call. Still, Timer is a, if not aptly named, pretty bad ass new class.