Symbian's application is generally divided into engine and UI, where the engine is responsible for describing logic issues such as algorithms, data structures, and UI processes the drawing, the user interface, etc. External properties.
Series 60 SDK draws on some of the MS VC, such as the structure of App-Document-View, but Main Frame is omitted, which should be a reasonable hierarchy based on the characteristics of mobile terminals. People who wrote VC on the structure of the document-view should have a thorough understanding, in general, Document is responsible for data, and VIEW is responsible for the UI, which is data display, drawing and other functions. View gets Document via GetDocument and rely on its completion of user action and synchronization. If you write kjava, then you may wish to understand the view into Canvas, although they have their own nature.
When you create a new Series 60 project with VC Project Wizard, you can select one in two templates of Eikon Control and Dialog Based, and there is a check item with a View architecture.
Eikon is based on all the UI libraries of the EPOC device, which is roughly divided into two categories, and one is the call for data access (calls related to Document), and the other is the control of various UIs. If you choose EIKON this template, the application's main view will inherit from the CCoecontrol class, if you select Dialog Based, Main View will inherit from CeikDialog.
The View architecture is a new frame type. If this framework is used, the application consists of a series of View, each of which has a normal UI performance, such as its own UI stack.
CCoecontrol is actually a base class for all control classes. All control classes in the S60 SDK are derived by it, check its function, know what this category is: capturespointer (), ActivateGc (), ISFocused (), retrogravals its class inheritance tree, see, these are from it: CeikalignedControl, CeikBordRoTrol, CeikButtonRoupContainer, CeiklabeledButton ... Hoho, is it very similar to Windows CWND? ? Take a look at its parent class, it is directly CBASE. Obviously, if Eikon Control is selected, you have to start from the grassroots, step by step, slowly practicing, achieving a variety of logic, and finally get a Hello World, but also tired of it.
Where is CEIKDIALOG? Class Index is not found, look for EikDialog.h, look at its definition:
Class CeikDialog: Public CeikborderedControl, Public McoecontrolpageObserver, Public MakDialogpageObserver, Public MaknfadedComponent, Public MaknfadedComponent, Public
It's a botherst, so many interfaces, it's not a study here, interested, you can go through what functions have been turned over. However, it should be seen from this statement. CEIKDIALOG is actually packaged in Dialog. If you use Eikon to use Windows SDK, then CeikDialog seems to use MFC, huh, huh, sorry, old, MS. Don't be flat! In addition, what often is Avkon, Avkon? The SDK is defined as: extension on uikon. What do I think is similar to the above-mentioned extension API? Ask someone to point ... Let's take a look at the SDK Help:
Traditional application framework (select Eikon framework):
Symbian App Generally uses the control from CCoecontrol as an application as an application's view, which is the Dongdong that can be seen, these controls are thrown in the application control stack, can be created, destroyed according to the application requirements. Show or hide.
This approach is ideal for Avkon applications, and the most flexible way of building applications. If you use a View system, it is clear that it is not able to use the VIEW management system provided by the system, but this is its biggest advantage, because it is not VIEW management restrictions provided by the system.
There are many ready-made application frameworks if you find that it is very similar to your needs, then you can borrow a ...
Oh, I understand, if Eikon's framework, you can do a lot, the system is very small, if you have enough metamorphosis or want to use the underlying to do some things that come out, then believe it, yes. However, in order to improve the development efficiency, it is best to see if there is any ready-made thing to borrow it. If repairing is used, it will be much more.
Let's take a look at the dialog-based framework:
The dialog framework applies to most of the display modes are applications in the form of dialog boxes, such as the main view is a dialog. The advantage of using the dialog is that its contents and layouts can be done by modifying the resource file without using any C code, but it is important to note that the nesting dialog is easy to take up a lot of stack space, so be sure Be careful to be careful.
Hoho, Document Recommendation If you use a dialog as a master view (window), it is best to run when a non-modal dialog is run. why? It is estimated to be due to various switching needs.
Speaking of the dialog, I have to say MS, do you wast a waste of money to buy an egg? In vc, code and resources are separated, S60 also draws this idea, which defines all CLIENT regions, titles, and controls contained in the dialog box, and the resource file name suffix is RHR, RSS There is also a .loc, content and VC String Table. For example, after establishing a project with a dialog-based framework, the resource file will appear similar definitions:
RESOURCE DIALOG r_test4_dialog {flags = EEikDialogFlagNoDrag | EEikDialogFlagNoTitleBar | EEikDialogFlagFillAppClientRect | EEikDialogFlagCbaButtons | EEikDialogFlagModeless; buttons = R_AVKON_SOFTKEYS_OPTIONS_BACK; items = {DLG_LINE {id = ETest4Dlg1Label; type = EEikCtLabel; control = LABEL {txt = "";};}};} flag that Tap is very familiar, and the precreateWindow (CreateStruct & Cs) in Windows is a bit similar. This FLAG is quite important, it sets a lot of properties, for example, modal non-mode can be set by eeikdialogflagmodeless. All of these logos can be found in avkon.hrh, and its meaning can be understood by name.
The View framework is Symbian V6 DFRDS (DFRD: Device Family Reference Design. All Products from the Same DFRD Are Aable To Run The Same Thrid Party Software, Content and Services.) Start support, in order to more suitable for the feature of S60 applications, avkon is here It has made some optimization and expansion. This framework allows applications to register a variety of views, so-called view, it is actually similar to the window, can be created, destroyed, activated, hidden. Each application can only have an activated view. This is activated, that must be hidden. When View hides, all menus, dialogs, dialogs, or other applications embedded in this view will be allocated, Of course, applications can also allow end users to control switching (activation or hidden) between various VIEWs, it is important to note that if a switching may abort the application, then this switching must be able to protect the scene, in addition, if it is applied Program A switches to the application B, then returns from B to A, when A does not automatically activate his view, and the program is processed to handle itself, which is very different from the Windows program.
View is identified by a UID in the management system. The View management system uniquely identifies a view through this UID and implements the schedule for them. In the application implemented by the VC App Wizard, the main view is inherited from CaknView, There is a pure virtual function ID () in CaknView, which is a must be overloaded and used to get the identity of the view. The ID can be defined by himself, as long as you don't repeat it.
Another use of View is as a message delivery intermediary, I believe that the mechanism to pass this mechanism may be more clear, and it is no longer nonsense. Why is View to handle messages? Because in applications written in traditional frameworks, View does not directly control the display page, and Windows is similar, if you want a Window dry point, the most appropriate method is to throw a message to it.
Let's take a look at the function of CaknView and messaging:
public: · IMPORT_C void ActivateViewL (const TVwsViewId & aViewId) · IMPORT_C void ActivateViewL (const TVwsViewId & aViewId, TUid aCustomMessageId, const TDesC8 & aCustomMessage) · virtual IMPORT_C void HandleStatusPaneSizeChange () · virtual IMPORT_C void ProcessCommandL (TInt aCommand) · virtual IMPORT_C void HandleCommandL (TInt aCommand) · virtual IMPORT_C void AknViewActivatedL (const TVwsViewId & aPrevViewId, TUid aCustomMessageId, const TDesC8 & aCustomMessage) protected: · virtual IMPORT_C void DoActivateL (const TVwsViewId & aPrevViewId, TUid aCustomMessageId, const TDesC8 & aCustomMessage) = 0 · virtual IMPORT_C void DoDeactivate () = 0 · IMPORT_C void ViewActivatedL (const TVwsViewId & aPrevViewId, TUid aCustomMessageId, const TDesC8 & aCustomMessage) · IMPORT_C void ViewDeactivated () · IMPORT_C TVwsViewIdAndMessage ViewScreenDeviceChangedL () · virtual IMPORT_C void HandleForegroundEventL (TBool aForeground) can be seen, news mostly generated when View is activated or hidden, Headache is that the SDK Help does not explain the above parameters. I don't know which person can explain it in detail? ? It should be noted that this call may be triggered in the case where this View has been activated, so this function must be able to self-judgment your state and make corresponding processing, or may result in some unexpected situations. The simplest processing method is to simply return Return when you find that you have activate it.