Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 63
Текст из файла (страница 63)
Such an application needs to provide the following functionality:• objects that are responsible for storing the contact information in thefile system so that it’s persisted across reboots of the device but is inan easy-to-access form• objects that display the contact details to the end user so that they caninteract with the data to add, update, search or delete contacts• objects that listen for events generated by the end user such as thetext they wish to search contacts for or the add contact menu itemthat has been selected.In addition to these core requirements the application needs to work onS60 where the end user generally uses a joystick-style button to navigate334MAPPING WELL-KNOWN PATTERNS ONTO SYMBIAN OSbetween contacts and UIQ where the user often taps the screen to selectdifferent contacts.SolutionThis pattern is based on the classic object-oriented abstraction of agraphically based, data-centric, interactive user application. The classicversion of this pattern, as described in [Buschmann et al., 1996], providesa ready-made template which is applicable to any GUI-based applicationon any platform.
The classic pattern recognizes the three core elementsof most interactive applications and recommends that each is designedas independent modules so that dependencies between the modules areminimized and the responsibilities are well encapsulated.These modules are defined as follows:• The model owns and manages the data that represents the internalstate of the application and implements all application logic thatdirectly changes that data, and hence the application state.• The view provides a view for the end user onto the application stateand ensures that it is always up to date with any changes to that statein the model.• The controller provides the interaction logic and interfaces that enablethe end user to interact with the application data, and hence manipulate the application state.StructureThe structure of the classic version of the pattern is shown in Figure 9.1.All GUI-based interactive applications on Symbian OS are implemented using a framework which is based on the classic version of thispattern, providing a similar level of abstraction even though it is differentin some details:• Symbian OS enforces clear separation between UI-dependent andUI-independent code.• Symbian OS has historically emphasized the document-centric natureof applications although this has become less important and both S60and UIQ minimize this aspect of the pattern.• Symbian OS is based on a design in which application classesare derived from interfaces provided by the application frameworksto provide concrete implementations of framework-defined behaviors.22 In fact, several frameworks are layered on top of each other, some contributed bySymbian and some by the UI vendor.MODEL–VIEW–CONTROLLER335Provides views onapplication stateto the end userViewobservesobservesModelControllerdrivesEncapsulates coreapplication logic,interfaces and stateUses events from theend user to driveapplication logic andstateFigure 9.1 Classic structure of the Model–View–Controller patternAs with any framework-based design, the application frameworks areintended to move complexity into system code.
Thus the frameworkintegrates individual applications and provides support for:• the application lifecycle of installation, launch, moving to and fromthe background, and shutdown• handling resources as well as associating documents with individualapplications• different display and graphics models including graphics contexts,concrete display classes, standard dialogs and other screen elementsprovided by the GUI variant• a window hierarchy and system events.This gives rise on Symbian OS to the basic structure shown inFigure 9.2.Every Symbian OS application must implement the interfaces definedby the application frameworks. However, the application frameworks canbe divided up into at least two layers: a generic layer provided by SymbianOS with a layer on top that provides the GUI variant’s specializations.Individual applications then provide concrete implementations of the336MAPPING WELL-KNOWN PATTERNS ONTO SYMBIAN OSFigure 9.2Structure of Model–View–Controller on Symbian OSclasses provided by the GUI variant and hence implement this basicpattern.Originally, the Symbian OS use of this pattern assumed that applications are document-centric; an application is considered to be a documentinstance, either in a ’live’ running state with an associated process orpersisted as serialized data in a store somewhere in the system.
However, subsequent usage has more typically been to make applicationstask-centric rather than document-centric so that the end user experienceis typically organized around user tasks rather than applications anddocuments. End users are assumed to be more interested in tasks thanin the applications that perform them and tasks are allowed to followtheir natural course, which is often to flow across multiple applications;for example, starting with looking up a name in a Contacts applicationand moving seamlessly on to calling a number from the Phone application.In practice, as in Figure 9.2, the document class is in many casessimply stubbed out.
Instead, the AppUi directly owns a UI-independentapplication engine which encapsulates the application state and logicand is equivalent to the model in the classic version of this pattern.Because all interaction between the model, the view and the controlleris through framework-defined interfaces, there is a high degree of decoupling inherent in this structure that makes it relatively easy to swap outone or more classes for an alternative implementation.MODEL–VIEW–CONTROLLER337Defining at least one view is essential for an application to display itself.While the classic Model–View–Controller pattern defines an explicitView class, the Symbian OS application frameworks do not; instead, ageneric control class CCoeControl is defined, and in early releases ofSymbian OS, application views were typically directly derived controls;in special cases3 they could be omitted altogether and replaced with asingle concrete control or container.
From Symbian OS v9.1 onwards,all standard application views derive from a suitable framework classsupplied by the GUI variant. In UIQ3 in particular, the view classesprovide important additional functionality, including support for viewswitching and view sharing between applications as well as integrationwith the new generic command structure.4This structure allows the UI dependencies of the application to largelybe confined to these views unlike the other two components, the controllerand the model, which should have minimal dependences on the UIand hence are easily portable between different GUI variants.
Viewsthemselves are not intended to be portable but they are, to a high degree,decoupled from the model and hence the controller can be replaced foreach version of your application specific to a GUI variant.DynamicsFigure 9.3 shows how the application classes interact.Figure 9.3 Dynamics of Model–View–Controller on Symbian OS3 Forexample, S60 2nd Edition.to support the multiple UI configurations of UIQ3.4 Introduced338MAPPING WELL-KNOWN PATTERNS ONTO SYMBIAN OSNote that in S60 views are sized and switched by the AppUi whilst inUIQ this is done within the application frameworks. The view switchingin particular highlights an important difference between the latest versionsof UIQ and S60:• In UIQ3, switching to external views, views that belong to a differentapplication, is explicitly supported by the framework, encoded in theview persistence and ’backing out’ behavior rules, and enshrined inapplication structure by the publication of external interface information in header files; the behavior of built-in UIQ applications dependson being able to drive one application into the view of a differentapplication.• In contrast, in the S60 view, persistence rules positively discourageleaving a view in the state of its last use or switching to an externalview.
Instead, S60 takes the approach of embedding one applicationinstance within another to achieve a similar effect. S60 applicationsrarely have their state affected by another application, whereas in UIQthis is the norm.An important point to remember is that, just as the classic versionof this pattern relies on Observer [Gamma et al., 1994] to allow thecontroller to react to events generated by the view and the view to reflectthe application state stored in the model, the Symbian OS version of thispattern also relies on an event-driven programming approach to keepthe three main classes aligned whilst allowing them to remain largelydecoupled.
If you introduce your own model class, you should ensurethat you build on this approach to avoid introducing hard dependenciesthat will reduce your ability to port your application in future.ImplementationOverviewThere is no such thing as a generic Symbian OS application, because ata detailed level application design depends on specific features of GUIvariants. However, at a fundamental level the underlying Symbian OSframeworks impose a common blueprint on all applications irrespectiveof UI variant:• The GUI variant framework implementations derive from the underlying Symbian OS frameworks and therefore share a common structureacross all devices.• While specific details of GUI behavior differ between UI variants, thesignificant differences are encapsulated in those variants and come’for free’ with the use of the specific application frameworks for theassociated devices.MODEL–VIEW–CONTROLLER339• The main differences between the UI variants are the details ofresource file usage and application lifecycle implementation details.This is in addition to more obvious differences to the application’sown UI that reflect the ‘look and feel’ of the UI variant such asview layout and navigation, menu layout and behavior and the layoutof application-independent screen areas, which includes the generalstatus and task bars that are always shown by a device.• The independence of Symbian OS from the GUI variant running ontop of it encourages the partitioning of application code between GUIindependent application engine code and GUI-dependent display anduser interaction code.The Symbian OS application frameworks are hidden from concreteapplications by the application frameworks of the GUI variant for thedevice you are currently targeting.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
