ActionScript 3 Tip of the Day

[oybrator]

I apologize in advance if this seems horribly out of place, but here it goes:

Would it make sense to start learning ActionScript 3.0 without knowing 2.0?

I am a fairly experienced ActionScript developer and I've been working with flash since version 3. When ActionsScript 2.0 arrived I sort of missed the point and went on developing with 1.0, after all it gets the job done and I'm already fluent in it.

Now I'm sweating a bit over having not kept up with the evolution and have decided I'm well overdue for catching up. I know a few basics of AS 2.0, but have never built anything with it. Should I make an effort to learn it and use it before progressing to 3.0 or would it be just as sensible to go straight to 3.0?

Any opinions with be greatly appreciated :-)

Thanks!

[icio]

If you're fluent in AS 1.0 it will only take a couple of days to learn what you need to do differently for AS 2.0

You've still got time before AS 3.0 is released with Flash 9 so I would take the time you have to catch up

[oybrator]

Originally Posted by icio

If you're fluent in AS 1.0 it will only take a couple of days to learn what you need to do differently for AS 2.0

You've still got time before AS 3.0 is released with Flash 9 so I would take the time you have to catch up

So by that you mean that learning stuff that's "wrong" in terms of AS 3.0 is still the right way to go because it would be easier?

Thanks for your reply by the way!

[icio]

Yes... I think that's what I'm saying.

The thing is, with learning AS 3.0 you pretty much learn all you need to know that's different from between AS 2.0 and AS 1.0.

Learning AS 2.0 would more acustom you to how AS 2.0 defines variables etc. Also, if you learn AS 2.0 you're going to be a more experienced developer

AS 3.0 isn't going to be mainstream for a while yet... you could probably do both

[theHollow]

I'm guessing it is, but is AS 2.0 still going to be supported when AS 3.0 becomes mainstream?

[senocular]

Originally Posted by theHollow

I'm guessing it is, but is AS 2.0 still going to be supported when AS 3.0 becomes mainstream?

Yes. AS3 represents a roadblock in terms of backwards compatibility. The only thing that can play AS3 is Flash 9. AS2 is essentially AS1 so even Flash Player 6 can play movies creates with AS2. Since the Flash player, as of 9, contains the VMs for both AS1/AS2 and AS3, AS1/AS2 will continue to be completely supported. And, really, AS1 will probably continue to be easier to use for designers since you have things like getURL("url string") and not navigateToUrl(new UrlReqest("url string")) and on events and things like that. But most importantly if that if you want to shoot for any earlier versions of the player, you'll be using AS1/AS2.

[senocular]

In ActionScript 1 and 2, when you convert String values into their number equivalents using Number(), if the number was preceded by a "0", the value would be interpreted as an octal value (base 8) much in the same way a preceding "0x" means hex (base 16).

// ActionScript 1 and 2
trace(Number("010")); // 8 
 

This could often cause problems for 'normal' values that, more often than not, you'd rather stay decimal (base 10). In ActionScript 3, this is no longer the case. String values with preceding "0"s are no longer treated as octals (though "0x" still means hex).

// ActionScript 3
trace(Number("010")); // 10 
 

If you want to interpret a string as an octal, you would then use parseInt specifying a radix of 8

trace(parseInt("010", 8)); // 8 
 

[senocular]

Garbage collection (GC) is the automatic process in Flash that removes variables from memory when they are no longer needed. There are two processes that handle garbage collection in Flash, reference counting, and mark and sweep.

Reference counting is a process that keeps track of all the variables referencing an object in memory. When a new reference is created to point to an object, its reference count is updated and incremented by one.

var a:Object = new Object(); // new Object in memory given reference count of 1
var b:Object = a; // Object now has reference count of 2 
 

When ever there are no longer any references pointing to an object in memory, that object is purged from memory and permanently forgotten by the player.

delete a; // Object has reference count of 1
delete b; // Object has reference count of 0, removed from memory 
 

Note: remember, the delete operator only removes variable association, it does not delete objects in memory, the GC is responsible for that. Also delete will only work on non class member variables.

There are certain times when reference counting does not work. For example, if you have two objects that reference themselves but reference nothing else, they remain to have a reference count greater than 0 but they are in no way accessible to you, the programmer, so are in all other means as good as gone.

