<?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-3-1-1-9-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-3-1-1-9-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-3-1-1-9-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-3-1-1-9-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>