The Symbian OS (779886), страница 18
Текст из файла (страница 18)
However, theprinciples of application structure have been essentially mature since thefirst release of S60 and UIQ in 2002.Uikon is the topmost layer of Symbian OS. It provides the frameworksupport on which a production user interface is built. The three currentlyavailable custom user interfaces are S60, UIQ and MOAP, but there is noengineering reason why any licensee should not build its own bespokeuser interface, which indeed is precisely the origin of S60 and MOAP.Uikon abstracts application and control base classes in the ApplicationArchitecture and Control Environment class hierarchies to create genericGUI application classes (that is, classes free of a look and feel policy)which are customized by the custom user interface.
The custom userinterface abstracts the Uikon policy-free base classes to provide thepolicy-rich classes that applications derive from.Uikon thus integrates the underlying support of the Application Architecture and the Control Environment to create a framework from which(as abstracted by the custom user interface), applications derive. Uikon isa framework and applications behave recognizably as plug-ins.
Uikon isimplemented as a server.66INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSThe Structure of an ApplicationEvery application is built from three basic classes:15• an application class, derived from the Application Architecture (CApaApplication)• a document class, derived from the Application Architecture (CEikDocument)• an application user interface class, derived from the Control Environment (CCoeAppUiBase).These classes provide the fundamental application behavior.
However,two important parts of the application are missing from this structure: theapplication view, which is the screen canvas the application uses todisplay its content, and the application data model and data interfaceimplementations, which encapsulate the application ‘engine’.The classic application structure expects that the data model (thedata-oriented application functionality) exists independently of the GUIimplementation of the application and is, therefore, independent of anyuser interface classes. It is hooked into the user interface by a memberpointer (iModel) in the document class. The classes specific to the userinterface then interact with it purely through the APIs it exposes.16Charles Davies:We always had that structuring of applications, the idea of separatingthe UI from the application engine.
That was an early design principleand it was the design guidance for application writers. We knew aboutModel–View–Controller, and we thought of an application engine as amodel, and our design guidance was to keep the application logic separatefrom the UI. Not because we anticipated at that time multiple UI flavors,but because we recognized something more fundamental in terms of writingan application.
That you might write an application and decide to improvethe design of the UI, where the refinement of the UI was just pragmatic, thebasic functional application logic stayed the same. So if you could separatethose two things, that was good, and that led to the terminology of applicationengines.15This is the ‘classic’ application structure, with roots in the Eikon applications of PsionSeries 5. Both UIQ and S60 extend the design patterns for applications.
See [Edwards 2004,p. 184] for discussions of the ‘dialog-based’ and ‘view-switching’ S60 application structure.UIQ applications also extend the basic pattern with custom view classes.16This is in fact a very powerful design principle, implying, for example, that thedata model can run without a direct user interface at all.
Engines designed this way areindependently testable and intrinsically highly portable between different user interfaces.The principle runs deep in the Symbian ethos, as witnessed by the presence of enginesindependent of the user interface in the operating system itself.THE APPLICATION PERSPECTIVE67In Symbian OS, a control is a drawable screen region (in other words,the owner of screen real estate).
The Application view class is deriveddirectly from the Control Environment control base classes.On small devices, where screen real estate is scarce, desktop-stylewindowing is not appropriate. A more natural approach for small displaysis to switch whole-screen views, for example switching between a liststyle view of contact names and a record-style view of the details ofa single contact. Applications therefore typically define a hierarchy ofviews, with the main application view at the root.Because Symbian OS is multitasking, multiple applications can berunning at once, even though only one (the foreground application) willbe presenting its view on the display.
Both S60 and UIQ support switchingdirectly between views in different applications, including launching theview of a new application inside the context of the current one (forexample selecting a phone number from within a Contact entry andimmediately switching to the phone application and dialing the number).Symbian’s application structure makes much of the detail of the application user interface programmable solely via resource files.
Resourcefiles are compiled separately as part of the application build processand linked into the built application, providing a natural mechanismfor language localization (all text strings used within an application canbe isolated in resource files and recompiled to a new language withouthaving to recompile the application). Resource files are also compressed.Charles Davies:We lived in tougher times as far as Moore’s law was concerned in those days.Resource files were around in contemporary GUI systems at that time.
Butfrom the beginning we did Huffman compression on resource files, and wewere careful about the amount of information we put in them.UikonThe most striking fact about Symbian OS at the user interface level isits support for a replaceable user interface, and indeed the fact that itships without a native user interface at all. (User-interface-dependentcomponents are shipped only with a TechView test user interface.)While it seems fair to say that Symbian did not get its user interfacestrategy right first time (in particular, the Device Family Reference Design(DFRD) strategy looks, with hindsight, to have been naı̈ve), nonethelessthe operating system has been able to support multiple licensees, eachhaving a distinct user-interface philosophy, occupying different positionsin the market and spanning diverse geographical locations. Those differences are encapsulated in the differences between the user interfaces thathave evolved for Symbian OS.68INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSS60 builds on the classic Nokia user interface to provide a simple,key-driven but graphically rich and arresting user interface.
In contrast,UIQ is firmly pen-based and targets high-end phones with rich PDA-likefunctionality including pen-based handwriting recognition. MOAP aimssquarely at its solely Japanese market, providing a graphically busy userinterface featuring Kanji as well as Roman text and animated cartoon-styleicons.File System or ‘Object Soup’ Storage ModelFAT is the ‘quick and dirty’ file system that MS-DOS made famous. Whenwork on EPOC started, the Apple Newton was a leading example of adifferent way to approach consumer computing (different, for example,from the MS-DOS-based Hewlett Packard machines which were theleading competitor for Psion’s Series 3).
Instead of a conventional filesystem the Newton employed an ‘object soup’ storage model.17On any useful system, data requires a lifetime beyond that of theimmediate context in which it is created, whether that means storingsystem settings, saving the memo you have just written to a file, or storingthe contact details you have just updated.Charles Davies:We had a normal file system on the Series 3. When we went to C++, we talkeda lot about persistent models of object-oriented programming, and we wentfor stream storage. We narrowly rejected SQL in favor of stream storage.
Iremember the design ideas around at the time, and it was done in the interestsof efficiency. Different applications were having to save the same systemobjects and we were having to duplicate that code. So for something like pagemargins, which was a system structure, if that object knew how to serializeitself, that would solve the problem. You do that by having serialization withinthe object, so objects that might reasonably want to be persisted could persistthemselves. And that was in the air, I mean Newton had its soup at thattime which I think was object-oriented, and there was a belief at that timethat object-oriented databases were it, and that objects ought to be seen assomething that existed beyond the lifetimes of processes.Objects, in other words, can be viewed as more than just the runtime realizations of object-oriented code constructs.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
