<?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" 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"><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"><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"><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>