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).
Figure: View Server architecture
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.