View Server Overview

Purpose

This API allows applications to make and receive requests to show a particular view of data. Small amounts of data may be passed in such requests. The view architecture allows a high level of integration between applications. This is particularly useful for enabling users to navigate through the UI on the basis of the tasks they are working on, rather than perceiving separate applications.

Architectural relationships

Views are UI classes (almost invariably controls) that implement the Symbian view interface. They display application data and are owned by the application's main user interface class (the AppUi).

The inter-process communication required to make and receive requests to display particular views is handled by a dedicated server. The client/server interface is not to be used directly by applications, but through framework functions in the AppUi (CCoeAppUi).

Description

The API has several key concepts:

Abstract view interface

The abstract view interface is implemented by application views to receive activation and deactivation requests from the view server. The activation method allows a message (a Direct Navigational Link, or DNL), encapsulated in a descriptor, to be passed to the view (for example, the name of a file that should be displayed in the view). Note that although view classes are usually derived from CCoeControl the view architecture does not impose any restriction on which type of object implements the view interface.

The abstract view interface is provided by MCoeView.

View ID

The view ID identifies a view uniquely. It consists of two UIDs: the application's UID, which is allocated by Symbian, and a view UID, which is allocated by the Symbian developer. The view UID is not strictly a UID (though it is of the the same TUid type) and needs only to be unique within the application and different from the application UID.

The view ID is provided by TVwsViewId.

Registration

Views are registered with the View Server. There are functions in CCoeAppUi to do this. Once registered other applications may activate them by specifying their view IDs. Applications which do not implement views may still participate in the view architecture, though to a lesser degree, by registering themselves using their application UID.

Activation, deactivation & screen device change

Activation is the process of switching, or linking to a view. Again, there are functions in CCoeAppUi to activate and deactivate a specified view. The new view is activated and the old view is deactivated. Activation and deactivation events enable to actions to be performed by both new and old views. Similarly views need to know when screen orientation (portrait to landscape) or size (flip closed to flip open) has changed.

Observation

Besides creating events and calling framework functions on activation, deactivation and screen device change the view architecture also supports three view observer interfaces which are also notified when such actions occur, namely MCoeViewObserver, MCoeViewActivationObserver & MCoeViewDeactivationObserver.

See also

• UI Control Framework Overview

• Uikon Overview

• Application UI