Why No Love for the Monostate Pattern in ActionScript 3?
A coworker of mine recently introduced me to the monostate pattern. At first I was like "wtf is that?". I had never heard of that pattern before. He is of the opinion that the monostate pattern is far better than the singleton pattern. I had no opinion on the subject because I only assumed singletons are the one and only way to ensure only one instance of an object is created throughout an application.
Just One of My Favorite Flash Tools: swffit
I just have to mention this really quickly. When working on tridentgum.com I was introduced to, what I thought might be, a little known JavaScript tool for Flash proejcts. We had to give the site a minimum height and width in the browser but still go 100% if the screen is larger than the minimum size. Something I've done before but just not so easily. At any rate, the lead developer at the other agency we were working with discovered swffit. It makes doing this sort of thing ridiculously easy. In most of my cases, I just need a minimum width and height, which is usually the width and height of my FLA's. Otherwise, the site can stretch to the size of the browser.
I recommend swffit to everyone!
Anyone Using PureMVC Multicore For Non-Flex Flash Sites/Apps?
Lately I've been experimenting with PureMVC. I'm really curious if it could aid in the development of side projects and even projects at work. In fact, I gave it a go on the project I'm currently on at work right now. All started out well, but then I ran into a dilemma. Basically, if you know anything about PureMVC, a mediator is register for a view component at runtime. Not being a total MVC genius, I figured I'd write some sort of proxy to load a section and register a mediator for the section once it was loaded.
Free ActionScript! AbstractButton
As many of you might know, when you're doing Flash everyday for a job, you find yourself doing a lot of the same things over and over. Such things include building a navigation system, a video player, a form, etc. At some point you say to yourself, there's got to be a way to improve my productivity with this. If I remember correctly, the first time I asked myself this I had no idea where to start. But, a couple days later it finally hit me. Probably the most common task I have when building flash content is making buttons.
Now, the kinds of designs I'm usually provided with at work are usually pretty graphic and the designers like fancy rollovers that the SimpleButton class just can't provide. Because of this I often use MovieClips as buttons and place assets within that MovieClip to animate and/or modify. So what I end up doing is creating MovieClips in the IDE and attaching a class to that MovieClip. Pretty standard.
So then I started to think, how can I make a class that is sorta like SimpleButton but gives me the flexibility I need for my "fancy" rollovers? Now, I'm no OOP wizard by any means, but it was then that I stumbled across what are called Abstract classes. Abstract classes are meant only to be extended and provide a code base for your more specific class. So It made sense to me to create an AbstractButton class that is always meant to be extended and would contain basic button functionality but remain ingorant to any animation or child objects needed for any effects.
I started experimenting and analyzing most of my previously made button classes and started to see some patterns in the basic button functionality. In the end I discovered my most used events and most used methods and added them to my AbstractButton class. I'm pretty happy with this class and it makes making buttons so much faster than it ever did before, especially with ActionScript 3. All I have to do now is create a class, extend AbstractButton and, in most cases, just override the onRollOver and onRollOut functions. Depending if the button is part of a nav system, I'll override the select() and deselect() methods as well. If the button just simply links to a URL, all I have to do is override the onClick method and add a navigateToUrl() call.
So in hopes of helping others, I'd like to share my class with all of you. I would certainly love to hear any comments, suggestions, or questions regarding the class.
Papervision3D Beta 1 Cube.destroy() bug?
So I've been working with Papervision3D quite a bit lately for a project at work. I've been creating controllable boxes and using Cube's with a depth of zero as the panels for the box. I used this technique in order to apply different materials to opposite sides of each box panel.
Eventually it came time to destroy these boxes, so I did a big sweep of all the PV3D objects and made sure to remove them from the scenes and destroy their materials. Eventually I got down to the box panels (cubes) and at first glance noticed the Cube.destroy() method. So taking for granted that this is still a beta version of PV3D, I assumed all would be hunky doory and the materials would be destroyed.
Now it was time to check the memory usage. Immediately I noticed the memory usage just kept going up each time I created a scene and/or boxes. For the longest time I had no idea what was causing this. After hours of banging my head, I ended up adding a method to PV3D's MaterialManager class to loop through the materials dictionary and see if anything was still left in it after my own destroy methods. Come to find out, the materials for all the box panels (cubes) we still lingering behind, even after calling the cube's destroy method. So I had to change my own destroy() method to remove the materials manually by doing the following:
_cube.materials.getMaterialByName( "all" ).destroy(); _cube.materials.getMaterialByName( "front" ).destroy(); _cube.materials.getMaterialByName( "back" ).destroy(); _cube.materials.getMaterialByName( "right" ).destroy(); _cube.materials.getMaterialByName( "left" ).destroy(); _cube.materials.getMaterialByName( "top" ).destroy(); _cube.materials.getMaterialByName( "bottom" ).destroy();
At any rate, I hope this helps anyone out there that may be experiencing any memory problems and using cubes!