The Symbian OS (779886), страница 19

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 19)

However, in termsof the standards of the day, approaches based on something otherthan a file system were certainly the exception. The big challenge inmaintaining data is that of data format and compatibility, ensuring thatthe data remains accessible. Any device which aims to be interoperable17‘Object soup’ is described in [Hildebrand 1994].THE APPLICATION PERSPECTIVE69(in any sense) with other devices faces a similar challenge. In bothcases, the design is immediately constrained in how far it can deviatefrom the data-format conventions of the day.

For EPOC at that time,compatibility with desktop PCs was an essential requirement. For SymbianOS now, the requirement is more generalized to compatibility with otherdevices of all kinds. Probably the most important test case for both isreadability of removable media file systems. (All other cases in which aSymbian OS device interoperates with another device can be managed bysupporting communications protocols and standard data formats, whichare independent of the underlying storage implementation.)While external compatibility does not determine internal data formats,the need to support FAT on removable cards probably tipped the balancetowards an internal FAT filing system.

One (possibly apocryphal) story hasit that the decision to go with FAT was a Monday morning fait accompliafter Colly Myers had spent a weekend implementing it.Peter Jackson:There were periods when we explored all sorts of quite radical ideas but inthe end we always came back to something fairly conservative, because if youtake risks in more than one dimension at a time it doesn’t work. So I spentquite a lot of time at one stage investigating an object-oriented filing system.But one day I think Colly Myers had a sudden realization and he just said,’Let’s do FAT’, and he was probably right.But FAT is not the whole story. In fact, Symbian OS layers a true objectoriented persistence model on top of the underlying FAT file system.

Aswell as a POSIX-style interface to FAT, the operating system also providesan alternative streaming model.It is an interesting fact that data formats, whether those of MS-Wordor Lotus 1-2-3 or MS-Excel, have proved to be powerful weapons in themarketplace, in some cases almost more so than the applications whichoriginated them. (The Lotus 1-2-3 data format lives on long after thedemise of the program and, indeed, of the company.) Data in this sense ismore important than the applications or even the operating systems withwhich it is created.Peter Jackson:The layout of the file is an example of a binary interface and, as softwareevolves, typically those layouts change, sometimes in quite an unstructuredor unexpected way, because people don’t think of them as being a binaryinterface that you have to protect.

So the alternative way of looking at things isto say you don’t think about that, you ignore the layout of the file. What you70INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSdo is you look at the APIs, and you program all your file manipulation stuff touse the same engines that originated the data in the first place.In effect, this is the approach that Symbian adopted. But it has a cost.Charles Davies:We went for an architecture in which applications lost control of their persistentdata formats, and in retrospect I think that was a mistake, because data lastslonger than applications. The persistence model is based on the in-memoryaggregation in the heap of whatever data structure you’re working with.

Forexample, if it’s a Contacts entry, then it consists of elements and you streamthe elements. One problem is that if you try to debug it and you’re looking ata file dump, its unfathomable. It’s binary, it’s compressed, so it’s very efficientin the sense that when you invent a class it knows how to stream itself, so it’s asort of self-organizing persistence model, but the data dump is unfathomable.The second problem is that when you change your classes it changes howthey serialize.

So it works. But if you add a member function which needs tobe persisted, then you change the data format. You lose data independence,and that stops complementers from working with your formats too. So wesacrificed data independence. And because that data has to carry forward fordifferent versions of the operating system, you get stuck with that data formatand you end up with a data migration problem. So I think that was a mistake.It would have been worth it to define data-independent formats.

In my viewthat’s what XML has proved, the XML movement has shown that data stickslonger than code.In some ways, implementing a persistence model on top of a FATsystem leads to the worst of both worlds, on the one hand missing outon the benefits of MS-DOS-style data independence, and on the othermissing out on Newton-style simplicity.Peter Jackson:If you implement your permanent store structure in terms of a database designthen you have all the advantages of being able to use database schema idiomsto talk about what you’re doing, and it turns out that those idioms now arefairly stable and universal.

