View source for Eclipse4/RCP/Lifecycle

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 <tt>@PostConstruct</tt> and </tt>@PreDestroy</tt> [http://jcp.org/en/jsr/detail?id=250 JSR-250] annotations to mark methods that should be called by the framework.

=== Initialization ===

<source lang="java">
@PostConstruct
private void init() {
  // do stuff
}
</source>

=== Disposal ===

<source lang="java">
@PreDestroy
private void dispose() {
  // do stuff
}
</source>

== 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 <tt>org.eclipse.e4.ui.workbench.lifecycle</tt>:

* <tt>PostContextCreate</tt>: called after the application context has been created, but prior to the model having been loaded
* <tt>ProcessAdditions</tt>: called once the application model is loaded.
* <tt>ProcessRemovals</tt>: called after <tt>ProcessAdditions</tt>
* <tt>PreSave</tt>: 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; <em>model addons</em> are used for providing model-based services.

Model processors are specified using the [http://help.eclipse.org/juno/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_e4_workbench_model.html <tt>org.eclipse.e4.workbench.model</tt>] extension point.  The processor is created with a context hooked from the application context, and is triggered with the <tt>org.eclipse.e4.core.di.annotations.Execute</tt>-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 <tt>MApplication</tt>'s addon list, either through a model processor or via a fragment.

Addons,like any model contribution, are triggered by <tt>@PostConstruct</tt> and <tt>@PreDestroy</tt>.  Any execution for an addon must be started from its @PostConstruct and those listeners should be removed in <tt>@PreDestroy</tt>.  Addons are created after <tt>@ProcessRemovals</tt>, 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.