Difference between revisions of "Eclipse4/RCP/Lifecycle"

Revision as of 12:56, 5 February 2013

E4AP provides two levels of lifecycles, for contributions and for the application.

Component Lifecycle

Components (UI or non-UI) very often manage resources that need to be initialized when the component is instantiated, or disposed when the component itself is disposed. This is a long-winded way of saying that a container should call a method after a component is instantiated and ready to go, and call another method just before disposing the component.

Clients can use the @PostConstruct and </tt>@PreDestroy</tt> JSR-250 annotations to mark methods that should be called by the framework.

Initialization

@PostConstruct
private void init() {
  // do stuff
}

Disposal

@PreDestroy
private void dispose() {
  // do stuff
}

Application Lifecycle

The E4AP provides a few mechanisms for hooking into the application lifecycle.

The Lifecycle Manager

A product can provide a lifecycle manager object. An instance of this object will be created and called into by E4AP using a set of annotated methods. The lifecycle manager class is provided as a URI either using the "lifeCycleURI" product property or from the "-lifeCycleURI" command-line argument; only a single lifecycle manager is supported at present. The lifecycle manager is created on the application context.

Currently supported annotations are those in org.eclipse.e4.ui.workbench.lifecycle:

• PostContextCreate: called after the application context has been created, but prior to the model having been loaded
• ProcessAdditions: called once the application model is loaded.
• ProcessRemovals: called after ProcessAdditions
• PreSave: called before the model is persisted

Model Processors

Model processors are provided an opportunity to manipulate the model after load. A model processor may be invoked either before or after any fragments have been loaded. Processors are typically used for one-time model transformations; model addons are used for providing model-based services.

Model processors are specified using the org.eclipse.e4.workbench.model extension point. The processor is created with a context hooked from the application context, and is triggered with the org.eclipse.e4.core.di.annotations.Execute-annotated method.

Model Addons

Model addons are typically used for associating model-based services, i.e., services that react to changes in the model over the course of the application lifetime. An addon is specified by adding a reference to the MApplication's addon list, either through a model processor or via a fragment.

Addons,like any model contribution, are triggered by @PostConstruct and @PreDestroy. Any execution for an addon must be started from its @PostConstruct and those listeners should be removed in @PreDestroy. Addons are created after @ProcessRemovals, and disposed as part of the application context being destroyed.

An addon can use Eclipse4/RCP/Modeled_UI/Listening_to_Model_Changes model changes to react at events that are meaningful within the application lifetime. For example, an addon could install an event listener for a widget-set on a window to detect when the first window is shown.