addicted2flash

Very often it is necessary to use an obervable-pattern in its basic structure, which means that the observable notifies registered observers after its internal state has changed.

This implementation concept is very static and has the side effect that the observers are notified every time the model has changed regardless of which change they are interested in.

In this case it is recommended to use a more dynamic approach like an specific observable.

But if you only have one value in the model which changes, the MicroObservable structure could be very useful. Read more...

With the loader queue it is easy to load data (f.e images or xml) application wide in a priority queue. This version uses encapsulated ILoader implementations and is therefore easy to extend.

The loader queue has the following tokens:

In addition it is possible to parametrize the loaded data with an anchor that could be of any type. This is very useful when images belong to specific objects (see code example).

For a new need of a loader implementation a programmer just had to write a new specific loader strategy that implements ILoader.

Basic implementations like a Loader and a URLLoader for loading Loader and URLLoader specific data can be found in the addicted2flash library. Read more...

There are different types of data-structure present in the AS3-Collection-Framework. Each of it has it's advantages and disadvantages. So before using it, it's recommended to first think about the requirement. Read more...

Lazy data-structures are structures that could be requested and are therefore not necessary loaded at request time.

Besides "lazy" data retrieval another important aspect of these data-structures are often the possibility to cache executed requests. To reduce http-requests on server-side it's necessary to cache the results of former requests on client-side.

To solve this problem a data-structure must be created on which specific ranges can be requested. Configured with a specific page size, data can be loaded with a constant size and requests therefore easily be cached. Read more...

In many situations programmers are forced to manipulate data structures.
These could be indexed based retrieval of data as well as sequential followed traversing. These structures are coded at least a hundret times in different projects.

To follow the fundamental thoughts of object oriented programming, there necessary has to be a common data-structure that ensure the maintainability and reusability of software.
Collection classes such as sets and lists are ideal candidates for software reuse and can therefore play an important role in object-oriented class libraries[EMKS98]. Read more...

The following post discusses an "extended" version of the Observer-Pattern.

The intent of the observer pattern is often described as an one-to-many dependency.
The key fact is that when one object changes its state, all listeners are notified about that change [GHJV95].

There are only two relevant kinds of objects in this pattern, observers and an observable.

An observable is basically an object that holds information on which other objects (observer) could be interested in.
When the data-state of the observable has changed the observers are notified about the change.
This kind of interaction is called publish-subscribe. The observable is the publisher of notifications. It sends out these notifications without having to know who its observers are[GHJV95]. Read more...

About 2 weeks ago, I started to rebuild JAVA's-Collection-Framework to Actionscript 3.0 requirements in my free time.

To my mind, there were some overengineered interfaces like the IDeque-Interface, which I decided to kick it out.

I think there are a few classes, which provide interesting and useful functionality and so there is still a way to go. But I think that the base classes in util-package are almost finished and ready to use.

Check out the the source-code.

If anyone is finding bugs or has good tasks about performance issues, I would be very pleased to hear from you.