246

ECOM

CCryptoInterface::ListImplementationsL(infoArray);

//infoArray is not leave-safe, but use of the cleanup stack is

//omitted for clarity. See Chapter 3 for more information.

...

CCryptoInterface* crypto;

for (TInt i =0; i< infoArray.Count(); i++)

{

// Retrieves default_data for each

TPtrC8 dataType = infoArray[i]->DataType();

crypto = CCryptoInterface::NewL(dataType); // Use this as a cue CleanupStack::PushL(crypto);

...

CleanupStack::PopAndDestroy(crypto);

}

}

14.7Summary

This chapter covered the important concepts behind the ECOM architecture, which provides services to locate, resolve, instantiate and manage instances of polymorphic plug-in DLLs.

The chapter discussed how to define an abstract interface and how to implement it in an ECOM plug-in DLL. The example showed how to implement two concrete implementation classes for a fictional cryptographic interface, within a single polymorphic plug-in DLL. For this reason, an ECOM plug-in DLL is also known as an ”ECOM Interface Implementation Collection”, and assigned a targettype of ECOMIIC.

The chapter also described how an interface client can use factory methods provided by the interface to instantiate concrete instances thereof, without having any knowledge of ECOM itself. The factory instantiation functions, provided by the interface, call the ECOM framework using REComSession::CreateImplementationL(). The ECOM framework uses a default or customized resolver to examine the registry of interface implementations and instantiate an object of the appropriate class. An interface client should simply include the header files which define the interface and link against ECOM.lib.

Chapter 13 discusses generic polymorphic plug-in DLLs and Symbian OS DLL loading in more detail.