September 24, 2003
Class Stampede: Exporting Classes
My home slice Jesse Warden came across an issue with Flash MX 2004 Pro components adding file size to his swf's first frame even after he unchecked "export to first frame" in the linkage properties.
We looked into it a bit and concluded that every class we're using is exported to frame 1. Anyhow, he posted about it on one of the list and low-and-behold we both forgot about an additional setting in Flash MX 2004:
"Export Classes in Frame #" conveniently located in the AS2 Settings Dialog.
On the up side it resolved his issue. On the down side this means that all of your classes will always have to be downloaded in one large chunk unless you use an alternative loading mechanism.
For the most part I will probably just export to some distant frame to make headway for a preloader. However, on a large enough project you could easily have over 300kb in just class overhead exporting into 1 frame! This means that your app won't run until ALL of your classes have loaded!!
This is different then how Flash MX exported components/classes. In MX if you unchecked "export to first frame" the class that the component was associated with got initialized with the instance of the component itself. So if your component is on frame 30 then the class doesn't get initialized until frame 30 also.
Don't get me wrong, I'm not saying this is a bad change; just something to be aware of.
Posted by erikbianchi at 12:30 AM | Comments (486)
September 17, 2003
Exploiting Closures: Using Real Private Members
In Flash MX 2004 you can set private members. However this is only used for authoring. All private members become public at compile. But there is a way you can have real private members in Flash MX and Flash MX 2004!
I've seen something like this talked about before but never really thought about it:
function SomeClass(){
var privateValue = 200;
function privateMethod(){
trace("privateMethod: "+privateValue);
}
this.privledgedMethod = function(){
trace("privateMethod: "+privateValue);
privateMethod();
};
}
SomeClass.prototype.publicMethod = function(){
this.privateMethod(); // Can not Access private method Directly
this.privledgedMethod(); // Needs to use
};
a = new SomeClass();
a.privledgedMethod();
a.publicMethod();
// Fails
a.privateMethod();
(NOTE: I am using Flash MX Syntax but the same concept can be applied to classes as well)
Basically a function declared locally inside of another function has access to any other locally scoped vars of the parent function at any time even after the function has returned. Since these vars are scoped to the function itself, inside the functions closure, they cannot be manipulated outside of the function. However you can use a privileged method to access these private members.
A privileged method is just like a public method except that it is declared to the parent function itself as opposed to the prototype chain. (Applies to MX 2004 as well). Remember functions are objects too, so by declaring this.privilegedMethod inside of a function you're declaring it to be apart of the functions scope, the same scope that the local vars and functions live in.
So functions do have there own scope (like movieclip timelines). Local variables inside those functions still exist even after the function has returned. However the only way to access those members is with a privileged method. Consequently, because a privileged method is defined per instance these methods cannot and are not being inherited. So each instance of the function/class will get a copy of the privileged methods thus taking up more memory.
All this brings up an interesting question. If vars still exist after the function has returned, is this a bug inherent to the implantation of ecmascript?
At any rate I would consider this one of those cool things in theory but is not very practical until true class based private members are introduced by Macromedia.
Posted by erikbianchi at 07:29 PM | Comments (869)
September 11, 2003
Behaviors: Flash 5 Developers Rejoice!
Just when you thought onClipEvents where dead and forgotten they are back alive and kicking once again in Flash MX 2004 thanks to behaviors.
Behaviors are a new concept to Flash developers but have been around for a while in Director and Dreamweaver. Essentially a behavior is a script that you can assign to any movieclip, button or frame using a behaviors panel that is similar to using the Properties Inspector. With behaviors however, you specify the behavior and then the event that triggers it. I.e. onPress, onRelease, etc. All this is done with out the user having to write a single line of code. So say for example I have a basketball movieclip on my stage and I want it to act like a basketball. Instead of having to worry about writing a real-time physics engine in Flash or any of newton's laws of physics I could just apply a basketball behavior to my movieclip. Very Cool!
Once the behavior has been set the actionscript for the movieclip actually gets applied to the movieclip itself via onClipEvent.
For example:
onClipEvent(press){
trace("Pressed");
}
(And you thought all those years of Flash 5 programming where wasted!)
There is a downside however. If you have two movieclips that use the same behavior you effectively place 2 separate versions of the exact same behavior in memory unlike components that reference the class they belong to.
For example say you have 5 Listboxes on stage at once. Each Listbox holds a reference to its linked class. With the above example you'll have 1 class definition in memory as well as 5 references to it. Now lets say you have 5 movieclips on stage each with a startDrag behavior attached to them. Here you will have 5 separate behaviors in memory!
So then what can we do to improve memory utilization? Here is one possible solution:
When you're defining the behavior first write a behavior class. (I like to keep all my behavior classes in a behavior folder inside Flash's class folder). In the Behavior definition file inside of the Actionscript tag you can place the following code:
onClipEvent(load){
__proto__ = new classes.behaviors.theNameOfTheBehavior();
}
NOTE: __proto__ was originally undocumented in Flash 5. In MX it was documented but stated that is was a read only property, thus writing over a __proto__ was unsupported by Macromedia. In MX 2004 the documentation no longer states that it is read-only. However this could have been an oversight in the docs(?).
At any rate, If using __proto__ is out of the question It would take one hell of a behavior duplicated many, many, MANY times to have any noticeable impact on your systems memory. Video, Audio, Graphics and large Record Sets are still going to be your biggest memory hogs.
In conclusion Behaviors are a great new and powerful addition to Flash's IDE and will no doubt speed development time and cut cost. They could have been implemented better but by no means should they be avoided.
Posted by erikbianchi at 12:46 AM | Comments (223)
September 09, 2003
Tech Editing Flash MX 2004 Magic
I originally signed on with New Riders publishing to coauthor the upcoming Flash MX 2004 Magic Title. Unfortunately my project was pulled last minute (mutual decision) due to some content overlap.
However, the fine folks over at New Riders decided to add me on as a Tech Editor instead! So now I'm getting paid to read a book as opposed to writing one! (And to think of all the years I've wasted reading books for free).
Posted by erikbianchi at 07:12 PM | Comments (366)
September 08, 2003
Flash for Java Developers
For all the Java Peeps out there. There is a new book about Flash written by Java developers, for Java developers that might be worth a read (Flash developers should take note too):
Reality J2EE: Architecting for Macromedia Flash MX
PUBLISHER: Macromedia Press
ISBN: 0-321-15884-9
Via FlashMagazine.com:
As Flash moves further towards application development, we're seeing a new breed of books. These are written from the perspective of another community, introducing them to Flash. This book is one of those. It has been written by Enterprise Java developers, for other Java developers, about Flash . . .
Follow http://www.flashmagazine.com/html/833.htm for the rest of the articale
Posted by erikbianchi at 08:04 PM | Comments (247)
September 05, 2003
Welcome To My Blog!
I'm finally up and running. For the next couple of days I'll be updating and fine-tuning the default look-and-feel of my site.
I should start posting regularly starting sometime next week. Here, you can expect to find post concerning Flash related: news, projects that I am working on, rants/tangents and ideas/concepts no matter how stupid or far-fetched.
The time you spend here is probably better spent doing something else. However, if you find yourself really that bored or you're just looking for an example on how not to structure a sentence then you've come to the right place!
Enjoy!
-erik bianchi
Posted by erikbianchi at 09:18 PM | Comments (549)