An actor has a list of in progress {@link Action actions} that are applied to the actor (often over time). These are generallyused to change the presentation of the actor (moving it, resizing it, etc). See {@link #act(float)}, {@link Action} and itsmany subclasses.
An actor has two kinds of listeners associated with it: "capture" and regular. The listeners are notified of events the actor or its children receive. The regular listeners are designed to allow an actor to respond to events that have been delivered. The capture listeners are designed to allow a parent or container actor to handle events before child actors. See {@link #fire}for more details.
An {@link InputListener} can receive all the basic input events. More complex listeners (like {@link ClickListener} and{@link ActorGestureListener}) can listen for and combine primitive events and recognize complex interactions like multi-touch or pinch. @author mzechner @author Nathan Sweet
Actors are objects which send messages to each other and which process only one message at a time. Messages are either requests or responses. When an actor sends a request to another actor, it expects to receive a single response unless an exception has been thrown.
When an actor sends a message it provides a callback to handle the response. The callback may be invoked either immediately or later. After sending a message, an actor may send additional messages or return control, at which point it may receive other requests or pending responses.
An actor typically interleaves the processing of multiple requests. To process a request to completion, an actor may need to send requests to other actors (in series or parallel) and process the responses to those requests. Actors process requests and responses as they are received whenever the actor is not busy processing a message. There is no way to block incoming requests. Actors are thread-safe, but message processing is not atomic.
Some actors are asynchronous. Requests sent to an asynchronous actor are processed on a different thread. Actors which perform heavy computation or which do I/O should be asynchronous. Asynchronous actors play an important role in vertical scalability, allowing a program to make effective use of multiple hardware threads. But care should be used, as asynchronous message passing tends to be slow.
An {@code Actor} dispatches method calls to a target object in a thread-safe manner. Methods are called either bycalling {@link org.gradle.messaging.dispatch.Dispatch#dispatch(Object)} on the actor, or using the proxy objectreturned by {@link #getProxy(Class)}. Methods are delivered to the target object in the order they are called on the actor, but are delivered to the target object by a single thread. In this way, the target object does not need to perform any synchronisation.
An actor delivers method calls to the target object asynchronously, so that method dispatch does not block waiting for the method call to be delivered.
All implementations of this interface must be thread-safe.
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |