Implementing the FEP API

Post-platform security – the ECom plugin interface

In the secure platform, FEPs must be implemented as ECom plug-ins. ECom provides a secure environment for loading FEPs that cannot be achieved using standard, non-ECom polymorphic DLLs. The main tasks that are specific to implementing a FEP as an ECom plug-in are described in this section. Note that the differences between pre- and post-platform security FEPs are imposed by the change from old-style, standard polymorphic DLLs to ECom plugins. The C++ APIs involved in FEP creation, which are defined in fepbase.h , are unchanged.

Define a class that implements the CCoeFepPlugIn interface

This class must implement the NewFepL() and SynchronouslyExecuteSettingsDialogL() functions that were, pre-platform security, the first and second exports from the DLL. Note that these functions have been redefined and no longer take the const TDesC& aFullFileNameOfDll argument: the ECom plugin implementation is identified by a UID rather than a filename. This means that the implementation of SynchronouslyExecuteSettingsDialogL() is now responsible for locating the resource file needed to execute the settings dialog itself.

       
        
       
       class CCoeFepPlugIn : public CBase
    {
public:
    inline static CCoeFepPlugIn* NewL(TUid aFepUid);
    virtual ~CCoeFepPlugIn();
public:
    virtual CCoeFep* NewFepL(CCoeEnv& aConeEnvironment, const CCoeFepParameters& aFepParameters) = 0;
    virtual void SynchronouslyExecuteSettingsDialogL(CCoeEnv& aConeEnvironment) = 0;
    };
      

Provide the factory code required to instantiate the derived class

FEPs must provide the standard factory code required by every ECom plugin. For more information, see “Using ECom” in the Symbian Developer Library. For example, (the following code is taken from TFEP1PlugIn.cpp ):

       
        
       
       const TInt KTstFepPlugInImplementationValue = 0x102024D0;
const TImplementationProxy ImplementationTable[] = 
    {
    IMPLEMENTATION_PROXY_ENTRY(KTstFepPlugInImplementationValue, CTstFepPlugIn::NewL )
    };
EXPORT_C const TImplementationProxy* ImplementationGroupProxy(TInt& aTableCount)
    {
    aTableCount = sizeof(ImplementationTable) / sizeof(TImplementationProxy);
    return ImplementationTable;
    }
CTstFepPlugIn* CTstFepPlugIn::NewL()
    { // static
    return new(ELeave) CTstFepPlugIn;
    }
      

Create an ECom resource file

Each FEP must have an ECom resource file. Its interface UID must be 0x1020233f, or CONE will not be able to find the FEP. For example,

       
        
       
       #include <RegistryInfo.rh>

RESOURCE REGISTRY_INFO theInfo
    {
    dll_uid = 0x102024D0; // UID3 of the DLL
    interfaces = 
        {
        INTERFACE_INFO
            {
            interface_uid = 0x1020233F; // Same for every FEP
            implementations = 
                {
                IMPLEMENTATION_INFO
                    {
                    implementation_uid = 0x102024D0;
                    version_no = 1;
                    display_name = "FEPNAME";
                    default_data = "";
                    opaque_data = "";
                    }
                };
            }
        };
    }
      

The CCoeFep class

The parts of CCoeFep relevant to classes deriving from it are shown below:

       
        
       
       class CCoeFep : public CBase, protected MFepAttributeStorer, public MCoeForegroundObserver, public MCoeFocusObserver
{
public:
    enum TEventResponse
        {
        EEventWasNotConsumed,
        EEventWasConsumed
        };
    class MDeferredFunctionCall
        {
    public:
        virtual void ExecuteFunctionL()=0;
        };
    class MModifiedCharacter
        {
    public:
        virtual TUint CharacterCode() const=0;
        virtual TUint ModifierMask() const=0;
        virtual TUint ModifierValues() const=0;
        };
public:
    IMPORT_C virtual ~CCoeFep();
    virtual void CancelTransaction()=0;
protected:
    IMPORT_C CCoeFep(CCoeEnv& aConeEnvironment);
    IMPORT_C void BaseConstructL(const CCoeFepParameters& aFepParameters);
    IMPORT_C void ReadAllAttributesL();
    IMPORT_C void MakeDeferredFunctionCall(MDeferredFunctionCall& aDeferredFunctionCall);
    IMPORT_C void SimulateKeyEventsL(const TArray<TUint>& aArrayOfCharacters);
    IMPORT_C void SimulateKeyEventsL(const TArray<MModifiedCharacter>& aArrayOfModifiedCharacters);
    IMPORT_C void WriteAttributeDataAndBroadcastL(TUid aAttributeUid);
    IMPORT_C void WriteAttributeDataAndBroadcastL(const TArray<TUid>& aAttributeUids);
    IMPORT_C TBool IsOn() const;
private:
    virtual void IsOnHasChangedState()=0;
    virtual void OfferKeyEventL(TEventResponse& aEventResponse, const TKeyEvent& aKeyEvent, TEventCode aEventCode)=0;
    virtual void OfferPointerEventL(TEventResponse& aEventResponse, const TPointerEvent& aPointerEvent, const CCoeControl* aWindowOwningControl)=0;
    virtual void OfferPointerBufferReadyEventL(TEventResponse& aEventResponse, const CCoeControl* aWindowOwningControl)=0;
    };
      

Note that CCoeFep inherits, but does not override, some pure virtual functions from its base classes MFepAttributeStorer , MCoeForegroundObserver and MCoeFocusObserver . These therefore need to be overridden in addition to CCoeFep ’s own pure virtual member functions. The details of the member functions of CCoeFep and its base classes are explained in various sections of this document.

The CCoeControl class

The CCoeControl class (defined in epoc32\include\COECNTRL.H ) provides many useful features for implementing a FEP, such as functions for handling window server events. In fact, for FEPs wishing to intercept key events, writing a class that derives from CCoeControl is a necessity because of the need to use the control stack (see Intercepting key events , below). Thus although deriving from CCoeControl is not explicitly demanded by the FEP architecture, it is assumed throughout this document that the object of the CCoeFep derived class owns an object of a CCoeControl derived class.