How to write a 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().