The Symbian OS (779886), страница 32
Текст из файла (страница 32)
The Uikon Error Resolver Plug-in is a smallcomponent that is used by the user interface variant to map system errorcodes to localized strings. Strictly speaking it is not a plug-in, but aresource file which is built as a dummy DLL.Uikon provides a server stub which is run to launch other serversexpected by the framework or by applications (the alarm server, notifierserver, and server-side support for user-interface status panes) and to loadimplementations specific to a user interface variant for password andalarm notifications.
(The Notifier is run inside the Uikon server thread toensure that memory is always preallocated for those notification dialogswhich must never fail, for example the ‘Out of memory’ dialog itself.)Uikon provides servers to manage backup and shutdown (used toclose running applications when the user starts a backup, and to handle126THE UI FRAMEWORK LAYERshutdown when the user switches off the device). In earlier releases ofthe operating system (up to Symbian OS v7.0) Uikon also supplied acore library of concrete controls and dialogs, EikCoeControl; theseare now supplied in the customization toolkit, and may be selectivelyre-implemented by the user interface variant or discarded.The Control Environment (CONE)Controls in Symbian OS are window-using, possibly nested, rectangularscreen areas that accept user input and other events. (Windows do notnecessarily own any controls; menus and sprites, for example, do not.)Events (such as redraw events, standard events and foreground –‘focus’ – events) are supplied by the Window Server to the ControlEnvironment framework.2 Of these, key, pointer and draw events arerouted by the Control Environment to controls.
Additional events maybe generated by controls themselves, including change of focus eventsbetween controls. In effect, controls bring together:• screen and window behavior as controlled by drawing, redrawingand other events• graphics states, for example, color, font, brush and other settableattributes• user-input handling (the Window Server serializes system events, suchas key presses and pen taps, and delivers them to the currently activecontrol of the foreground application).The Control Environment defines the base classes that encapsulatethese basic behaviors and the relationship between controls and theirenvironment and define abstract controls.
Applications can derive theirown types of controls directly or use derived classes provided by Uikonand the user interface variant. The Control Environment, in effect, isthe abstract middle layer between the low-level windowing functionalityprovided by the Window Server and the concrete user-interface classesprovided by Uikon and libraries specific to the user interface variant.• The CCoeControl class is the base class for derived controls.• The CCoeEnv class encapsulates the application session with theWindow Server, as well as providing utilities to manipulate thegraphics state and for other system interactions (for example, it createsan application session with the File Server).
Every application ownsa singleton object of this class derived from CEikonEnv (which is2Note that Window Server focus events are not the same as ‘focus events’ as understoodby controls.ARCHITECTURE127implemented as an active object responsible for routing input-eventmessages from the Window Server to the application frameworkAppUi class). Typically, the object is accessed from the applicationframework classes through the derived CEikonEnv class. From anapplication control, the object’s methods are accessed through thecontrol’s iCoeEnv member.The Control Environment also defines the user interface base classCCoeAppUi, providing the application user interface framework (brokered to applications via Uikon and the user interface variant) thatmanages input events.
Key events are managed in the context of the stackof application controls (assigning a key event to the appropriate control).Front-End Processor FrameworkThe Front-End Processor (FEP) Framework provides the abstractions thatimplement user-input capture and preprocessing, for example for handwriting recognition or multitap input systems, in order to capture, processand map user input events onto standard key events.The FEP Framework provides the base classes for creating FEPs anddefines the plug-in interface. The FEP Framework extends Control Environment base classes and is implemented as a DLL that is statically linkedto by code which wants to derive from it. The Control Environmentmanages the creation, ownership and destruction of FEPs.
FEPs are alsoavailable to Java and OPL applications.FEP implementations are based on the CCoeFep class, which ownsa high-priority, invisible control loaded by the Control Environment.Controls are organized as a priority queue. Since FEPs have high prioritythey receive keyboard events before (nearly all) other controls. TheFEP captures and preprocesses sequences of input events which arethen returned to the control stack as new events for consumption bylower-priority controls.Only one FEP instance is allowed per application, since it must runwithin the application process and thread (in order to access the controlstack). A FEP can exist on top of an application without the applicationbeing aware of it.AnimationThe animation framework is used to create bitmap-based and sprite-basedanimations.
Animations are created as framework plug-in DLLs (with theextension ANI), which are recognized and loaded directly by the WindowServer. While bitmap-based animations are rectangular and restricted toa single window (hence they are also known as ‘window’ animations),sprites can have irregular shapes and can overlap windows.128THE UI FRAMEWORK LAYERBecause animations are run inside the Window Server thread, they runwith higher priority than would otherwise be possible for any applicationthread, solving possible problems of slow running due to the high latencyof redrawing.Animations have been used since the early days of the Symbian OSand the framework still contains visible legacy of this, for example in thechoice of timing periods.36.6 A Short History of the UI Architecture4As early as 1997, when the Nokia Communicator project was alreadyunderway in Symbian, proposals were made for separating Eikon’s lookand feel (LAF) from its basic functional machinery.
In the end, theCommunicator project, like other early licensee projects, settled foradaptation (branching the codeline). However, it was clear that this couldonly be a short-term solution and that a principled approach was requiredto support the numbers of licensees and devices which were envisaged.Reference DesignsAs part of the Symbian OS v6 release project, therefore, the earlier lookand-feel separation proposals were revived. The result was Uikon. Itsgoal was to create a modular, streamlined and extensible user interfaceframework that would support multiple user interface styles whose lookand feel could be customized from a common base. This approachbecame a central part of the DFRD strategy, which proposed to createreference designs for a generic product matrix that would be licensed tocustomers as the basis for real products.Recognizing that each licensee had a distinct product philosophy, thereference designs in effect defined a set of distinct products.
Referencedesigns specified the basic use cases and device style (classic phone orPDA; pen or keyboard input) and physical form factor (tablet or clamshell,as well as screen size, resolution and orientation), and were intendedto be followed up with reference implementations including a referenceuser interface based on custom extensions to Uikon.Uikon Architecture EvolutionThe Uikon architecture consists of a common functional core (Uikon),a standard but non-core supporting library (EikStd), a graphical utilitylibrary (EGUL), and a LAF customization framework (UikLaf).34See Douglas Feather’s Window Server chapter in [Sales 2005].See also Chapter 16.COMPONENT COLLECTIONS129Early on, the implementation of common dialogs and controls wassplit between a core set and an optional set, with printing, file browsing,infrared beaming, and other similar functionality classed as optional.• Core modules were intended for use unchanged.• Standard modules were based on the Eikon baseline but were evolvedin collaboration with the DFRD teams (Crystal, Quartz and Pearl).• DFRD-specific libraries were created by DFRD teams.Initially, ‘mixin’ classes were used to enable control implementationsto reside in LAF-specific custom classes.
Invoking Set() functions inthe mixin classes loaded the custom library dynamically and allowed thecore libraries to ‘set’ the custom concrete implementations.Largely for performance reasons, this evolved into a stub library modelin which the core links statically against a stub library which then loadsand initializes the concrete custom library (or libraries, since there maybe several). The advantage was that only one copy of the custom DLL wasnow loaded and one-off initialization was also faster than on-demandinitialization. As well as providing a custom library, each variant userinterface also implements a LAF module DLL that supplies the specificlook-and-feel implementation for the Uikon core, to achieve a consistentlook and feel across core, standard and custom libraries.
The customlibrary replaces the Uikon internal library, UikLafGT.5In its current architecture, Uikon principally provides application baseclasses for use by a variant user interface implementation. In earlySymbian OS releases, it also provided a core set of controls (such aswindow borders) and dialogs (standard information and query dialogs).Additional (optional) standard controls and dialogs, which are directlymodified by customizers to form part of a variant user interface, aresupplied in the UI Toolkit (part of the larger Symbian Toolkit delivery)and are not described here. Each variant user interface also defines itsown custom controls, which vary between user interfaces.6.7 Component CollectionsThe UI Framework layer contains two collections of components, asshown in Figure 6.2.UIFrameworkUI SupportUI ApplicationFrameworkFigure 6.2 Component collections in the UI Framework layer5‘GT’ is a legacy Symbian internal name that originally stood for Generic Technology.130THE UI FRAMEWORK LAYERUI Application Framework CollectionThe UI Application Framework collects the main frameworks related touser interfaces (see Figure 6.3).It provides generic user-interface framework components that supportuser-interface customization.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
