Symbian3/SDK/Source/GUID-ACC71D0D-32C4-5DAF-B4D9-66013A073FD4-GENID-1-8-1-6-1-1-4-1-8-1-4-1-8-1.dita
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-ACC71D0D-32C4-5DAF-B4D9-66013A073FD4-GENID-1-8-1-6-1-1-4-1-8-1-4-1-8-1.dita Wed Mar 31 11:11:55 2010 +0100
@@ -0,0 +1,50 @@
+<?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-ACC71D0D-32C4-5DAF-B4D9-66013A073FD4-GENID-1-8-1-6-1-1-4-1-8-1-4-1-8-1" xml:lang="en"><title>Synchronising
+FEP Instantiations</title><shortdesc>This topic describes how to synchronize settings across different
+instances of the same FEP.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>As mentioned previously, the FEP architecture has been designed so that
+each running application has its own instance of the current FEP. <codeph>CCoeFep</codeph> provides
+support for synchronizing attributes across all of these instances, so that
+when one instance changes the value of an attribute, the others are automatically
+updated. In order for this to happen, the FEP has to do several things. </p>
+<ul>
+<li id="GUID-EC8E4D77-BE0E-5A5E-87B0-817109AD5D44-GENID-1-8-1-6-1-1-4-1-8-1-4-1-8-1-3-2-1"><p>Override the four pure
+virtual functions that <xref href="GUID-ADAA039A-7BF3-3B06-8486-2E3604C2633D.dita"><apiname>CCoeFep</apiname></xref> inherits from <xref href="GUID-B0007B23-6745-31BE-A832-9ACA4C12E3E6.dita"><apiname>MFepAttributeStore</apiname></xref>: <codeph>NumberOfAttributes()</codeph>, <codeph>AttributeAtIndex()</codeph>, <codeph>WriteAttributeDataToStreamL()</codeph> and <codeph>ReadAttributeDataFromStreamL()</codeph>. <codeph>NumberOfAttributes()</codeph> should return the number of attributes that are to be synchronized across
+all instances of the FEP, <codeph>AttributeAtIndex()</codeph> should return
+the UID of the specified attribute, and <codeph>WriteAttributeDataToStreamL()</codeph> and <codeph>ReadAttributeDataFromStreamL()</codeph> should
+write/read the specified attribute’s data to/from the provided stream. </p> </li>
+<li id="GUID-0163FF77-8495-5812-AF0D-2FB9AB376EC5-GENID-1-8-1-6-1-1-4-1-8-1-4-1-8-1-3-2-2"><p>When the object of the <xref href="GUID-ADAA039A-7BF3-3B06-8486-2E3604C2633D.dita"><apiname>CCoeFep</apiname></xref> -derived
+class has been fully constructed, call <codeph>CCoeFep::ReadAllAttributesL()</codeph>.
+This calls the <codeph>ReadAttributeDataFromStreamL()</codeph> virtual function
+for each of the UIDs that the FEP requires to be synchronized (as specified
+by <codeph>NumberOfAttributes()</codeph> and <codeph>AttributeAtIndex()</codeph>). </p> </li>
+<li id="GUID-E4435F88-8C8F-5E93-8587-101DBCA7FA03-GENID-1-8-1-6-1-1-4-1-8-1-4-1-8-1-3-2-3"><p>After internally changing
+the value of an attribute that is to be synchronized, call <codeph>CCoeFep::WriteAttributeDataAndBroadcastL()</codeph> to
+propagate that change to all the other instances of the FEP. The parameter
+identifies the attributes that are to be synchronized, using UIDs. See the
+Symbian website for information on how to be allocated UIDs. </p> </li>
+</ul>
+<p>The purpose of the <codeph>SynchronouslyExecuteSettingsDialogL()</codeph> exported
+function, which the FEP must provide, is to launch a dialog that allows the
+user to change any settings specific to that FEP. As mentioned above, there
+is no guarantee that any instance of that particular FEP exists when this
+function is called. In order for the dialog launched by <codeph>SynchronouslyExecuteSettingsDialogL()</codeph> to
+be able to edit settings that are required to be synchronized across all running
+applications, the dialog class must derive from <xref href="GUID-270424BB-124B-39FF-9CDA-5CAFB5407FAE.dita"><apiname>MFepAttributeStorer</apiname></xref>.
+The dialog class’ implementation of <xref href="GUID-270424BB-124B-39FF-9CDA-5CAFB5407FAE.dita"><apiname>MFepAttributeStorer</apiname></xref> ’s
+virtual functions should be the same as the <xref href="GUID-ADAA039A-7BF3-3B06-8486-2E3604C2633D.dita"><apiname>CCoeFep</apiname></xref> -derived
+class’ implementation of them. For an example of this, see TFEP1Plugin. When
+the dialog is launched it needs to call <codeph>MFepAttributeStorer::ReadAllAttributesL()</codeph> to
+correctly initialize all the settings. Conversely, the settings in the dialog
+are committed by calling <codeph>MFepAttributeStorer::WriteAttributeDataAndBroadcastL()</codeph>. </p>
+</conbody></concept>
\ No newline at end of file