in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Symbian os Expleined effective C++ programming for smartphones - Batchelor D.

Batchelor D. Symbian os Expleined effective C++ programming for smartphones - Wiley publishing , 2005. - 394 p.
ISBN 0-470-02130-6
Download (direct link): symbianosexpltivec++2005.pdf
Previous << 1 .. 98 99 100 101 102 103 < 104 > 105 106 107 108 109 110 .. 151 >> Next

A single REGISTRY_INFO structure is used to declare all the implementations of ECOM interfaces (identified by interface_uid) available in the plug-in DLL (identified by dll_uid). The details of each implementation are declared inside separate IMPLEMENTATION_INFO structures. The default ECOM resolver uses the default_data attribute to resolve a cue passed to a factory instantiation function. In addition, it is possible to customize the resolver to use the opaque_data attribute for lookup. Customized resolution can be useful to extend the selection criteria from those of the default ECOM resolver, for example by implementing case-insensitive lookup.
A customized resolver is actually an implementation of an ECOM interface, CResolver, and itshould thus be implemented in an ECOM plug-in DLL and registered with ECOM by supplying a resource file as described above. The interface_uid for CResolver is 0x10009D0 - you should always use this value in the resource file created for your custom resolver.
Such a resolver must implement the pure virtual functions IdentifyImplementationL() and ListAllL() declared in CResolver. It should also specify a factory creation function which takes an MPublicRegistry reference parameter; this object gives the resolver access to a list of implementations of a specified interface.
IdentifyImplementationL() should be implemented to identify the most appropriate implementation of a specified interface, according to a cue. It will use the MPublicRegistry object to obtain information about each implementation. ListAllL() must return a list of all implementations which match the cue.
class CCryptoResolver : public CResolver {
// Factory function
static CCryptoResolver* NewL(MPublicRegistry& aRegistry); ■^CCryptoResolverO; public: // From CResolver (see resolver.h)
/** Request that the resolver identify the most appropriate
interface implementation, returning the UID or KNullUid if no match is found */
TUid IdentifyImplementationL(TUid aInterfaceUid,
const TEComResolverParams& aAdditionalParameters) const;
/** Return a pointer to an array of all the implementations which satisfy the specified interface */
RImplInfoArray* ListAllL(TUid aInterfaceUid,
const TEComResolverParams& aAdditionalParameters) const;
... // Omitted };
The custom resolver may be used by the interface instantiation functions; for example, the CCryptoInterface::NewL() factory method may be extended to use a custom resolver as follows:
CCryptoInterface* CCryptoInterface::NewL()
{// The implementation instantiated is the first found by resolver _LIT8(KAny,"*");
TEComResolverParams resolverParams; resolverParams.SetDataType(KAny()); resolverParams.SetWildcardMatch(ETrue);
14.6 Example Client Code
So how does a client use an ECOM plug-in? As I have already described, the caller doesn't need to be aware of the details and simply uses the factory function supplied by the interface, supplying a cue if it is required. ECOM takes care of the details of locating and instantiating the appropriate implementation. An interface client must simply include the header files which define the interface, link against ECOM.lib and use the factory instantiation functions as appropriate:
#include "CryptoInterface.h"
void GetDefaultCryptoL()
{// Get the default implementation of CCryptoInterface CCryptoInterface* crypto = CCryptoInterface::NewL(); CleanupStack::PushL(crypto);
void GetSpecifiedCryptoL()
{// Use a cue - gets CCryptoInterface implementation which uses // hardware support _LIT8(KHardware,"HW");
CCryptoInterface* crypto = CCryptoInterface::NewL(KHardware); CleanupStack::PushL(crypto);
void GetAllCryptoL()
// Get all implementations using CCryptoInterface::ListImplementationsL() RImplInfoPtrArray infoArray;
// UID of the crypto resolver
const TUid KCustomResolverUid = {0x10008EE6};
TAny* cryptoInterface =
REComSession::CreateImplementationL(KCCryptoInterfaceUid, _FOFF(CCryptoInterface,iDtor_ID_Key), NULL, resolverParams, KCustomResolverUid));
return (reinterpret_cast<CCryptoInterface*>(cryptoInterface));
The third UID of an ECOM plug-in DLL is used to name its associated compiled resource, which contains its ECOM "registration" information.
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++) 1
1 // Retrieves default data for each TPtrC8 dataType = infoArray[i]->DataType(), crypto = CCryptoInterface::NewL(dataType); CleanupStack::PushL(crypto); // Use this as a cue
CleanupStack::PopAndDestroy(crypto); } }
14.7 Summary
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.
Previous << 1 .. 98 99 100 101 102 103 < 104 > 105 106 107 108 109 110 .. 151 >> Next