A brief analysis of Symbian application framework

The operation of S60 applications relies on a large number of OS components, such as screen drawing and application data persistence, that can be directly used by Windows servers or file servers on the OS.

Application Core Framework Classes

The application framework consists of a core set of classes that are the foundation of all application frameworks. These classes encapsulate the interaction between the application and the required OS servers.

First layer: CBase and cactive two base classes, where cactive is also derived from CBase, and cactive is derived from the second layer of cconenv

Second tier: Contains two basic components: Apparc and cone. APPARC represents the application architecture, which provides the basic application structure, the mechanism for submitting system information to the application, and the use of File server persistence data. The classes are named with the prefix "*apa". The cone is the abbreviation for the control environment in which classes provide the mechanism for handling user input and creating user interfaces-These classes are primarily used to interact with window servers, where classes are prefixed with "*coe" when named. Many of the classes in this layer are abstract classes that define only the interfaces of an API.

Third layer: Uikon components. This is a generic device-independent implementation with rich functionality, non-abstract framework classes, and provides a common UI library layer on all Symbian OS. Some specific UI controls, such as list boxes and scroll bars, can be created at that level, and these controls are sometimes referred to as Eikon controls. Classes in the Uikon component are named with a prefix of "*eik". Added a common Symbian OS implementation, shared with other Symbian OS UI platforms.

Layer Fourth: Consists of Avkon classes that provide core S60 UI features, such as menu support. The class of the Avkon control is named with a prefix of "*akn". Add S60-specific implementations to the framework.

Layer Fifth: Design your own application for the layer of the application, adding custom application implementations.

The classes mentioned above are simply: views, documents (document), Applications (application), application UI (application UI). So how does a S60 UI application use these classes to implement its organic program, which involves an initialization problem with an application framework.

Application Framework Initialization

You must create each of the following methods to provide the smallest S60 application:

A, Frame entry: All S60 UIs Implement a global Function E32dll () (The Global Entry function for a non-UI class is E32main), and when the application starts, the framework will call the function first, which is also called the DLL entry point, and the application must exist for that function. Each S60 UI application is a polymorphic DLL.

b, New application instance: Let the Framework Call Newapplication (), which is the only function exported by the DLL, responsible for creating an instance of the application class and returning its pointer, which the framework later uses to complete the creation of the application. Here the application instance is created on the heap using the "new" method rather than the common "new" method of the Symbian OS, because the trap harness (Eleave) has not yet been created. If the system cannot allocate memory for a new instance, the returned pointer is null, and the application framework can check and handle the problem.

C, return UID: Appdlluid () Called by the framework returns the application's UID. The function must return the UID value specified in the. mmp file, which can be used to determine whether an instance of the application is running. If an application is running and another instance of the program is started, the running program will be switched to the foreground instead of regenerating one.

D, New document instance: The framework invokes the CREATEDOCUMENTL () function of the application class instance through the framework to obtain a pointer to the newly created instance of the document class. With the document instance pointer, the framework can invoke some of the functionality of the document instance, and the document instance also invokes its own NEWL () and NEWLC () dual static constructors (why the dual constructs, which is related to Symbian's exception handling mechanism, And I'm not quite sure what I'm designing as a static function to create myself.

E, whether to mount the file: The framework calls Appdlluid () to see if you want to mount a file from the file system. (It seems to be related to some permanent storage information, the current project does not use this function, I do not know how to use this)

F, new Appui and view instances: The framework generates a APPUI instance and gets a pointer to it by calling the Createappuil () method of the Document object. Here the APPUI instance creates itself using the C + + default constructor and returns a pointer to the instance, after which the framework uses the pointer to call the CONSTRUCTL () function of the APPUI instance to complete the construction. The first call in this constructl () function is the Basecontructl () function of the Appui base class, which handles the reading of the resource associated with the program, followed by the new instance of the view class that needs to be loaded (through a double construct). If you need to call the ADDVIEWL () function to load a new view instance in more than one view, the default default view is set by the SETDEFAULTVIEWL () function at the end of multiple view. such as reading a resource file related to the program appui called the NEWL function of the Appview class to generate the example, and here is the double construct

G, view redraw: Through the above creation process, the framework already has the view's infinite dispatch right, at this time if has the general System event Framework can call view's draw () function through the window server, as these system events generally refer to the program to start, The application gets focus or the options menu disappears, and so on. It is important to note here that programming developers are not able to invoke draw directly, requiring that the graphics context of the system be activated before the call, and that the Drawnow () method can only be invoked if the programmer wishes to redraw the screen. Also, the draw function cannot exit abnormally because the function can be invoked directly by the framework, and the framework does not know how to handle the possible exceptions. So draw itself needs to catch and handle possible errors.

h, processing commands: After completing these steps, the user can invoke the Handlecommandl () function with an interactive UI such as a menu option, and pass a parameter acommand that indicates the user's choice of command. Handlecommandl () will then judge different commands to schedule execution separately. Another place to note here is that if you want the view instance of your program to also respond to a user's key, you must add the view instance through the Appui Addtostackl () function to the control stack of the APPUI instance.

For the above invocation method implementation, the individual felt it necessary to appui several important event processing methods listed:

Handlewseventl () is used to handle events passed by the window server, which makes the framework invoke the following concrete event handling methods;

Handkeyevent () is used to handle user key events (this function is called when the control stack is empty, or the frame will call the Offerkeyeventl () function);

HANDLEFOREGROUNDEVENTL () This function is called when the application switches to the foreground or switches from the foreground to the background, and the default implementation can handle the change of keyboard focus;

Handlesystemeventl () is used to handle events generated by the window server;

Handleapplicationspecificeventl () is used to work with custom events that you define. The default implementation can handle notification of color scheme changes;

Handlecommandl () is used to process user-selected menu items;

Handleswitchoneventl () is used to handle specific switching events such as device switching;

Handlemessagereadyl () is used to handle message events generated by the window server.

In the above function processing events, except the first handlewseventl () function, the other functions are pure virtual functions by default and need to be overloaded.

After you have initialized the steps for the application framework, a complete framework is created.