The Symbian OS (779886), страница 34
Текст из файла (страница 34)
The original goals of the printing support in SymbianOS (to provide WYSIWYG document printing) have been overtaken bythe nature of the content being printed (from photos and contact details toweb pages, but rarely a full business document) and by newer protocols(such as the Bluetooth printing profile).7.6 ArchitectureA goal of the user-interface architecture in Symbian OS is to enableas much common functionality as possible on the system side and tomake it available to as wide as possible a range of applications.
Thisallows applications to be written with a minimum of new code and themaximum reuse of system-provided code. Applications gain in robustnessand reliability because, as far as possible, the most complex code iswritten only once, on the system side where it is tested and validated,and is reused by application authors.
While the strategy for deliveringthis goal has shifted from providing full application engines to providingcomprehensive services, with engines moving up to the licensee layers,the goal remains the same. And while the classes that define the basicarchitecture of a Symbian OS application differ between variant userinterfaces, they all derive from generic Symbian OS classes; Symbian OSimplements the underlying generic behavior.For the application writer, this is interesting. On the one hand, it isextremely powerful, because a little application code goes a long way.On the other hand, having so much richness in the system presents asteep learning curve to the application writer. The Application Serviceslayer provides ‘rich system’ support for applications.Application FrameworkModel–View–Controller (MVC) is the classic object-oriented abstractionof a graphically based, data-centric, interactive user application.
(MVCwas originally part of Smalltalk-80 and, according to [Johnson 1998], was‘the first framework that was recognized as a framework’.)1In practical terms, their public APIs are likely to be deprecated in some future release.138THE APPLICATION SERVICES LAYERSymbian OS, from its first inception, applied an MVC-like model toapplications. It is not quite pure MVC, because it elevates the applicationitself (as an abstraction for system-owned resources) into a first-classconcept and because the variant user interfaces do not necessarily codethe MVC classes directly. How they interpret MVC is strictly the businessof the variant user interfaces.Applications, documents, UIs and viewsThe first rule of object orientation (in C++ anyway) is, according to[Koenig and Moo 1997], to ‘use classes for concepts’.
There are fourkey concepts in the application model: Application, Document, AppUIand View. The Application Framework supplies the base classes forApplication, Document and AppUI, and variant UIs supply appropriatecustom specializations. The View class is typically derived directly fromCCoeControl.An application is built as a EXE that is recognized by the applicationarchitecture and launched in its own process.2 The framework-definedentry-point function calls the factory function that creates the applicationinstance. The application encapsulates the relationships between theapplication instance, its document, its document-owned user interface,and its view or views, as well as application-owned resources, forexample the application icon and more abstract properties such as UIDs.Applications may have multiple views; every application must have atleast one view (i.e.
one window-owning or window-controlling control).Strictly speaking, the application document abstracts a data modeland not a file, although applications may be file-based. The document is responsible for storing and restoring the application’s persistentdata, whether to or from a file or a database. Documents can also beembedded, so that documents may contain other documents (includingdocuments belonging to other applications). The application document isalso responsible for creating the application user interface (although theframework takes ownership of the user interface and is responsible fordestroying it). Just as the document exists to persist the data state of theapplication, the user interface exists to manipulate the data state.A ‘data model’ in this context really means data plus the APIs definedto create and manipulate it (getters and setters, the ‘data logic’ definingthe translations and other functions that can be applied to the data toreturn results of some kind).
In Symbian OS, this is often loosely referredto as an application ‘engine’; the engine is really a code implementationof the machine that transforms the data state, driven by the user interface:the document encapsulates the data model state.2In releases before Symbian OS v9, applications were built as DLL plug-ins and sharedprocess space; the changes are required by the system-wide security model.ARCHITECTURE139‘Engine’ classes do not have any framework significance (and hencedo not derive from a framework class) and they are not required, althoughthey are a useful design pattern for encouraging separation of logic fromdata.Since the document creates the user interface and every applicationneeds a user interface, every application must have a document.
Eachapplication instance is associated with a single document.The application view provides a view onto the state of the applicationdata. Views are implemented using controls. On a typical SymbianOS device, desktop user interface idioms (such as multiple overlappingwindows) are not appropriate, for a number of reasons: display size ishugely limited compared with a desktop device; handheld operation (and,in particular, one-handed operation) rules out mouse-style interaction,and so on.Typically, the view metaphor is closer to a stack of sticky notes or adeck of cards. The top card conceals the other cards in the deck. Cardscan be brought to the top, shuffled to the bottom of the deck or shuffledunseen within the deck.
While applications can have multiple views,only one is visible at any time.View switchingThe View Server provides a framework for sharing application views by‘view switching’. Originally designed to support switching between flipopen and flip-closed modes on the Ericsson R380 (an ER5-based phone),it migrated into the Quartz user interface (which became UIQ) andwas eventually adopted back into the operating system. Applications canregister views with the server.
A registered view owned by one applicationcan then be used by any other application (or indeed by another view inthe same application) that requests the view to be activated.In UIQ, for example, the Contacts application can request activationof the New Message view from the Messaging application when a usertaps on an email address in a contact detail. View switching provides aclever shortcut to passing data between applications.Note that while the View Server manages view switching and owns theframework, it is not used directly by applications: instead, switching isenabled via the application user interface (which is a Control Environmentwrapper).
View Server uses the Window Server client API to effect viewswitching.Support for Generic ApplicationsWhile applications are highly dependent on the frameworks suppliedby the variant user interface, the underlying support for the applicationlogic is largely provided by Symbian OS. This is an important part of theplatform promise that Symbian makes to developers: application logic140THE APPLICATION SERVICES LAYERshould in principle be reusable across the whole range of devices basedon Symbian OS.
As discussed above, in recent releases the emphasiswithin the operating system has shifted away from providing reusableapplication engines towards application services.Legacy enginesThe earliest versions of Symbian OS included a number of fully fledgedapplications, ranging from standard PIM and Office applications (Agenda,Data, Sheet, Word) to Time World (a time zone browsing and settingapplication), a Help system, and so on. While there was no Contactsapplication on the original Series 5, by the time of the later Psion devices(such as the Revo) it had joined the set of standard applications.Increasingly, providing common services and standardizing APIs isseen as providing more value to licensees than providing ready-made,one-size-fits-all engines.
However, the legacy engines still form part ofthe operating system.Along with phone-specific functions (messaging and email as wellas the phone application itself), PIM applications – most importantly, aphonebook and a simple calendar – are at the heart of what a modernphone provides to its users. Underlying these standard applications are anumber of common services, including support for basic text handling, thevCard and vCalendar standards, alarms, backup and restore notifications,and file and date conversions.Text handling (EText) and formatting (FORM)Text Handling supports the storing of editable text and its formattingattributes, while Text Formatting provides text view and layout classes(CTextView, CTextLayout, MLayDoc) that control scrolling, selection,cursor management, margin setting, and other attributes of displayed text.Managing display attributes (layout and drawing) is thus distinguishedfrom managing logical text attributes (including text content).Text content is managed by the text-handling APIs, and consists ofUnicode characters, including space characters and paragraph delimiters,as well as formatting attributes, including properties such as paragraphalignment, character fonts, and so on.
(Formatting attributes are not thesame as text formatting layout attributes.)The text-handling APIs and the rich text model underlying them havea long history in Symbian OS. They have used Unicode since the ER5urelease, the first release to be used in phones, in 1997.The Text Formatting layout framework is used directly by applications(to lay out text in application user interfaces and documents) and byuser interface and system components (to lay out text in dialogs, etc.);for example, text views are used by the Uikon Core API for editabletext windows (‘editors’), as well as directly by applications to format anddisplay rich text.ARCHITECTURE141vCard and vCalendarvCard and vCalendar are standards that define formatting conventionsfor card (address detail) and calendar (diary appointment) entries.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
