diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02.dita
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,67 @@
+<?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_d0e116900_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>
\ No newline at end of file