<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02" xml:lang="en"><title>View

Server Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<section><title>Purpose</title> <p>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. </p> </section>

<section><title>Architectural relationships</title> <p>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). </p> <p>The inter-process communication required to make

and receive requests to display particular views is handled by a dedicated

server. <b>The client/server interface is not to be used directly by applications,

but through framework functions in the AppUi (CCoeAppUi).</b>  </p> <fig id="GUID-DBF38DC9-0A01-532F-83E4-B0BDC5103DB7">

<title>              View Server architecture            </title>

</fig> </section>

<section><title>Description</title> <p>The API has several key concepts: </p> <p><b>Abstract

view interface</b> </p> <p>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 <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita"><apiname>CCoeControl</apiname></xref> the view architecture

does not impose any restriction on which type of object implements the view

interface. </p> <p>The abstract view interface is provided by <xref href="GUID-2C5E3F6C-6679-3914-9736-62296E7715A7.dita"><apiname>MCoeView</apiname></xref>. </p> <p><b>View

ID</b> </p> <p>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 <xref href="GUID-530281E6-29FC-33F2-BC9B-610FBA389444.dita"><apiname>TUid</apiname></xref> type) and needs

only to be unique within the application and different from the application

UID. </p> <p>The view ID is provided by <xref href="GUID-3DEA9A17-CB50-3DCD-87AC-0E91B377FB0E.dita"><apiname>TVwsViewId</apiname></xref>. </p> <p><b>Registration</b> </p> <p>Views

are registered with the View Server. There are functions in <xref href="GUID-3AC2CDAC-0291-309F-A020-049BC9F2CF90.dita"><apiname>CCoeAppUi</apiname></xref> 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. </p> <p><b>Activation, deactivation &amp; screen

device change</b> </p> <p>Activation is the process of switching, or linking

to a view. Again, there are functions in <xref href="GUID-3AC2CDAC-0291-309F-A020-049BC9F2CF90.dita"><apiname>CCoeAppUi</apiname></xref> 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. </p> <p><b>Observation</b> </p> <p>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 <xref href="GUID-916B51B5-44BB-3010-B974-8D5D14D37169.dita"><apiname>MCoeViewObserver</apiname></xref>, <xref href="GUID-994248C5-B9C2-3932-A499-2A6A4E7A552E.dita"><apiname>MCoeViewActivationObserver</apiname></xref> &amp; <xref href="GUID-8D9CBC46-6057-3FDC-906C-35BEBDA00D16.dita"><apiname>MCoeViewDeactivationObserver</apiname></xref>. </p> </section>

<section><title>See also</title><ul>

<li><p><xref href="GUID-37E8A48E-09B8-5958-9263-B33EDAE3F7C6.dita">UI Control Framework

Overview</xref></p></li>

<li><p><xref href="GUID-1C802DBD-1453-5C69-94D5-FB0229C544D6.dita">Uikon Overview</xref></p></li>

<li><p><xref href="GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita">Application

UI</xref> </p></li>

</ul></section>

</conbody></concept>