var a:Object = new Object(); // reference(a) count 1
var b:Object = new Object(); // reference(b) count 1
a.b = b; // reference(b) count 2
b.a = a; // reference(a) count 2
delete a; // reference(a) count 1
delete b; // reference(b) count 1 
 

Here both a and b are removed from the current scope so are no longer accessible. b is accessible from a and a is accessible from b, but since you can never get to a or b there's no way to get to b or a. These objects are as good as deleted from the programmer, however, they will remain in memory because they still contain a reference count greater than 0. This is where mark and sweep comes into play.

Mark and sweep is a process that scans all references and object from a base location (such as the root or stage scope) and marks each one found. All of those not found are inaccessible and are therefore deleted. Given the example with a and b, since a and b are no longer accessible from any object path derived from root, they are not marked and eventually get garbage collected.

[root] <- scan...
     [objectRef (marked)] <- scan...
          [objectRef (marked)] <- scan...
          [objectRef (marked)] <- scan...
     [objectRef (marked)] <- scan...
     [objectRef (marked)] <- scan...
...
[delete all objects not marked]

Mark and sweep is a more expensive process compared to reference counting so it takes longer and is performed less often. In fact, provided little or no activity in your movie, many frames could elapse before mark and sweep kicks in. What this means is that you could potentially have variables in memory for a long time after you assumed them to be gone. For objects that have actions associated with them, such as events coming off of enterFrame events, this could be something to be concerned about since those events could still operate after the object should technically be deleted. You should always make sure you "cleanup" your events for situations where they might remain in memory longer than you want.

[oybrator]

Originally Posted by icio

Yes... I think that's what I'm saying.

The thing is, with learning AS 3.0 you pretty much learn all you need to know that's different from between AS 2.0 and AS 1.0.

Learning AS 2.0 would more acustom you to how AS 2.0 defines variables etc. Also, if you learn AS 2.0 you're going to be a more experienced developer

AS 3.0 isn't going to be mainstream for a while yet... you could probably do both

I'll take your word for it – I've allready started reading "Essential ActionScript 2.0" (Moock) for the second time and I'm enjoying it!

Thanks!

[jeromeribot]

Here's a little something our resident Chris came up with:


http://www.flashcodersbrighton.org/wordpress/?p=9


thought i'd inform




Jerome

[senocular]

If you want a reference to exist for an object that will not be counted towards the reference count used by the Garbage collector, then you can use a weak reference. Weak references are ignored by the reference counter and can exist even if the object is deleted.

You can't use weak references anywhere, however. There are only two places you can use weak references in ActionScript 3. One place is with Dictionary objects. The Dictionary constructor allows one optional parameter that specifies whether or not keys within the instance are weak references or not. False is the default value which means strong references. If you pass true, the Dictionary instance will use weak references

var dict:Dictionary = new Dictionary(true); // use weak references as keys 
 

If you do this for Dictionary instances, the keys you use to store values will not be counted towards that object's reference count.

var obj:Object = new Object();
dict[obj] = true;
delete obj; // obj can be garbage collected since the dict reference isnt counted 
 

The EventDispatcher's addEventListener is the other place you can specify weak references. addEventListener has a parameter that lets you specify the listener reference as being weak (since listeners internally require a reference to the object they are listening to).

// addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void 
addEventListener(MouseEvent.CLICK, clickHandler, false, 0 true); // use weak references 
 

For addEventListener, the default is also false, using strong references, though it's good habit to use weak listeners to help with garbage collection.

[senocular]

Flash 8 let you load bitmap information from the library using a linkage ID and the BitmapData.loadBitmap() method. This is no longer the case with Flash 9 and ActionScript 3. Now, as with timelines and movie clips in the library, Bitmaps are associated with classes. If you do not specify a specific class to be related to your bitmap in the library, you can name one which will be created automatically when publishing the SWF.

Classes associatated with bitmaps in the library are subclasses of BitmapData (flash.display.BitmapData). These are then instantiated as instances in ActionScript using the new keyword. As BitmapData instances, before being able to be seen on the screen, they would need to be associated with a Bitmap (flash.display.Bitmap) instance which is a display object capabale of being added to a display list (BitmapData instances cannot be added to display lists).

A side effect of extending the BitmapData class is, since the BitmapData class has two required parameters (width and height) for instantiation, so will bitmaps created from the library. Unlike direct BitmapData instances, however, the height and width has no bearing on the size of your library bitmap. It will always be created at its original size. So for instantiation, you can just pass 0's.

