Design Pattern: View Handler

 

Intention

For graphic user interface (GUI)

Application, Multimedia System, etc

One system, different view

The View Handler design patterns help to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organizes their update

 

 

Example

Multi-document editors allow several documents to be worked on simultaneously

Each document is displayed in its own window

Users can clone window and work with serveral independent views of the same document

Changes in one window may affect other windows as well

Need an efficient update mechanism for propagating changes between windows

 

 

Context

A software system that provides multiple views of application-specific data, or that supports working with multiple documents

 

 

Problem

Need to support multiple views often need additional functionality for managing them

Views need to be coordinated

Need update propagated

Forces

 

 

Solution

Divide and Conquire

Separate the management of views from the code required to present or control specific views

A view handler component manages all views that the software system provides

It offers services opening, coordinating and closing

For example, tile all views to arrange them in an orderly pattern

Specific views, together with functionality for their presentation and control, are encapsulated within separate view component - one for each kind of view

Suppliers provide views with the data they needed

(Compared with Model-View-Controller, only remove responsibility of managing the entirely of views)

 

 

Structure

View handler is the central role, it opens new views

Client specify the view they want

(open-then-display, open-then-iconize)

It handles closing view as well

Main service is to offer view management services

For example, bring a specific view into several parts, to refresh all views, to clone views

Coordination of views

Serial update is coordinated if necessary (most global information should be updated first)

Class
  • View Handler

Responsibility

  • Opens, manipulates, and disposes of views of a software system

Collaborators

  • Specific View

Abstract view component defines an interface that is common to all views

View handler uses this interface for creating, coordinating and closing views

The backend will use the same interface to execute user events, e.g. resizing the window

Class
  • Abstract View

Responsibility

  • Defines an interface to create, initialize, coordinate, and close a specific view

Collaborators

  • -

Specific view components are derived from the abstract view and implement its interface

Implement its own display function

Data are from suppliers

The display function is called when opening or updating a view

Class
  • Specific View

Responsibility

  • Implements the abstract interface

Collaborators

  • Supplier

Supplier components provide the data that is displayed by view components

They notify dependent components about change to their internal state

Class
  • Supplier

Responsibility

  • Implements the interface of the abstract view-one class for each view onto the system

Collaborators

  • Specific View
  • View Handler

 

ViewHandler ---- creates, closes, and coordinates -------------- AbstractView
|                                                                    |
notifies                                                           inherits
|                                                               |             |
|                                                        SpecificViewA  SpecificViewB
|                                                               |             |

Supplier ---------------------------------------------------------------------------- retrieves data --------

 

 

Dynamics

Scenario I: shows how the view handler creates a new view

  1. A client (user or another component) calls the view handler to open a particular view
  2. The view handler instantiates and initializes the desired view
  3. The view registers with the change-propagation mechanism of its supplier (as in Publisher-Subscriber pattern)
  4. The view handler adds the new view to its internal list of open views
  5. The view handler calls the view to display itself
  6. The view open a new window, retrieves data from its supplier, prepares this data for display, and presents it to the user

 

Scenario II: Organizes the tiling of views

  1. Client invokes the command to tile all open windows
  2. The request is sent to the view handler
  3. For all the opened view, the view handler calculates a new size and position, and calls its resize and move procedures
  4. Each view changes its position and size, sets the corresponding clipping area, and refreshes the image it displays to the user
  5. View will re-get the data from suppilers if necessary

 

 

Implementation

Identify the views

Specify a common interface for all views (should at least include functions to open, close, display, update, and manipulate a view)

Implement the views (add whatever patterns, or ticks ... double buffer, etc)

Define the view handler (hold control information about views, logging about animated simulation, serial update, remote access, etc)

 

 

Variants

View Handler with Command objects - use command objects to keep the view handler independent of specific view interfaces

View Handler with remote access (Proxy)

 

 

Known Uses

Macintosh Window Manager

Microsoft Word

Some variation of emac editor

 

 

Conseqences

Advantages

Uniform handling of views

Extensibility and changeability of views

Application-specific view coordination

Disadvantages

Restricted applicability - only if different views are needed

Efficiency