Package	org.goasap.interfaces
Interface	public interface IManager
Subinterfaces	ILiveManager
Implementors	OverlapMonitor

Makes an object compatible with 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.

See also

---

release

()

method

reserve

()

method

---