Application Framework

Series 60 UI applications rely upon a number of OS components to operate . Many common application requirements, such as screen drawing and the persistence of application data, need not be programmed from scratch into the application by the developer ”this would be like reinventing the wheel. Instead, an application's common requirements are satisfied by various servers in the OS. For example, the Window Server provides extensive UI support, and the File Server lends support for persisting data.

The application framework constitutes a set of core classes that are the basis of all applications. These classes form the structure of all applications, and they also encapsulate interplay between the application and required OS servers.

This section provides background information concerning the design of the Series 60 application framework. It shows how Series 60 framework classes derive from, and functionally augment, generic Symbian OS framework classes. This contextual information will help you to better understand and more effectively use these APIs and will prepare you for the class-specific discussions in the Application Architecture section.

Primarily, Figure 4-1 shows conceptual groupings of the application framework classes. It also shows real API classes contained within these groupings, and inheritance relationships between them:

Figure 4-1. The application framework classes for an Avkon View-Switching application.

The architecture used here will be explained in detail in the Avkon View-Switching Architecture subsection later. Note that Figure 4-1 is a UML class diagram that shows four class layers , omitting associations, mixin classes and derivations from CBase for clarity.

The first layer in the class hierarchy is divided into two fundamental components, namely AppArc and CONE .

AppArc stands for "Application Architecture." These classes provide the basic application structure, and mechanisms for delivering system information to the application and persisting data using the File Server. This is a Symbian OS category, and classes in it are named with the prefix " *Apa " ”for example, CApaApplication .

CONE is short for "CONtrol Environment," and the classes in this component provide mechanisms for handling user input and creating the User Interface ”these classes interact primarily with the Window Server. (Briefly, the Window Server is a Symbian OS Server that controls drawing and handles user input.) Again, this is a Symbian OS component, and classes in it are named with the prefix " *Coe " ”for example, CCoeControl .

Remember that a Symbian OS Server is a program, without a UI, that runs in a separate process and manages (possibly shared) resources. A client-side API is provided, with parameters passed over the process boundary.

The second layer of classes fit into the Symbian OS Uikon component. This is a generic, device-independent implementation of highly functional, nonabstract framework classes, and provides a UI library layer that is common to all Symbian OS platforms. Some concrete UI controls, for example, list boxes and scroll bars, can be created in this layer and these are sometimes called Eikon controls. Note, however, that Avkon (Series 60-specific) controls should always be used in preference to Eikon controls, as they provide the correct behavior for Series 60 applications. Classes in the Uikon/Eikon component are named with the prefix " *Eik ", for example, CEikApplication .

The third layer consists of the Avkon classes, and these provide core Series 60 UI functionality, such as menu support. This layer is a purely Series 60-specific implementation, and your application should always derive from the Avkon classes in preference to generic Symbian OS classes. The Avkon classes are named with the prefix " *Akn " ”for example, CAknApplication .

The fourth layer, the application-specific layer, demonstrates how you would derive from the Series 60-specific Avkon classes in order to design custom applications. Please note that this layer of Figure 4-1 is application architecture-specific and the classes from which you derive may vary, depending upon UI requirements. The Application Architecture section will address these issues.

Many of the classes in the first layer are abstract and merely define the interface to the framework APIs. The second layer adds a common Symbian OS implementation, and this will be shared with other Symbian OS UI platforms. The third layer adds a Series 60-specific implementation to the framework, and the fourth layer adds custom application implementation.

The next section will discuss the core application framework classes in more detail and examine their relationship with each other and the system in general.