Difference between revisions of "Eclipse4/RCP/Lifecycle"

Revision as of 17:34, 3 April 2015

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

@PersistState
private void persitState() {
  // do stuff
}
 
@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 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.