Symbian Developer Library


[Index] [Glossary] [Previous] [Next]

Subsystems and APIs


Symbian OS is a large system, containing hundreds of classes and thousands of member functions. Like most complex systems, it is easiest to approach by dividing it into large areas, and gradually narrowing your focus down to the areas that are most important to your tasks. The largest divisions that Symbian has found useful are called subsystems. For example, the Application Engines subsystem contains all the APIs that can be used to manipulate data for the standard applications such as Contacts.

Subsystems can be thought of by third-party developers for the most part of simply conceptual areas that group related functionality together. They aren't binary files such as DLLs, or source files such as headers, but it's still worth knowing about them though for a couple of reasons:

The documentation for subsystems is in turn divided up into APIs: groups of classes identified by descriptive English names. These too don't necessarily have a one-to-one relationship with binary libraries or headers, though there is very often a close correspondence. This is just because the requirements for those who need to understand and use the system are sometimes a little different from those of the system implementers. But the detail of libraries and headers are fully given in the API Reference documentation.



The subsystems

We can now look at particulars: the following figure shows the subsystems, followed by a brief description of each:



Note that some subsystems (Narrow Band Protocols, Web Browser, WAP Browser) do not currently have APIs available to third-parties. Subsystems concerned with PC connectivity are not shown.


The Base group of APIs cannot be ignored by any developer, whatever the type of program that is being written. An important fact to realise for the developer coming to Symbian OS for the first time is that certain fundamentals of programming are handled through class libraries specifically designed and optimised for phones, rather than through the standard C function library, or the standard C++ library (or that part of it known as the STL). This means that the Base APIs contain the classes that handle strings, arrays, lists, error handling, even basic types used for integers and real numbers. As the name implies, it also contains the APIs for genuine system programmers, who need to manipulate in detail system fundamentals such as threads, processes, and memory.

A good place to start to understand the Base APIs is Essential Idioms, which concentrates on the object oriented nature of the operating system, and the surprises that it might hold for those coming from other platforms.


The Graphics sub-component contains the APIs for drawing to particular types of phones, such as the screen and printers, embedding picture objects, and font and bitmap handling.

The sub-component also contains the Window Server Client-Side API, which provides functionality to draw to windows and receive window events, and the animation APIs which allow animations to be run in a high-priority system thread.

Application Framework

The Application Framework APIs include as their name implies the frameworks that define the application structure and their basic user interface handling. Applications here has a narrower sense than just program: it implies a program with a user interface, rather than say, a server program that runs in the background doing a system task. It can also imply a whole other group of requirements such as how the documents (data) that the application handles are presented to the user.

The scope of these APIs is actually a little larger than just that, as it also includes reusable frameworks for handling such things as text layout, user interface controls, and front end processors (non-keyboard input mechanisms, such as hand-writing recognition).

The phone manufacturer adds their own specialist APIs that provide user interface elements suitable for the screen and input mechanisms that it uses. However, the base classes for these and many of the key application concepts are defined by this subsystem.

Engines and utilities

The Application Engines APIs provide access to the application data of the core applications. This makes it straightforward for third-party applications to be integrated with the core applications, for example for a new communications application to store manipulate and read Contacts and Agenda data.

Alongside the Application Engines APIs, as specialist manipulators of data, are the Multi Media Server APIs, which provides audio and image manipulation, and the Application Services APIs, which provides a range of utility services to applications, from logging and system information, to vCard and vCalendar handling.


As you would expect from a phone OS, there is a rich group of communications related APIs. They are generally smaller and their use more specialist than some of the APIs we have previously discussed.

The Comms Infrastructure APIs provides frameworks and system services for communications and networking. It's required background for those wishing to use particular communications technologies such as Infrared, and Serial Comms.

At a higher-level, Messaging provides a framework for multi-protocol messaging and support for particular messaging protocols, and Telephony provides a comparable framework for telephony services. Finally, WAP Stack provides access to a WAP protocol stack.