Overview

When navigating in the MediaPortal 2 GUI, the user executes a "workflow" in terms of MediaPortal 2. A workflow is a sequence of different continuous screens presented to the user. The screens are switched by navigating through the menu or the context menu or via remote control/keyboard shortcut actions.

Details

The workflow manager is responsible for managing those UI states and possible state transitions, menu and context menu items, managing UI models and publicizing the current state to the workflow models.

Workflow states

When talking about work flows consisting of states, we first have to define the term workflow state. A workflow state is an application state in respect to the GUI. Lets imagine the MP2 application as consisting of multiple independent state machines (one for the video recorder, one for the player which holds its current music title which is playing and other information, ...). Most of those state machines are system internal and hidden to the user, but the most obvious state machine contains the states which correspond to GUI screens where the user navigates through. Each of those GUI navigation states is a workflow state. A workflow state becomes apparent by an entry in the navigation bar of MediaPortal 2, which is displayed at the bottom of the screen in the default skin.

It's hard to define "workflow state" more exactly because there are few fixed characteristics. Basically, a workflow state represents the application state behind most of the logical GUI screens.

Typically, workflow states are registered to the system by plugins. A plugin might register hard coded several states for the normal application runtime, and/or for custom configuration workflows. The SkinBase plugin, for example, registers the "home" state (among others), which is associated with the home screen.

Aside from static registered workflow states, the MP2 WorkflowManager also supports transient workflow states. Those transient states will be built at runtime, from a dynamic resource for example. Examples for transient states are the media states: Each view navigation position corresponds to a transient workflow state, which are not known at compile time. When navigating through a (imaginary) path "Local Shares"/"Music""R.E.M."/"Around the Sun", each of those navigation levels will be pushed as a workflow state onto the workflow navigation context stack, i.e. this path will be visible in the navigation bar.

Workflow states are typically arranged hierarchically; there is the one and only "home" state from which transitions typically go to the UI plugin's main entrance states:

The user can navigate through that hierarchy in exactly one path from the root (home) to the trees at a time.

But there are also transitions which are not static. So called "workflow contributor actions" can show a transition from one state to another depending on certain internal conditions. For example the "Fullscreen Video" action is only visible when a video is being played. In that case, the according workflow contributor action blends in the transition to the fullscreen content state which makes the menu model show the "Fullscreen Video" menu point.

So the tree of possible state transitions consists of static transitions as well as dynamic transitions.

What you see in the navbar in the skin is the current path from the home workflow state up to the current workflow state.

Models

Each GUI screen is able to access models providing its data. So there will be models to provide the current system time, the current media item which is played or the menu to be shown in the current workflow state. Models might be stateful or stateless. We separate "normal" models from workflow models. The basic difference is: A workflow model will be notified by workflow state changes, and might hold an internal state. A normal (non-workflow) model isn't notified by workflow state changes, and thus doesn't know about the current GUI state.

Workflow models

A workflow state might be connected to a workflow model. In contrast to a stateless non-workflow model, a workflow model attends the sequence of workflow states the user navigates through. The workflow model tracks state transitions to and from its connected workflow states. So it is possible to react to workflow state transitions.

The workflow model connected to the current workflow state also can provide additional state-dependent menu actions. So a workflow model basically has two jobs: It can act as a controller for the current workflow sequence, and it can also present state-dependent GUI data.

A workflow model typically attends multiple workflow states, which form a part of a workflow.

Workflow manager

Technically, the workflow manager is responsible for:

• The synchronization between the GUI's screen, its models and workflow models
• The management of models and workflow models
• The supply of registered state transitions for the menu

It organizes the current workflow instance in form of a workflow state stack. Each workflow navigation taken by the user beginning at the home screen will push a new "workflow navigation context" onto the stack. The "back" button will pop a workflow state from the stack. The workflow manager provides methods to access the current workflow state stack and to navigate through a workflow by pushing new workflow states onto the stack or by popping states from the top of the stack.

State management

Since models don't manage the application's workflow state themselves, they always have to react to state changes which come from the workflow manager. For that reason, model developers must take care where they store the internal state of a model. Non-workflow models should be stateless in general. If still some state needs to be saved, it can be assigned to the current navigation context of the workflow manager, which can be requested by models. But be aware that non-workflow models don't get notified when the the current workflow state is left. In this case, all temporary saved state information will be lost. Another limitation of non-workflow models is that because they aren't notified about state changes, they cannot know when potential resources can be freed.

Workflow models can either hold an internal state or store their state information in the workflow navigation context. See the shares configuration workflow model in the SkinBase plugin as an example for a workflow model which holds an internal state. The ConfigurationModel of the Configuration plugin in contrast saves its state in the workflow navigation context.