This topic describes how to synchronize settings across different instances of the same FEP.
As mentioned previously, the FEP architecture has been designed so that
each running application has its own instance of the current FEP. CCoeFep 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.
Override the four pure
virtual functions that CCoeFep inherits from MFepAttributeStore: NumberOfAttributes(), AttributeAtIndex(), WriteAttributeDataToStreamL() and ReadAttributeDataFromStreamL(). NumberOfAttributes() should return the number of attributes that are to be synchronized across
all instances of the FEP, AttributeAtIndex() should return
the UID of the specified attribute, and WriteAttributeDataToStreamL() and ReadAttributeDataFromStreamL() should
write/read the specified attribute’s data to/from the provided stream.
When the object of the CCoeFep -derived
class has been fully constructed, call CCoeFep::ReadAllAttributesL().
This calls the ReadAttributeDataFromStreamL() virtual function
for each of the UIDs that the FEP requires to be synchronized (as specified
by NumberOfAttributes() and AttributeAtIndex()).
After internally changing
the value of an attribute that is to be synchronized, call CCoeFep::WriteAttributeDataAndBroadcastL() 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.
The purpose of the SynchronouslyExecuteSettingsDialogL() 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 SynchronouslyExecuteSettingsDialogL() to
be able to edit settings that are required to be synchronized across all running
applications, the dialog class must derive from MFepAttributeStorer.
The dialog class’ implementation of MFepAttributeStorer ’s
virtual functions should be the same as the CCoeFep -derived
class’ implementation of them. For an example of this, see TFEP1Plugin. When
the dialog is launched it needs to call MFepAttributeStorer::ReadAllAttributesL() to
correctly initialize all the settings. Conversely, the settings in the dialog
are committed by calling MFepAttributeStorer::WriteAttributeDataAndBroadcastL().