As an example, lets say you imported a bitmap of Rome in your library. In the linkage dialog for that bitmap, give it a class name of RomeImage - note that you don't have to create this class yourself; it will be created automatically. Then, to display it on the screen in ActionScript, use:

// create instance of RomeImage bitmap data
var romeImageData:RomeImage = new RomeImage(0, 0);

// create a bitmap instance that references the RomeImage instance
var romeImageBitmap:Bitmap = new Bitmap(romeImageData);

// add the new bitmap to the display list
addChild(romeImageBitmap);

[cahlan]

Originally Posted by senocular

Using ActionScript 3 you can now obtain sound spectrum information from audio played through Flash. This lets you create visualizations like those seen in popular in media player applications. The class that provides this information is the SoundMixer class (flash.media.SoundMixer). It's computeSpectrum method (static) places sound spectrum information in a ByteArray instance which can then be used to generate a visualization.

FYI ...

There are some cool examples of this here: http://www.gotoandlearn.com/forum/viewtopic.php?t=3175

[senocular]

The typeof operator lets you determine the basic type of any value. Note that this does not give you actual class association information, but only provides a simplistic indication of the type of variable its used with. For more information regarding specific class relation, use instanceof, getQualifiedClassName, or describeType.

In ActionScript 1 and 2, typeof returned the following values:

• boolean
• function
• movieclip
• null
• number
• object
• string
• undefined

In ActionScript 3, typeof returns:

• boolean
• function
• number
• object
• string
• xml
• undefined

Notice that MovieClip instances are, in AS3, no longer recognized by typeof. They are now seen as objects. Additionally, there is no null value (also seen as an object) and xml is seen as being of type xml.

The new number types in AS3, int and uint, when used with typeof both return number.

Also, primitive values (boolean, number, and string) created with their constructors and the new keyword are now recognized as those primitive types by typeof and not as objects as they were in AS1 and AS2.

// AS1 & AS2
trace(typeof new XML()); // object

trace(typeof my_mc); // movieclip

trace(typeof null); // null

trace(typeof true); // boolean
trace(typeof 1); // number
trace(typeof ""); // string

trace(typeof new Boolean()); // object
trace(typeof new Number()); // object
trace(typeof new String()); // object 
 

// AS3
trace(typeof new XML()); // xml

trace(typeof my_mc); // object

trace(typeof null); // object

trace(typeof true); // boolean
trace(typeof 1); // number
trace(typeof ""); // string

trace(typeof new Boolean()); // boolean
trace(typeof new Number()); // number
trace(typeof new String()); // string

trace(typeof int(1)); // number
trace(typeof uint(1)); // number 
 

[senocular]

Like ActionScript 1 and 2, ActionScript 3 has a getBounds() (flash.display.DisplayObject.getBounds()) method for determining the bounds of a movie clip (display object) in the coordinate space of any timeline. In ActionScript 3, however, getBounds has changed to return a Rectangle (flash.geom.Rectangle) instance instead of a generic object with the properties xMin, xMax, yMin, and yMax.

ActionScript 3 also adds an additional method similar to getBounds called getRect() (flash.display.DisplayObject.getRect()). The getRect() method works just like getBounds except it doesn't take into consideration strokes on shapes.

The following example shows the differences between the rectangle shape returned by getBounds and that returned by getRect.

var sprite:Sprite = new Sprite();
sprite.graphics.beginFill(0x999999);
sprite.graphics.lineStyle(10, 0x333);
sprite.graphics.drawCircle(100, 100, 50);
sprite.graphics.endFill();
addChild(sprite);

addChild(createRectShape(sprite.getRect(this), 0xFF00FF));
addChild(createRectShape(sprite.getBounds(this), 0xFF0000));

function createRectShape(rect:Rectangle, color:uint):Shape {
    var rectShape:Shape = new Shape();
    rectShape.graphics.lineStyle(0, color);
    rectShape.graphics.drawRect(rect.left, rect.top, rect.width, rect.height);
    return rectShape;
}

Running the above script draws a circle with a stroke of 10 px with two rectangles around it, one which fits to the vector shape of the circle (getRect) and the other which fits to the bounds of the whole object including the stroke (getBounds).

The rectangle returned by getRect relates to width and height values associated with the display object (which doesn't account for strokes) while getBounds returns a rectangle associated with the visual boundaries of the display object. Note that filters are not accounted for in either method.