GoEngine.addManager()
* [This section updated recently!]
* What are managers?
* *Tweens and other animation items are not aware of other items while they
* run; by contrast, manager classes can monitor and interact with many active
* items at once. OverlapMonitor, a manager shipped with GoASAP,
* prevents situations like two different tween instances trying to animate the
* x property of a single sprite at the same time. This type of conflict needs
* a system-level manager that can look at multiple items as they operate. Managers
* can be used to automate any general process within an animation system.
* This sounds dry, but it can be a creative opportunity as well: imagine a manager
* that automatically motion-blurs targets based on their velocity, for example.
* Working at the system level gives you power that you don't have at the GoItem level,
* and opens up a new range of possibilites. For example, a custom game engine would
* be built primarily at the management level.
There is a distinct difference in the Go system between managers and
* utilities, although both typically work with batches of Go items. Utilities
* are tools designed to be directly used at a project level, such as a sequence or
* animation syntax parser (even GoItems like tween classes are essentially
* utilities). In contrast, managers are self-sufficient entities that, once registered
* to GoEngine, operate in the background without requiring any direct
* interaction at runtime.
About Go's Decoupled Management system
* *The downside of managers in general is that they can add overhead as they perform * their additional processes, slowing your system down. Prefab tween engines usually "bake" * management features into their core code, locking you into any processing cost incurred as * well as whichever set of features the author decided were important. GoASAP's management * layer is designed specifically to solve these problems, and is GoASAP's most unique * architectural feature. It leverages the centralized pulse engine as a registration hub * for any number of managers, then leaves it up to the end user which managers to register * per project.
* *This layer stays optional at all levels: it is optional to make tweens or other
* animation items manageable in the first place (by implementing IManageable),
* but it is very easy to write your own custom managers (that implement IManager).
* Then even after implementation, it still remains optional for the end-user whether to add
* any particular manager to GoEngine at runtime. By choosing not to add any managers if they
* aren't needed in a project, Go can stay ultimately streamlined and limit its footprint to
* just code that is used. It's also very easy to create custom managers to meet the needs
* of a challenging project. You can activate these custom tools at runtime this time, then
* ignore them until needed again. This allows you to tie your custom program code very tightly
* into your animation engine, but keeps those customizations neatly 'decoupled.'
Go Manager types
* *Go currently provides two manager interfaces to choose from, IManager and
* ILiveManager. An IManager is notified every time any IManageable
* item is added or removed from GoEngine. This is the interface used by OverlapMonitor
* for example, which only needs to detect conflicts as new items are added. The second interface,
* ILiveManager, is for situations where you want a manager to actively handle items
* as they update.
Implementing IManager
This interface has two methods that are called by GoEngine, reserve()
* and release(). The first method is called when any item that implements IManageable
* is added to the engine, and the second is called when such an item is removed. This means that
* instances of a tween class that implements IManageable, for example, can be
* trapped by the manager while their play cycle is active. Managers can do whatever they want
* with the items, but the IManageable interface ensures that they can always get
* the active animation targets and properties from the item, determine property overlap
* between items, and ask items to stop playing when necessary. There are no rules for what you
* write in the reserve() or release() methods, except that you should not
* call release() directly from reserve(), but instead ask an item to stop via
* a IManageable.releaseHandling() call. GoEngine will call release()
* on the manager once the item has truly been stopped.
You can also extend IManageable to add special functionality that a manager might use
* on an item, or even just to create a new marker datatype without adding any custom methods. This enables
* your custom managers to sniff for a particular interface type in order to determine which items to store,
* monitor, or alter. The general rule is that items like tweens are considered working code, so you might
* end up changing the management implementations on different sets of tweens based on your project needs.
* Regardless of implementation on the manageable side, managers will remain decoupled in that they need
* to be registered into GoEngine to be compiled and used in a project. As a general rule
* you should try to have managers and managed items only reference each other via interfaces so that no
* classes are forced to be compiled until they are used directly in a project.
This method should NOT directly stop the item, stopping an item results in * a release() call from GoEngine. This method should simply remove the item from * any internal lists and unsubscribe all listeners on the item.
*/ function release(handler:IManageable):void; } }