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).

- 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.

See also

UI Control Framework -Overview
Uikon Overview
Application -UI

+ + + + + +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).

+ 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.