View and container in Symbian

There is a template for developing a Symbian GUI application. You can use the carbide C ++ Project Wizard to automatically generate the basic framework of the program. However, it may be related to the installed SDK version. Currently, I can only generate a general container template for one Appui. (in the past, I used 2nd fp3 to generate view templates for multiple views and multiple container ).

No matter which template, the common parts of them are the entry function, application, and document. That is, the following three files are available to all projects:

1) there is a CPP file with the same name as the project. It only provides two global functions. It is the entry to program execution and is responsible for creating applications. We don't need to worry about this file.

2) There is a class named after the project name + application, derived from caknapplication, which is responsible for creating the document class and providing the UID of the application. In general, it does not require us to worry about it, but because it provides a function openinifilelc, if we need to load the configuration in the INI file when starting the program, we can reload it.

3) There is a class named after project name + document, which is derived from cakndocument and is responsible for creating the UI class. In general, we don't care about it, but it also provides a function openfilel, to load a common file, you can also load it.

Let's take a look at the differences between the two templates.

1. conventional mode based on ccoecontrol

This mode is characterized by an Appui class and corresponds to a container class.

In addition to the above three files, it also has the following two files:

4) there is a class named after project name + Appui derived from caknappui. Its main task is to take charge of the user interface (so-called UI) and create a container class, so it is one of our focuses.

The most important member function is handlecommandl, which is from the ceikappui class and is responsible for processing various naming/events.

There are two functions: dyninitmenubarl and dyninitmenupanel. to dynamically change the menu items, You can reload them.

The handlekeyeventl function can be reloaded when you need to handle keyboard events by yourself.

In addition, this Appui provides some common functions, such:

Document () can get the Document Object Pointer.

Application () can get the application object pointer.

Statuspane () can get the pointer of the status bar.

CBA () can get the pointer of the control bar.

5) there is a class named after project name + container derived from ccoecontrol, which is responsible for displaying the content, which is also the focus of our attention.

If you need to add the control class on the interface, it is implemented in this class. In general, it is responsible for all the items related to the interface display.

It has a draw function, but if we use controls to display information, the code in this function seems to have little to do with us, unless our interface is completely drawn.

The other two functions, componentcontrol and countcomponentcontrols, respectively obtain the control and the number of controls. They are more important in GUI applications that depend on the control display.

Because it implements the mcoecontrolobserver interface, the handlecontroleventl function also needs to be implemented.

You can use its member icoeenv to obtain the pointer of the Appui class, but you need to force a transformation, such as static_cast (cimusicappui *, icoeenv-> Appui ()->...

Ii. MVC mode based on caknview

This mode adds an appview class between the Appui class and the container class, that is, an Appui object, N appviews, and N container.

In addition to the public three files, it includes the following files:

4) there is a class named after the project name + Appui, derived from the caknviewappui class. In fact, it is also indirectly derived from the caknappui class, and its job responsibilities are basically the same as the Appui class in the general mode.

The only difference is that it does not directly create the container class, but creates an appview class and creates multiple appview classes. At the same time, it also needs to add the created view to addviewl in the view stack.

 

Cimusicviewmusic * view1 = new (eleave) cimusicviewmusic;
Cleanupstack: pushl (view1 );
View1-> constructl ();
Addviewl (view1); // transfer ownership to caknviewappui
Cleanupstack: Pop (); // view1

Cimusicviewfavt * view2 = new (eleave) cimusicviewfavt;
Cleanupstack: pushl (view2 );
View2-> constructl ();
Addviewl (view2); // transfer ownership to caknviewappui
Cleanupstack: Pop (); // view2

Cimusicviewweb * view3 = new (eleave) cimusicviewweb;
Cleanupstack: pushl (view3 );
View3-> constructl ();
Addviewl (view3); // transfer ownership to caknviewappui
Cleanupstack: Pop (); // view3

This-> activatelocalviewl (kviewmusicid );

5) There are multiple classes named after the project name + view, derived from the caknview class. It is responsible for processing part of the Appui events, so it also has the handlecommandl function.

In addition, its doactivatel and dodeactivate functions are called when the current view is activated or disabled, and need to be reloaded.

When activating the container, you need to create the container class corresponding to the view, call the setmopparent of the container as your own, and add the container to the stack in the Appui of the upper layer. The general code is as follows:

 

Icontainer = new (eleave) cimusiccontainerfavt;
Icontainer-> setmopparent (this );
Icontainer-> constructl (Appui ()-> applicationrect ());
Icontainer-> listtype = type;
Appui ()-> addtostackl (* This, icontainer );

Note that its Appui () can get the Appui object pointer on its upper layer.

The opposite is true when inactive.

If (icontainer)
...{
Appui ()-> removefromviewstack (* This, icontainer );
}
Delete icontainer;
Icontainer = NULL;

6) There are multiple classes named after the project name + container, derived from ccoecontrol and implemented the interface mcoecontrolobserver, so its behavior is similar to that in the general mode of container.

This mode can effectively organize applications and cut them into several modules (Views) Based on Multiple Functional interfaces of applications ). Multiple appviews are used to share the event processing in the Appui, and are responsible for the specific behavior and display in the view.

Switching between views is also simple:

Static_cast (cimusicappui *, icoeenv-> Appui ()-> activatelocalviewl (kviewmusicid );

[Supplement]

Three comparison Modes

Some textbooks have also proposed the dialog box mode, but I don't think it is practical, and I have never paid attention to its structure.

Compared with the above two architecture templates, it is clear that the second view-based template should be more practical unless the program is really simple.

However, the "View" here is easy to misunderstand. Generally, when we talk about MVC, the Model-View-controller, but here the appview actually corresponds to the Controller, while the container corresponds to the view.

Therefore, in the new SDK, the Class Name of the ccoecontrol source in the project generated by the wizard in the first template is changed to appview, which corresponds to the Appui class that inherits from the caknappui controller. Because I didn't see the code generated by the multi-view project, if so, I should change it accordingly.