Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


Introduction to the ECom architecture

In C++, the existence of abstract base classes and virtual functions means that programs can call, or access, interfaces without knowing the class that provides the implementation. This is a useful mechanism that allows an implementation to be written some time after the interface has been defined. Such implementations are known as plug-ins.

In early versions of Symbian OS, such implementations were provided by polymorphic interface DLLs. This meant that all frameworks within Symbian OS that wanted to use plug-ins had to provide their own mechanisms for clients to discover and instantiate the available implementations.

ECom removes this duplication of functionality by introducing a generic framework that provides a single mechanism to:

To show how ECom does this, let's recap the essentials of any plug-in system.

A client wishes to access an object to perform some processing. The specifics of this object are not known until run-time. The general characteristics of the processing are known, and are defined in an interface, but several variants of required processing could exist, which are provided by implementations that support the interface.

There are four clearly-defined roles in such a system.

The relationships are shown in a UML diagram below:

Plug-in relationships


Plug-in relationships

The instantiation mechanism forms the backbone of such a system, and is responsible for providing the services that identify, and load the correct interface implementation at run-time. ECom is such a framework.

We'll now look at the system from the perspectives in turn of each of the interface client, interface implementation, and interface definition, before summarising the functions of the ECom.