So I think there are examples where we have prunedaway the databaseness of an application because we thought our customersdidn’t really want a database – but that may be a bad thing if one day ourcustomers decide they want more than just flat data.SYMBIAN OS IDIOMS71Store and DBMSThe native persistence model is provided by Store, which defines Streamand Store abstractions. Together they provide a simple and fully objectoriented mechanism for persistence:• A Stream is an abstract interface that defines Externalize() andInternalize() methods for converting to and from internal andexternal data representations, including encrypted formats.• A Store is an abstract interface that defines Store() and Restore()methods for persisting structured collections of streams, which represent whole documents.

Store also defines a dictionary interface whichallows streams to be located inside a store.Symbian OS also includes DBMS, a generic relational database API layered on top of Store, as well as implementations including a lightweight,single-client version (for example, for use by a single application thatwants a database-style data model which will not be shared with others).Databases are stored physically as files (single client databases may alsobe stored in streams).Database queries are supported either through an SQL subset ora native API. Since the introduction of platform security, the DBMSimplementation supports an access-policy mechanism to protect databasecontents.3.7 Symbian OS IdiomsC++ is the native language of Symbian OS.

Symbian’s native APIstherefore are C++ APIs (although API bindings exist for other languages:OPL, Java and, most recently, Python). C++ is a complex, large andpowerful language. The way C++ is used in Symbian OS is often criticizedfor being non-standard. For example, the Standard Template Library (STL)is not supported, the Standard Library implementation is incomplete, andPOSIX semantics are only partly supported. Since Symbian OS competeswith systems which do support standard C++, there is also little doubtthat the operating system will evolve towards supporting more standardC++.

But, like it or not, true native programming in C++ on Symbian OSrequires understanding and using its native C++ idioms.Among some developers inside the company the view has beenunashamedly one of, ‘Those who can, will; those who can’t shoulduse Java, Python, or even OPL’.18 While that may not make for massmarket appeal for Symbian C++ itself, the fact is that programming on18For example, see the remarks by David Wood in Chapter 18.72INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSany platform requires specialist expertise as well as general expertise,and, in that, Symbian OS is no different. The skill level required iscommensurate with the programming problem. It is far from easy to writesoftware for consumer devices on which software failures, glitches, freezesand crashes – things people put up with regularly on their PCs – aresimply not an option.

Mobility, footprint, battery power, the different userexpectations, screen size, key size and all the other specifics of their smallform factors make mobile devices not at all like desktop ones; phones,cameras, music players and other consumer devices are different.Symbian OS idioms are not casual idiosyncrasies; they are deliberateconstraints on the C++ language devised to constrain developer choices,consequences of the market the operating system targets, and of theembedded-systems nature of ROM-based devices. Strictly speaking, theyare less architectural than implementational but, in terms of the overalldesign, they are important and they have an important place in thehistory of the evolution of the system. Understanding them is essential tounderstanding what is different about Symbian OS, and what is differentabout mobile devices.

There are some large-scale differences.• Lack of a native user interface means that the development experienceis significantly different for device creation developers using theTechView test user interface than for developers later in the productlifecycle using S60, UIQ or MOAP.• The build system is designed for embedded-style cross-compilation,which is a different experience from desktop development.• Idioms have evolved to support the use of re-entrant, ROM-basedDLLs, for example disallowing global static data.• Other optimizations for memory-constrained, ROM-based systemsresult in some specific DLL idioms (link by ordinal not name, forexample).There are what might be described as language-motivated idioms:• descriptors• leaving functions• the cleanup stack• two-phase construction.And there are some design-choice idioms:• active objects and the process and threading model•UIDsSYMBIAN OS IDIOMS73• static libraries and object-oriented encapsulation• resource files to isolate locale-specific data, for example, text strings.Active ObjectsActive objects are an abstraction of asynchronous requests and aredesigned to provide a transparent and simple multitasking model.An active object is an event handler which implements the abstractinterface defined by the CActive class and consists of request andcancellation methods, which request (or cancel) the service the objectshould handle, and a Run() method which implements the actual eventhandling.

Характеристики

Список файлов книги