The client begins detached from any particular view process. In order to receive results, it must be attached to a view process. This creates demand for the process to execute, ensuring that it remains executing while the client is attached.
If the application requires asynchronous updates, it must set a result listener. This receives notifications of events from the view process. The result mode for this client may be controlled using {@link #setResultMode(ViewResultMode)}; this allows unwanted types of result to be filtered out, potentially avoiding the overhead of unnecessary serialisation.
The application may poll for the latest full result by calling {@link #getLatestResult()}. Listeners can be set or changed even when the client is detached from a view process; this allows the necessary listeners to be in place before results commence.
The per-client flow of results is controlled through {@link #pause()} and {@link #resume()}. By default, results will flow immediately, but the client may be paused before attaching it to a view process.
When results are paused, they are incrementally batched to be delivered as a single, collapsed result when they are resumed. This result is specific to the individual client that has been paused.
Use {@link #setUpdatePeriod(long)} to throttle the frequency of updates exposed through this client.
Always call {@link #shutdown()} from any state to allow resources associated with the managed view to be releasedwhen the client is no longer required. Without this, the view process may continue executing indefinitely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|