Symbian3/SDK/Source/GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02.dita
author Dominic Pinkman <dominic.pinkman@nokia.com>
Fri, 11 Jun 2010 12:39:03 +0100
changeset 8 ae94777fff8f
parent 7 51a74ef9ed63
child 13 48780e181b38
permissions -rw-r--r--
Week 23 contribution of SDK documentation content. See release notes for details. Fixes bugs Bug 2714, Bug 462.

<?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>
<image href="GUID-347ACB44-5D07-5EA6-8751-E424A118859D_d0e131819_href.jpg" placement="inline"/>
</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>