Dialog Box-based architecture
Unlike the traditional Symbian OS architecture, its controls are inherited directly from the dialog box class family.
The main advantage of the dialog box is that it requires less development work than controls derived directly from ccoecontrol because they automatically manage the layout of child controls. Construct and run in the Appui class: void csimpledlgappui: constructl () {baseconstructl (); iappdialog = new (eleave) csimpledlgdialog; iappdialog-> setmopparent (this ); iappdialog-> executeld (r_simpledlg_distack); addtostackl (iappdialog);} because the dialog box has no mode, executeld () will be returned immediately after the call. You must use addtostackl () to add the dialog box to the Control Stack, because the dialog box without mode cannot do this by yourself. Also, you must destroy this dialog box in the destructor of Appui: csimpledlgappui ::~ Csimpledlgappui () {If (iappdialog) {removefromstack (iappdialog); Delete iappdialog ;}
} (3) the avkon view switching architecture is more complex than the first two. Another class is introduced as the medium between Appui and container. In addition, the Appui class inherits from caknviewappui, rather than caknappui. In the first two architectures, appui is directly responsible for view switching. It must manage the instantiation, deletion, and display of view submission controls. However, caknview-based classes can significantly reduce Appui tasks in this respect. The Appui still processes the view switching request, but now it does not delete the old container and instance the new container. The Appui only needs to call one of its special views to activate the function, for example, activeviewl (). These special caknviewappui functions submit an activation request to the view server, and then enable/disable member functions in the relevant classes based on caknview, the view server explicitly coordinates the activation of the current view and requested view. The general features required for this architecture are as follows: l the application must be designed so that each avkon view derived from caknview has a container, and then the Appui has each avkon view. L The Appui of the application must be derived from caknviewappui, rather than from caknview, because the former provides methods for registering, activating, and disabling the avkon view. L all avkon views must be registered on the view server. L avkon view has activated/disabled member functions. View servers can directly call these functions. These functions must be rewritten to provide proper processing for subordinate containers. The main principle of view server is to determine that only one avkon view is activated in each application at any given time point. The avkon view identifies itself to the view server through two UIDs: One uid is used to indicate the application that owns the view, and the other uid is used to uniquely identify the view in the application. For each caknview-based class, the activation/prohibition functions to be implemented are doactivel () and dodeactivate (). These functions are used to instantiate, display, or delete the UI controls of the avkon view. The view server will take the initiative to call deactivateview (), so as to force each application to have only one rule to activate the view. How to Use avkon view to switch the architecture: l when using this architecture, the caknviewappui and caknview classes must be used in combination. Each avkon class is derived from caknview and must contain an ID () function, so that the system can mark this class. It must also implement the doactivatel () and dodeactivatel () functions. In addition, it must implement the handleforegroundeventl (), handlecommandl (), and handlestatuspanesizechange () functions for processing various events. L when a user requests to activate the view, the view server calls doactivatel (). The purpose of this function is to instantiate and display the control of the submit view. Note: You can call doactivatel () multiple times before dodeactivatel (). L when you want to disable the avkon view, dodeactivatel () is called. This function is responsible for destroying its controls. When an application exits or another view of the same application is activated, the view is disabled. This function cannot exit unexpectedly. L handleforegroundeventl () is called only when the avkon view is activated, that is, between doactivatel () and dodeactivatel. When the view arrives at the foreground, it receives handleforegroundeventl (etrue). When the view is removed from the foreground, it receives handleforegroundeventl (efalse ). Programmers may want to use this method to set focus or control screen updates. Handlecommandl () is called when a command is generated in the View menu. handlestatuspanesizechange () is called when the user's rectangle size is changed due to the status panel change (). To allow the avkon view to define its own soft keys and menu resources, you can (. create an avkon_view resource in RSS, and pass the resource ID to the baseconstructl () function of the view. Generally, all avkon views in the application are constructed in the constructl () method of the Appui object. Use addviewl () to register these avkon views on The View server, and activate the initial view by setting the default view. Use setdefaviewviewl (). Note: commands not processed by avkon view are passed to Appui. In the handlecommandl () method of Appui, only commands for switching between views are performed. Local view switching or application view switching are all performed by referencing the UID of the target avkon view. To perform external view switching, call the ccoeappui: activateviewl () function to provide a tvwsviewid that contains the UID of the target application and the UID of the target view. For example, const tuid kphonebookuid = {0x101f4cce}; // from pbkuid. hconst tuid kphonebookcontactviewuid = {1}; activateviewl (tvwsviewid (kphonebookuid, kphonebookcontactviewuid); Note: if some views in your program can be used by other programs, then we must publish the UID of the application and the UID of the view by exporting it as the header file.
