The Symbian OS (779886), страница 35
Текст из файла (страница 35)
Thestandards allow entries to contain more than simply text (character,number, date and time) content. For example, they can include sounds(for example, alarms) and pictures.The vCard and vCalendar component provides parsing APIs for vCardand vCalendar entries and enables conversion into Symbian OS nativeformats.Alarm serverThe Alarm Server manages a queue of system-wide, time-based alarmsand provides APIs for applications to set, modify and query alarms. Notethat the Alarm Server does not actually notify, sound or show alarms (theAlarm Alert Server performs those functions).The Alarm Server is a conventional Symbian OS server managing ashared resource (the alarm queue).
Clients create a session and connectto the server to use the APIs. The Alarm Server has a long history inSymbian OS.3Backup and restore notificationThe backup and restore notification mechanism provides an alert (basedon Publish and Subscribe) to signal to PIM applications that backup orrestore is in progress or has completed. Applications may need to refrainfrom writing data to file during backup or may need to re-read files afterrestore. Other applications should use Publish and Subscribe.Chinese calendar converterThe Chinese Calendar Converter provides a simple API for convertingbetween Gregorian and Chinese calendar dates.File converter plug-insThe File Converter Plug-in is a simple converter that translates HTML toSymbian OS rich text format.
It is used, for example, to convert text toHTML email format.3Until Symbian OS v7.0s, a single component (known cryptically as EALWL) combinedboth World Server and Alarm Server functions and served as the engine for the TimeWorldapplication, see [Tasker 2000, p. 108]. In Symbian OS v7.0s, they were separated andrewritten. The new version of the Alarm Server replaced the old EALWL-specific alarm types(e.g. clock alarms and agenda alarms) to make them more generic.142THE APPLICATION SERVICES LAYERPrinting supportPrinting Support implements a framework for managing printers and printjobs, generating graphics input to raster devices and treating printing asa special case of drawing to a device context, much like drawing to ascreen or any other display device.It is intended to be used by applications printing directly to supportedprinter types and is therefore most suitable for ‘old-fashioned’ PDAstyle applications on ‘converged’ devices, such as Communicator-stylephones, and less appropriate for the more lightweight kinds of applicationlikely to be found, for example, on a phone without a keyboard.
For suchapplications, full WYSIWYG printing is unlikely to be as important assending a picture to a printer using Bluetooth technology. The printframework can, therefore, be seen as part of the legacy functionality ofSymbian OS, along with the Office-style applications it most naturallysupports.It presents a simple application-level interface to underlying printingsupport provided by the Multimedia and Graphics Services. The printingAPI, among other things, manages:• listing and selection of available printers• encapsulation and setting of the device and print job properties• selection of a printer port (where required by the printer).Data synchronization and device management and provisioningThe Open Mobile Alliance (OMA) sponsors data synchronization servicesbased on SyncML, Client Provisioning for OTA device configuration, andDevice Management standards.
The Application Services layer includesspecific support for OMA standards.Support for Generic TechnologiesStandards-based messaging and browsing have become essential functions for mobile phones. The Application Services layer provides extensible support for messaging standards including SMS, MMS and email;for Internet browser protocols; and for newer, session-based multimedia protocols. Supporting services include content recognition, includingMIME-type recognition, for data originating from the network; and supportfor ‘smart’ messaging (messages containing network-originated configuration and settings data intended to be used by the system rather thanread by the end user).ARCHITECTURE143MessagingComprehensive support for messaging of all kinds, from email to text andmultimedia messages, is an important feature of Symbian OS. Messagingsupport has been available from the first release. As the operating systemhas become more phone-centric, messaging has arguably become evenmore critical than it was originally, although (interestingly) the use casesare subtly different for phones and PDAs.The Symbian OS messaging implementation provides a complete messaging infrastructure for use by a messaging application, whether froma licensee or other source.
It is based around a message server, whichmanages access to a unified Message Store and performs generic messaging actions that are exposed through a client-side API. It also ownsan extensible framework allowing generic actions to be specified forparticular message types. The framework is open and is intended to support enterprise-level customization (for example, for bespoke, corporatemessaging systems or services) as well as licensee extension and customization (for example, to adapt the generic functionality to a particularuser interface idiom – S60 and UIQ messaging applications behave differently from an end-user perspective). The client-side API enables clientapplications to manipulate the message store, for example, to browse andnavigate the message-store folder tree, and provides basic functions, suchas edit, copy and move.
The framework also supports scheduled sendingof messages.The underlying communications services of the operating system areused to enable message transport over any available network connection,whether phone, short link (Bluetooth or infrared), or cable (serial or USB).Extensions are provided by Message Type Module (MTM) plug-insto the framework and the operating system provides product-qualityimplementations for a standard set of message types, including email(SMTP, POP3 and IMAP4 HTML mail), SMS (on both GSM and WCDMA,that is on 2 and 2.5G, 3G and CDMA 2000 networks: the SMS protocolsare specific to each type of network) and MMS.BIO messagingAn important secondary server and framework is the Bearer-IndependentObject (BIO) Messaging Framework, which extends generic messagingto provide a ‘smart’ messaging server, a message type framework and awatcher framework. Bearer-independence means that the message handling is independent of the type of transport over which the messagewas received; ‘smart’ messages are those which are intended for processing by the system, or directly by applications.
BIO messaging supportsapplication message types, such as encapsulated vCard and vCalendardata, and system services such as network-access setup messages. The144THE APPLICATION SERVICES LAYERBIO messaging APIs allow application developers to create their ownapplication-specific ‘smart’ message types.The message server provides the underlying mechanisms used by dedicated messaging applications, or other mail or SMS client applications,as well as providing a ‘Send As’ API as an extension to the client-side API,which allows any application to encapsulate a document and send it as amessage type (including Fax), over any available bearer. Any applicationcan also receive messages, using the watcher service, and ‘smart’ objects.Messaging support includes handling of MIME and other recognizeddata types (provided by the Content Handling components); handlingof attachments; managing local and remote mail boxes; and editingmessage contents and properties.
The watcher frameworks support alertsfor message-related external events, for example a fax-line ringing or anSMS or email being received, and for ‘system’ messages to be identifiedand handled.The basic design principle in the messaging system is to clearly separategeneric message handling performed by the framework from the detail ofmanipulating and handling different message types, which is delegatedto the MTM extensions.The Message Store is considered to be a shared system resource, forwhich the client–server design ensures multiple simultaneous access byclient applications.The plug-in-framework design allows for a modular and extensibleimplementation.
(However, the MTM model is complex: creating a newMTM is a challenging system-level programming project.) An MTMimplements concrete support for three client-side APIs and one serverside API. The client-side implementation consists of a user interface forviewing and editing message contents (and service settings), concretedata, such as icons that clients should display, and the message creationand management functions. The server-side implementation supportsmanipulation of messages on remote services. Messaging clients link tothe client-side MTM. The matching server-side MTM is loaded as neededby the messaging server.The BIO messaging server and framework is itself implemented as anMTM. BIO messaging plug-ins derive from and implement the frameworkclasses and are loaded by the BIO messaging MTM.BIO Messaging responsibilities are divided between the MTM (whichimplements the server and framework), a BIO database (which maps portnumbers, MIME types, etc.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
