TyZ - Thijs Broerse - Flash Developer

Op 18 november heb ik op FLUGR een presentatie gegeven over de Temple.

Hierbij de presentatie in PDF.

The Flash Player has a problem with cleaning up memory for AS3. Storing a reference to an object blocks the Garbage Collector from disposing the object and the object will be kept in memory. That’s why a lot of developers set ‘useWeakReference’ to true when adding an event listener.

1

addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void

“A strong reference (the default) prevents your listener from being garbage-collected. A weak reference does not.”

http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/events/IEventDispatcher.html#addEventListener%28%29

I think using weak listeners is bad practice - don’t do it!

When setting a listener as weak the responsibility of the operation of your application is transfered to the Garbage Collector, which isn’t reliable at all. If and when the Garbage Collector is running is completely random[1]. You never know if or when your listeners are removed, which makes your application unreliable and unstable. Weak listeners are used by lazy developers who don’t want to take responsibility for cleaning up their own code.
Removing event listeners should always be the responsibility of the developer (or application) and not the Garbage Collector. So if you add an event listener be sure you also remove it when the object should be disposed.

There is only one exception for using weak listeners: adding listeners to the stage. Since the stage will never be disposed and the only reference to an object is the reference to the stage, there is no need for this object to exist. But still you have to remove this (weak) listener when this object should be disposed!

Temple
If you do not want to remove all listers by hand, you could use Temple Library. This toolkit has a destruction model which automatically removes all (strong) event listeners when an object is destructed and makes the object available for garbage collection. But even if the Garbage Collector isn’t running your destructed objects won’t unnecessary listen for events.

The Temple is open-source and available on GoogleCode: http://code.google.com/p/templelibrary/

[1] I know there are some tricks to force a garbage collection, but those are all unsupported. So a Flash Player update could break those tricks.

If you have a function reference in Flash there is not a lot of information you can get from it. Converting the function to a string will only give you: (more…)

‘Temple‘ is the name of our AS3 library we use at MediaMonks. Almost all of our AS3 projects are using it. The Temple is inspired on several 3rd party libraries like ASAPLibrary, AS3CoreLib and CaseLib, but adapted to fit our needs.

The Temple consists of several classes we use on a regular basis. They are designed for reusability and optimized for performance and memory usage.  The Temple is specially designed to work with other frameworks like Gaia. The core of the Temple focuses on: debugging, destruction and memory management.

Debugging
Many classes are debuggable and have a ‘debug’ property. When this property is enabled, the object logs debug messages which allow you to see what the object is doing. All debuggable objects can be managed by the DebugManager. The DebugManager allows you to run all objects in debug mode.
All messages are logged through the Log class which is easily extended for usage by other logging applications, like Yalog and DeMonsterDebugger.

Destruction
All objects are destructible. By calling the destruct- method, the object will clear all of its data, removes all event listeners, removes itself from the display list (DisplayObjects only of course) and makes the object available for garbage collection. Destruction is recursive, so an object will also destruct all its children.

Memory Management
All Temple objects are tracked, via weak reference, in the Memory class. You can view all objects in the Memory class. This makes it possible to detect if an object’s destruct method is working correctly.

More
We also added many nice utility classes for the initial release of Temple, however there is a lot more to come. Since we are keen on stable, neat, and well documented code we are initially only releasing the core of the Temple library. This code has been used and tested and has proven to fit our requirements. There is a lot more we are planning to release soon, like UI components (buttons, form components, video player), loaders (CacheLoader, ImageLoader) and behaviors.

The Temple can be downloaded from Google code and the documentation can be viewed online.

For updates follow us at Twitter.

The Temple is released under the GNU General Public License which allows you to use, extend or modify the code to whatever you want.

I use Gaia a lot. I think it’s a great and powerful framework to create page-based Flash sites. But there is a problem: Gaia creates a SWF for every page. And every time you visit a page, the SWF is loaded again. Even if you already visited that page. Also it is not possible to preload pages you are not visiting.

To make page caching and page preloading possible, I have created the ‘CacheLoader‘ and ‘CacheURLLoader‘ classes. Both classes make use of the ‘LoaderCache‘ to cache the SWF files used by Gaia. Just add these 3 classes to your project and you only have to adapt 2 Gaia classes to enable this feature: (more…)

I am a huge fan of Gaia Flash Framework, I use it for almost all my projects. It is a great framework if you want to create solid and maintainable Flash websites.

But as with many Frameworks it comes with some disadvantages; Gaia creates a .fla file for every page, but a page will not run standalone. After compiling the .fla file you have to test the page through the main.swf. For a huge project this is very unwieldy and inefficient.

So I created this “GaiaStandAloneRunner” which enables you to run your Gaia pages standalone, even with all the assets and SEO copy defined in your site.xml. The code only adds about 0.6 KB to your page swf file. (more…)

If the HTML is larger than the browsers window, using the mouse-wheel will always result in a page scroll in AS3. That’s a bummer if you want to use the mouse-wheel inside the Flash.  This problem is better explained here.

After a lot of Googling I found out there wasn’t a good solution for this problem. So I build something that works. (more…)

For a project I am making a videoplayer which can be controlled by the keyboard. The spacebar is used for toggling between play and pause. But a bug inside the Flashplayer causes my videoplayer to pause or play when entering fullscreen mode. Since this is really anoying I wrote a workaround which seems to be working very nice: (more…)