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 as conceptual areas that group related functionality together: they aren't binary files such as DLLs, or source files such as headers. The system documentation in the Symbian OS Library uses them consistently to divide up functionality.

Subsystems are composed of components (defined by a bld.inf file) which are built to make up the operating system. The API Reference documentation is divided by these components. A component can have several libraries or headers: the details of what to link against or include to use an item are given in the item's page in the API Reference.

When describing large components, it's sometimes also useful to break down functionality into smaller areas. For example, the E32 component (the kernel) in the Base subsystem, has many areas of functionality, including descriptors, threads and processes, and memory management.

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

(Note that the placing of the blocks on the diagram roughly reflects whether the subsystem has a higher or lower level, but is not intended to provide a map of the subsystem dependencies).

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 small-memory devices, 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, and even the 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 System libraries (Syslibs) APIs build on the base APIs to provide a large number of useful general APIs. These include storage (central repository, database, structured stores), an implementation of the standard C function library, and the ECom plug-in framework.

The Security subsystem contains the components that provide cryptographic algorithms, certificate management, and the application installer, which has secure features.

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

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

The Application Framework subsystem includes, as the 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 is 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).

A licensee product adds its own specialist components that provide user interface elements suitable for its particular screen and input mechanisms. However, the base classes for these and many of the key application concepts are defined by this subsystem.

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

Further subsystems provide specialist manipulators of data.

Application Services provides a range of utility services to applications, from logging and system information, to vCard and vCalendar handling.

Application Protocols subsystem contains components for using the Web HTTP protocol, and associated utilities.

Multimedia provides audio and image manipulation.

SyncML provides an OMA (SyncML) data synchronization client, and OMA Device Management v1.1.2 support.

As you would expect from a mobile phone operating system, 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, Bluetooth, and Serial Comms. Networking also builds on the Comms Infrastructure, to provide a TCP/IP stack, and dial-up connections.

Telephony provides application access to the phone's telephony functionality, and a framework for writing drivers for particular telephony hardware. Narrow Band Protocols provides handling of SMS messaging.

At a higher-level, Messaging provides a framework for multi-protocol messaging and support for particular messaging protocols. WAP Stack provide access to a WAP protocol stack and WAP Browser adds support for WAP Push.