Blog

To those of you that think memory management is old hat, more power to you. However, there are those of us who have never had the opportunity to worry about such things in the past. Who knows what is really happening behind the scenes, but I was trying to load 26 XML files. The process goes:

– get xml filename
– attach to existing LoadVars variable (not local)
– do a POST to PHP script
– PHP script uses the passed in filename, loads the gZipped XML file, and returns to the LoadVars callback as a variable “theXML”
– LoadVars’ callback then throws that string to the xml object via owner.my_xml.parseXML(theXML)

Now, each XML file, around 300k, was making the memory jump 20 megs every load. So, the 9th load would usually crash Flash. I thought it was the XML object, but turns out, it is the LoadVars object. Even though his “theXML” variable is reset each time, the string data in memory isn’t.

To solve it, I added a “delete this.theXML;” after I passed the string data to the XML object to parse. This doesn’t entirely solve the problem, though. Even though I can see the RAM drop about 20 megs, she still climbs to a whopping 80megs when finished. I really don’t think my nested array/objects are what is causing the significant increase, and there aren’t many components on stage nor in use. At any rate, at least it doesn’t crash now!

Chafic wrote this phat article (that he shoulda let me tech edit) on Ultrashock. He took a monumental task in writing it, so I congratulate him.

I wanted to add a few things that the V2 framework doesn’t take into account as far as Flash goes.

Authortime Components

This is the bane of the mixed group of developers we have in the Flash community and on the help lists. Some of us use authortime components, others dynamic, and some both. I try to attach everything dynamically myself, but for those gigantor forms, or intricate layout times, it?s just quicker & easier to drag and drop. The difference is, if a component is an authortime component, it is initialized (methods, not properties) a frame afterwards. The exclusion to this rule is if you drop it on _root, but even then, if your SWF is then loaded into a movie clip, you have the same problem again.

The way I typically solve this is just to implement an onLoad in my class. Thus:

public function init(Void):Void
{
        super.init();
        
        setSize(320, 240); // set a default width and height
}

public function onLoad(Void):Void
{
        my_pb.addEventListener(?click?, this);
        my_pb.label = ?Sup?;
}

Same holds true for Central components. I think Flex handles this transparently. Now, technically, one could argue you should be using createChildren to attach everything? but to me, that is not realistic to do every time. It violates OOP purism, but I?ve got deadlines to meet, and I know some of you do, too.

createClassObject/createObject prefix

This is more of an opinion because I haven?t looked at the FLASM output, but I consider it a best practice to call removeMovieClip before ever creating anything (createEmptyMovieClip/attachMovie/createClassObject, etc.). It may just so happen that the bytecode is the same for creating a movie clip in the same depth as another one (even if the same movie clip), thus deleting whatever is there, but there is one distinct case I can argue: corrupted movie clips. Sometimes, when loadMovie fails on loading JPEGS (not sure about SWFs), it?ll corrupt the movie clip. This is mega lame if you authortime dropped it because now your foobarred? unless you swap it to a positive depth and then removeMovieClip on it which is hackish… but necessarey I guess in the case of deadPreivew (talk about this later). Thus, removing a movie clip before attaching it, to me, should have been added to the createObject method (since createClassObject calls it anyway). I haven?t, however, had this problem with text fields, so I don?t call removeTextField before creating them.

Finally, and I don?t really know about a fix for this, sometimes onEnterFrame?s that are dynamically attached I believe hang around via the activation object. So, even if you delete the onEnterFrame before calling removeMovieClip, and even get a true returned value from the delete call, your onEnterFrame will still get called. I don?t really know how to fix that, even if it could, but it really just confirms you should be using doLater vs. rolling your own onEnterFrames, unless of course they are on process only movie clips (mc?s created specifically and only to generate that event for your use).

Width & Height, deadPreview, and LivePreview

You?ll notice above I called setSize in my init. I did this because, by default, __width and __height are based on _width and _height. Now, if your creating the ideal component, there really isn?t anything to base a valid _width and _height value off of, is there? Well maybe? depends on how you make things.

Back in MX, width and height were getter/setters for width and height. That is, they were NOT pointers to _width and _height values, which to me, is a failure, again, for the V2 framework to make allowances (yes, they are allowances, that?s why frameworks rock) for Flash. For example, an image is 1000×1000, however, your masking it off at 320×240. Know what width reports? 1000. Stupid. Thus, that?s why MX rocked, because no matter what you did via setSize, it always correctly reported the ?true? or ?visual? width and height; if for some odd reason you needed the true _width, you can just access it. That?s why in MX it was integral to default to something because the base class, FUIComponent, did not.

Typically, you?d put your components your using on frame 2, with a stop action on frame 1, thus having a nicely packaged component, reading for SWC exportation. However, this causes 2 problems. First, there is nothing on frame 1, therefore, width and height won?t be jack (well? 0, 0) because there is no physical element on frame 1 for it to get bearings on what _width and _height will be. Second, because there is nothing on frame 1 (aside from a stop action), your LivePreview for your component won?t work. LivePreview?s, since MX, have needed SOMETHING on their stage (separate SWF in MX, frame 1 in 2004) so they can have a rect in which to draw in. Thus, in MX, deadPreview was born. If you turned off LivePreview in MX, you?d see this sketchy, or non-live component. Typically this was just the pieces of the component put together in a semblance of what the component would look like? or what you saw when you did an edit in place on components. This was done for those who turned LivePreview off in the IDE. Additionally, an automatic unloadMovie was called on deadPreview (you typically named your movie clip that) so it was removed when your component was run. However the V2 framework has removed this? as mistake in my eyes.

Because of deadPreview’s new role in as the frame 1 rect creator for SWC LivePreviews, it now has 2 roles (first here, 2nd below this paragraph). I?ll typically still use deadPreview, and call swapDepths(0), and then removeMovieClip (since removeMovieClip doesn?t work on negative depth movie clips a.k.a. authortime movie clips). I have my own base class which uses Grant Skinner?s GDispatcher, and extends UIComponent, so I put the deadPreview stuff in there since everyone uses it. Still, I shouldn?t have to, but that?s a case where inheritance rox da hizz-ouse!

Finally, a deadPreview gives your component a _width and _height that UIObject can work with, thus negating the need to give it a default width and height by calling setSize in your init. I still do so anyway, though.

Conclusion

I love Chafic?s article as I learned a lot (and now all of my classes need to be rewritten) and I love the V2 framework as well. It?s a lot easier to make my modifications without it breaking via another Flash IDE update, or some other addition since it?s nicely encapsulated. I?m a guy that likes to use frameworks, not create them, so it saves me a ton of time. Hopefully the above will help you navigate the Flash nuances that the V2 doesn?t solve.