Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 64
Текст из файла (страница 64)
Beneath the GUI variant, Symbian OS defines the following levels of UI and application frameworks:• Uikon is the most abstract framework. It defines the generic application framework, free of any ‘look and feel’ policies, from whichGUI variants derive a concrete framework implementation. It includesbase classes derived from, as well as concrete classes used by, thederived application frameworks.• Application Architecture 5 provides a less abstract implementation ofUikon interfaces that define the UI-independent application lifecycleand responsibilities, including the relationships between applications,data, and resources.• Control Environment 6 provides a less abstract implementation ofUikon interfaces to supply base classes and an environment forabstract UI controls. These controls are window-using, possiblynested, rectangular screen areas that accept user input and systemevents. In particular this framework provides abstract interfaces forgraphics contexts, the windowing model, and event dispatching.All Symbian OS applications derive their basic application classesfrom GUI variant base classes, including (from v9) application viewbase classes.
Table 9.1 shows a mapping between the base Symbian OSframework classes, the GUI variant base classes used by applications andthe classic MVC model.As Table 9.1 shows, there is no immediate equivalent for the SymbianOS Application class in the classic MVC model and MVC views canhave a number of alternative implementations in Symbian OS applications.5 Also6 Alsoknown as AppArc.known as CONE.340MAPPING WELL-KNOWN PATTERNS ONTO SYMBIAN OSTable 9.1 Model – View – Controller Inheritance HierarchyS60 Base ClassUIQ Base ClassSymbian OS BaseClasses andAssociated FrameworkClassic MVCEquivalentCAknApplicationCQikApplicationCEikApplication(Uikon) extendsCApaApplication(AppArc)N/ACAknDocumentCQikDocumentCEikDocument(Uikon) extendsCApaDocument(AppArc)ModelCAknViewAppUiand, for non-viewbased applications,CAknApUiCQikAppUiCEikAppUi (Uikon)extends CCoeAppUi(CONE)ControllerCAknView and, fornon-view-basedapplications,CCoeControlNB: All S60 viewbase classes arecontrol-owning, i.e.they own an instanceof a CCoeControl.CQikViewBase (for‘single page’ views),CQikMultiPageViewBase (for‘multi-page’ views),and CQikViewDialog (for simple‘dialog’ views).CCoeControl (CONE)ViewNB: All UIQ viewbase classes areCCoeControlderived i.e.
they arecontrols.The following code fragments demonstrate the degree to which aSymbian OS application follows a generic structure, irrespective of theGUI variant it targets. The variations between S60 and UIQ certainlycannot be ignored and in some cases are quite subtle. They can, however,be quite easily identified and isolated.ApplicationThe top-level application class binds the application into main applicationframeworks and hence into the application lifecycle.In the code for an Application class, the only difference betweenS60 and UIQ is the base class derived from.
In either case, you stillneed to implement the entry point that the framework uses to launchMODEL–VIEW–CONTROLLER341the application as well as a method to return the application UID. Thisclass is also responsible for the next object in the chain, the applicationDocument, whether or not it is seriously used.class CMyApplication : public // CAknApplication OR CQikApplication{public:// Return Application’s UIDTUid AppDllUid() const;protected:// Create the documentCApaDocument* CreateDocumentL();private:// Called by the framework to create a new application instanceCApaApplication* NewApplication();};DocumentThis class was intended to encapsulate the application data and core logichowever it is usually not seriously used though it still needs to be providedto allow the application to interact with the application frameworks.
Theclass is responsible for creating the next object in the chain, the AppUi.If it is used in earnest, such as by a file-based application, the documentreads its initial state from a file. Again the only difference between S60and UIQ is the base class derived from.class CMyDocument : public // CAknDocument OR CQikDocument{public:// Constructors / destructor omitted// Create the App UICEikAppUi* CreateAppUiL();};AppUiThe AppUi provides the application-specific handling of events givento it by the application frameworks as a result of system events such asthose generated by the end user. It is generally responsible for creatingthe application’s model and drives it as a result of these events.In addition, the AppUi provides the UI classes and defines the commands which are called from the menu choices command switch handler.It does this by creating the main default view and registers it with theframework although it is not expected to destroy the view.342MAPPING WELL-KNOWN PATTERNS ONTO SYMBIAN OSThe responsibilities of the AppUi class differ between S60 and UIQ.In S60, the AppUi is responsible for command handling, which followsthe original Symbian OS pattern; in UIQ3, a new command-handlingframework moves responsibility for command-handling to view classes,enabling commands to become view-specific.class CMyAppUi : public // CAknAppUi OR CQikAppUi{public:// The application frameworks requires the default C++ constructor to// be publicCMyAppUi();...private:// The AppUi owns the main application viewCMyAppView* iAppView;private:// S60 apps only, cf.
new UIQ command-handling frameworksvoid HandleCommandL(TInt aCommand);void HandleStatusPaneSizeChange();};ViewS60 and UIQ diverge most significantly in the way that they handleviews, reflecting important, but subtle, differences in the underlyingtreatment of views and, in particular, of view switching. In UIQ, DirectNavigation Links7 enable applications to drive views belonging to otherapplications; in S60, on the other hand, applications typically collaborateusing embedding. Both view derivation and view responsibilities andbehavior are different between these GUI variants.The following is a conventional S60 view class, which is derived fromCCoeControl; more recent S60 view classes differ in that they are notcontrol derived, but do own controls:class CMyS60View : public CCoeControl{public:// Constructors/destructor omitted// Handle drawing and size changesvoid Draw(const TRect& aRect) const;virtual void SizeChanged();};The UIQ application view derives from one of the new UIQ view baseclasses which are themselves derived from CCoeControl:7 SeeUIQ 3 SDK UIQ Developer Library UIQ Style Guide 5 Navigation.MODEL–VIEW–CONTROLLER343class CUIQTeomplateView : public CQikViewBase{public:// Constructors/destructor omitted// Return a globally unique view id that can be used to DNL to this// viewTVwsViewId ViewId() const;// Commands are handled in the context of a viewvoid HandleCommandL(CQikCommand& aCommand);};ConsequencesIn practice, almost any application written for Symbian OS that has aUI is obliged to use this pattern.
The possible exceptions are specialcase dialog-based applications that require only a very simple dialoglike interface, which both S60 and UIQ support; for example, settingsmanagement and other ’single function’ applications. Even in these caseshowever, the application must implement a simplified version of thestandard application pattern.8 This means that there is no real questionof a trade-off for applications between using it and not using it. It is,however, useful to understand the influence it has on your application.Positives• Development costs are reduced as the strong framework supportallows applications to follow a standard template with minimal customcode to behave as a fully integrated, well-formed application.• Maintenance costs are reduced because of both the reuse of theapplications frameworks proven in many releases of Symbian OS andthe use of a well-known design pattern.9• Porting of applications between GUI variants is made easier throughthe isolation of UI dependencies from core application functionalitywhich makes it easier to reuse the same core application logic acrossmultiple GUI variants based on Symbian OS.• Testing costs are reduced as the high degree of decoupling betweenthe individual MVC components allows each to be easily isolated andunit tested.• Clear and structured application designs are enforced.8 There are a handful of exceptions such as console or server applications which do nothave to use this pattern.9 The classic version of this pattern was possibly the first pattern to be described in’pattern’ terms.344MAPPING WELL-KNOWN PATTERNS ONTO SYMBIAN OSNegatives• For developers new to Symbian OS, especially those unfamiliar withobject-oriented and framework programming, there is an inevitableoverhead in learning how to implement applications using this pattern.Especially as this pattern differs from the classic implementation.In practice, this isn’t a significant issue as there are many sourcesof information and help for application developers that include theSDK for each GUI variant in addition to the Symbian DeveloperLibrary.
IDEs, such as Carbide,10 often provide wizards to createcomplete template applications and, last but not least, there are manygood examples (including complete source code) and tutorials bothonline and in books from Symbian Press such as [Babin, 2007] and[Harrison and Shackman, 2007].Example ResolvedFor a full set of example code on how a contacts application can becreated, please see:• <Nokia S60 3rd Edition SDK Installation Directory>\S60Ex\Contacts• UIQ 3 SDK UIQ Developer Library UIQ Examples QLayout – this describes an example application that has a view similar tothat of a contacts application.Other Known UsesAll Symbian OS applications, by definition, follow the Symbian variantof this pattern. Some well-known applications are:• the phone application, which allows you to make phone calls• the agenda application, which provides a calendar, allows you tocreate a todo list, and so on• the messaging application, which allows you to send SMS messages,emails, and so on.Variants and Extensions• Document–ViewDocument–View is a common variant which Windows developers will be familiar with through the Microsoft Foundation classes(MFC).11 In the Document–View pattern, the Controller and View10 www.forum.nokia.com/main/resources/tools and sdks/carbide .−−11 msdn.microsoft.com/en-us/library/4x1xy43a(VS.80).aspx .MODEL–VIEW–CONTROLLER345are combined into a View.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
