Overview

In this section, I'll give an overview over the system components of a running MP2 GUI application.

Details

Layers

After the MP2 client has started up, the runtime structure can be devided into three layers:

Core layer

The core layer are the running services like PluginManager, MessageBroker, TaskManager, PlayerManager/PlayerContextManager, WorkflowManager, resource access services, UPnP subsystem etc.
Some of those services depend on other services, for example do some of the services load plugin parts and therefore, they use the PluginManager service. But basically, those services run autonomously without the need of any components.
The core layer forms the base system of the MediaPortal 2 client. It provides the generic MediaCenter functionality, i.e. it can load and play media items, it provides the server communication interfaces etc. This layer is fixed and cannot be exchanged dynamically in MP2 client applications (as opposed to components from the second and third layer, see below).

UI plugin layer

The UI plugins form the second layer. In this category, the SkinEngine, the Configuration plugin and all UI models are classified. This layer uses the core services from the core layer, i.e. calls those services and registers message queues to receive core service messages.
The components of this UI plugins layer provide the code which controls the actual behaviour of the application, mostly triggered by skin actions. The components of this part are completely customizable, i.e. components can simply be exchanged by exchanging their plugins by other plugins. For example, the Media plugin could be removed or exchanged by another media browsing plugin. Even the SkinEngine can be replaced by another SkinEngine; this will be done for example when MediaPortal 2 is ported to another OS like linux.

Skin layer

The skin forms the third layer. The skin is explicitly built for special components from the UI plugin layer, i.e. the Media skin explicitly „talks“ to the Media model and to some UI models from the SkinBase plugin. The skin is the component which can be customized/exchanged at the most easy way. There will be many skins and themes for the default set of UI plugins. Typically, the skin only triggers calls to functions located in the UI plugins layer; there are only very few calls to the core layer if any. The skin solely databinds to UI models, never to core services. That is important for the runtime separation of UI instances. It helps to prevent getting memory leaks.

Examples

A typical UI function will invoke components from all three layers. Here are some examples for typical UI functions:

Menu/Navigation bar

The appearance of the menu, as it can be found in almost each screen, is defined by the skin. The skin shows a ListView control which databinds to its underlaying MenuModel. The menu model gets its data from the WorkflowManager from the core layer and works it up to a list of ListItem instances which can be used from the skin.
The navigation bar works similar, here, the skin (theme) defines the appearance of a special navbar control UI element which acts as UI model in that case. Like the MenuModel, the navbar control takes its data from the WorkflowManager core service and provides properties with data which is especially worked up for the skin.

Player control

To control the players in the navigation screens, the skin (theme) defines the appearance of a special PlayerControl UI element, which works as UI model. The PlayerControl provides several properties which can be databound by the skin. It takes its underlaying data from the PlayerManager/PlayerContextManager core services.

UI Notifications

To display UI notifications, the default skin reserves a small area of the navigation screens which is used to show notification symbols if there is a notification present. The data to populate this notification area comes from the NotificationModel, which works up the data of the core NotificationService.