Features of an ECOM Interface

Let's start by considering the features of an ECOM interface:

• As expected, the interface will define a set of pure virtual functions which a concrete instance will implement.

• In addition, the interface must also provide one or more factory functions that pass a cue to ECOM to enable it to instantiate an object of the correct implementation (in the example below, the interface definition has two static NewL() functions).

• The interface must also provide a means for its clients to release it, such as a destructor to allow it to be deleted, or a method such as

• An ECOM interface definition must also have a TUid data member which is used internally by ECOM to identify an implementation instance for cleanup purposes.

Here is the definition of the example interface class, CCrypto-Interface. You'll notice that the example interface class is a C class rather than an M class, which is what you may automatically have expected for an abstract interface definition from the discussion of the standard Symbian OS class types in Chapter 1. The reason for this is clear on further inspection, because an ECOM interface class has features which are atypical of an M class, such as the static instantiation method and a TUid data member.

class CCryptoInterface : public CBase {

public:

enum TAlgorithm { EDES, E3DES, EAES, ERC2, ERC4 };

// Instantiation of a default object of this type IMPORT_C static CCryptoInterface* NewL();

// Instantiation using a cue to identify the implementation to use IMPORT_C static CCryptoInterface* NewL(const TDesC8& aCue);

IMPORT_C virtual ^CCryptoInterface();

// List all implementations of this interface IMPORT_C static void

ListImplementationsL(RImplInfoPtrArray& aImplInfoArray);

public:

// Interface functions to be implemented by a concrete instance virtual void EncryptL(TDesC8& aPlaintext, TDesC8& aKey,

TDes8& aCiphertext, CryptoInterface::TAlgorithm) = 0;

virtual void DecryptL(TDesC8& aCiphertext, TDesC8& aKey,

TDes8& aPlaintext, CryptoInterface::TAlgorithm) = 0;

private:

TUid iDtor_ID_Key; // Identification on cleanup };

This example interface derives directly from CBase, but it is not mandatory for an ECOM interface definition to do so. Interfaces may, for example, equally well derive from another C class such as CActive, which, of course, itself derives from CBase. Although the interface is defined as a C class, you'll notice that a couple of the usual characteristics of a C class are missing. Firstly, the class has no explicitly declared constructor because it is an abstract base class and will not itself be constructed.2 In addition, although the class defines a static NewL() factory function, it does not define a ConstructL() method for second-phase construction. This is because the NewL() factory method of CCryptoInterface does not use standard two-phase construction, but instead calls ECOM to instantiate a suitable implementation object.

0 0

Post a comment

  • Receive news updates via email from this site