Version: Next

Lifecycle of Plugins

The Lifecycle of a Feature should partly be reflected to the Plugin implmentation itself by implementing the Lifecylce Protocol in the Plugin.

This way plugins can adapt their business logic to the user journey.

Plugin Lifecycle

Plugin have a couple of methods that are being called based on state of the User, Userinteractions and interoperability between plugins.

To provide informations about the plugin, some attributes are also requested by the plugin implementation:

method or attribute	type / return type	Name	Description
attribute	String	identifier	Each Plugin has a unique identifier, that is used for logging, debugging and being referenced from other Plugins.This identifier should follow this format `<provider>.<app_name>.<plugin_name>`, example: `ey.navida.videoconsultation`
attribute	`List<Provider>`	provider	Each plugin can have data provider that could be used by other consumers to receive data from this plugin. Example: One Plugin provides data about upcoming events, another plugin can use this information to provide Information to the User
method	none	init	First call made towards the plugin. If this method is called, the plugin should prepare itself for being opened to the user. In this case API Calls should be performed or local data should be loaded
method	none	reset	resetialize the plugin. Data and memory should be cleared
method	none	update	Method that is constantly called, whenever there is a change to the environment, like the User or user-related meta data
method	Screen?	start	User or another Plugin indicated the start of this plugin. If this plugin can be opened with the informations passed, the start method will return a dedicated Screen. The Deeplink-Information contain infos about the route, that should be opened. User Informations, like name, gender, age are passed in.
method	none	stop	User and/or the system indicates the plugin to stop running. Based on the reason data should be cleared