[AS3] StateView

/*
-----------------------------------------------------------------
StateView by thienhaflash (thienhaflash@gmail.com)
	
Updated			: 26.Feb.2012
Callbacks 		: -
Features 		: 
	Automatically get the children of a container use as states
	Support optional custom transitions when changing states
	Support optional callbacks on each child to be called when transition start / end
		(onStartIn, onStartOut, onEndIn, onEndOut)
	Automatically disable interaction and block state changes while doing transition
	Fully trace for invalid operations for easy tracking down
	No dependencies (don't even need a tween engine)
------------------------------------------------------------------
*/

[AS3] Input

In the efforts to unify the AS3 libraries i realized that writting too many files (each file is specific for one functionality) though very clear and easy, maintainable is a big issue. I usually need to bring the whole library, which caused conflicts to another project when there might be other versions of utils classes (btw, i used to put package’s function for each utility) happen to be there. This caused too much headaches as the old ones will might not work the way we expected with the new ones, overwrite is not an option, especially when the classes was patched for bugs in different projects. Of course, life should be easier if you track down everything you modified to a class got used in the real project or got simple unit test for each file, but still, the portability is not that great.

One class for one thing should be the way to go, though it’s heavier in term of code base, the maintainable process should be easy enough, just move it somewhere, rename the package once if needed. No missing or conflicted dependencies to worry about …

One cool thing in this version is that you don’t need to cancel out theme configuration : if a state used bold = true, we don’t need to cancel out for other state, aka, doesn’t need to put bold=false for each other states. Another one is that we can do input configuration from timeline.

MultiKey Dictionary

While developing some kind of event monitoring Manager class i come across a problem of too many Object used : Each IEventDispatcher source can dispatch multiple eventNames, each eventName can have several function attached to it. The popular approach is using nested Dictionary/Object as the main data structure :

_sourceDict : Dictionary; /* map IEventDispatchers to _eventObjects */
_eventObject : Object; /* map eventName to _handlerDict */
_handlerDict : Dictionary; /* map handler to its params */

For faster check and overwrite the existed _handler for a specific source and eventName we need to use a Dictionary for _handlerDict instead of an Array, and by the way, add support for user parameters.

This data structure of course will still work without any problem even though the code looks busy by nested properties access. We might also got slow down by looping through those nested structure. Let’s have a look through another implementation where we save multiple values as the key instead of only one.

Indexed Linked List

Indexed Linked List is an improved version of Single Linked List that enable random access (can only found on Array) and fast item splicing (can only found on Linked List). We can use it for prioritized queues where items often got inserted / removed at arbitrary positions. Some popular applications are loading queue manager (sort by priority), delayed tween list (sort by delay), or custom Event Dispatcher (addListeners with priority).

I. THE GENERAL IDEA :

We have a single linked list (to cut memory cost 30% compared to double linked list), every item has a {.next} pointer point to the next item in the list. Every item has a {.priority} property to be used as mandatory sort term, a {.time} stamp for secondary sort term, this way, every item is unique and can be compared to each other without equality worries.

Besides the normal linked list implementation we have another Array {_grid} to keep track of pivots items at some rough space {_gridSize}, that means for every roughly {_gridSize} items in the list we save an item into the {_grid}. This kind of indexing will enable binary search for position of any item in the list which means fast random access to items (fixed (and small) time to reach any item in the list). Of course, this won’t beat Array’s random access, but it’s fast enough for practical use !

A better AS3 Singleton implementation

As a developer we usually need to create libraries to reuse in various projects, most of them are of the manager style : one class (or instance) to handle all in coming tasks from various places, popular examples are : Tween engines, Loading services, 3D libraries, Sound processing library … The simplest implementation is the static-class-methods way.

I. THE STATIC CLASS METHODS IMPLEMENTATION :

Let’s have a look through a simple library class :

package {
	public class MyUtility {
		public static function methodA(): void {
			//do A things here
		}
		public static function methodB(): void {
			//do B things here
		}
	}
}

And its simple usage syntax

MyUtility.methodA();//call method A
MyUtility.methodB();//call method B

EnterFrame

One of the most popular Event being used in AS3 is the EnterFrame Event. Working with Enterframe has some advantages as more than often we will need to update things each frame, or sometimes, defer validation for performance boost. As you all may already know, we can only has EnterFrame listens to DisplayObjects, like Shape, creating an empty shape for every class just for EnterFrame listening is not very efficient, neither in term of memory nor processor cost (remember that listens to EnterFrame event dispatching from multiple objects will slower than listen multiple times to one object).

So, in brief, this small utils will help you a little bit for better working with EnterFrame event in AS3. Not covering performance gains, it shortens your code and support custom parameters + once listeners

Linked List

It’s a rumor that Linked List should be a better Data structure to choose if we only need to traverse linearly one after another, without the need of randomly access, plus the ability to remove/ insert items at arbitrary positions.

For 1000 items double linked list

1. Pushing items into the first, or last position is 15x faster than put items randomly as we need to search for the correct position, as an important side note : searching time will go up linearly with the List size.
2. Pushing items into Array is much faster than insert into first/last position of the list : Push/Pop is 4x faster and even randomly splice is 1.2x faster.
3. List seems to use much more memory than Array, about 5x more, as each node of the list is an Object, that has at least 2 variables refer to prev and next items.
4. Traverse from first to last item is 2x slower than the same task with Array.
5. Checking existances using indexOf in both Array and List is not efficient, it’s very slow as we need to traverse one after another to find out.
6. For huge number of items, list operations should go linearly while Array won’t

Hooking

Hooking provides a lightweight way to add flexibility to applications, especially for components. We just can not handle all types of skins, themes and interactions internally as it is too complex and vast, instead, allow some kind of hooking will allow user to handle things their way without the need of reading and understanding how things work internally.

Let’s see a simple sample for size-handling ! Let’s say we have a component base class

package {
	public class AComponent {
		// ...
		public function setSize(w: int, h: int): void {
			//do skin handling here
		}
		// ...
	}
}

As we can see we will need to do all supported skin resizing inside setSize function to enable skin to change its size. Let’s think of the various cases when the skin is just a simple textfield, a bitmap, or a sprite contains a textfield, or a sprite contains many other sprites (bg, border, textfield …) how our almighty setSize handle that ? just can’t with all possible cases, right ? And we usually agree on a compromise solution that we will only support some type of skins or defining some naming rules that user must follow in order for the component to woks. This will work for most cases although we will need quite a bit of work but it’s worth to note that there are special cases that user just can not fit their need into our rules … what will they do then ?