The Symbian OS (779886), страница 94
Текст из файла (страница 94)
In Symbian OS v8.x, the architecture was reinvented to support a full suite of sophisticated phonefunctions. Between the releases of Symbian OS v6.0 and v8.1 therefore the change has been dramatic, from still camera to movie camera;from instamatic-like snapshots to full-function, multimegapixel digitalcamera replacement; from ring tones to music player.
With image- andsound-recording, -editing and -manipulation capabilities, Symbian OSis evolving to support capabilities that until recently were limited tomultimedia workstations.The underlying rationale for the multimedia architecture redesignwas support for the increasingly complex built-in hardware of the newgenerations of phones, with their dedicated multimedia components suchas graphics hardware accelerators, MIDI-tone generators, dedicated DSPsand voice synthesizers, as well as high-end imaging and audio hardwareparts.Evolution of the licensee UIs for Symbian OS has been another bigdriver for change in the graphics services which underlie the UI frameworksupport. Numerous UI enhancements aimed at supporting specific UIeffects, such as fading, transparency and multimillion-entry color palettes,have required a steady stream of changes, mostly focused at the level ofeither the Window Server or GDI and BitGDI.
The Window Server is acentral component of the operating system, in many senses underpinningthe GUI application model of the operating system, responsible not justfor the windowing model, managing screen real estate and serving display5Incidentally, incompatible changes were back-ported to Symbian OS v6 to ensure thatlater Symbian OS v6 products could not be ‘hacked’ based on the previously publisheddocumentation.444SYSTEM EVOLUTION AND RENEWALregions to applications, but also responsible for the system-event model.An example of the complexities which can be involved are the challengeto the fundamentally single-threaded Window Server model by explicitmultithreading in the UI. It is easy to arrive at a position in which a clashof programming models (the native asynchronous model of Symbian OSbased on Active Objects versus explicit multithreading) turns into anarchitecture problem.There are other challenges too.
A good example of the unpredictableemergence of new technologies is the emergence of vector graphics asthe future display technology of choice (or at least a plausible candidate)within the wider industry. Traditional display technologies are bitmapbased (or have been for a good many computer generations), but vectorgraphics for display is certainly not new. Since the days of the NeXTstepUnix machine which put Display PostScript to work to manage the phonedisplay, it has remained an interesting possibility.However, recently there has been a vector revolution.
The big driverhas been 3D and naturalistic graphics for games. 3D graphics are calculation driven and vector graphics are a natural vehicle for their expression.Charles Davies:Now we have the challenge of how to deal with moving to Open GL andSVG, and what happens to Window Server in that context.
There’s a hugeamount of technology and value in the Window Server and in the GDI and,for example, none of that’s available in Linux; people have to license Trolltechabove Linux. That makes the Window Server quite a critical asset. But it’sunder threat, because the world might be moving on to vector graphics modelsof drawing. So we had better be careful about that.
It’s not going to happentomorrow, but it’s one of the challenges.17.7Defining the SkinOne of the trickier problems Symbian OS faces is the boundary problem,or as Charles Davies puts it, the problem of defining the skin of theoperating system, the boundary which determines what is in the operatingsystem and what is not, what value Symbian creates and what valueSymbian retains compared with the value that licensees themselves createand retain. There is a complex relationship between the architecture ofthe operating system and the business model, which is designed toencourage platform unity while enabling variation. At the same time,Symbian has deliberately sought to create an open platform capable ofsupporting a broad ecosystem of partners, third-party developers, softwareand tools vendors, enterprise customizers and hardware vendors, as wellDEFINING THE SKIN445as licensees. Against external competition from competing systems suchas Linux and Microsoft’s Windows Mobile, Symbian must maximizethe value it creates for its customers, thus maximizing Symbian benefit,without doing so at the expense of the value chain, which includes theecosystem of Symbian’s own partners as well as the partners of SymbianOS licensees.
The essential rule, of course, is that Symbian must maximizethe value it delivers without cannibalizing the value chain.Charles Davies:When I was at Psion, when we were building a PDA, I understood wherethe PDA ended and where the things outside the PDA began.
I knew theboundaries of the product. I came into Symbian OS and I thought, ‘Where arethe boundaries?’One of the things I’ve done since being here is to try to identify the scopeof Symbian OS. We have had arguments like ‘Should MMS have been insideor outside?’ and I would have liked, dearly loved, to say, ‘We do all the APIs,but we don’t do the implementation’.
That would be a simple thing to say,but the moment’s gone. S60, MOAP and UIQ have extensive APIs. So that’snot the boundary and it’s really tough for both our customers and us to knowwhere the boundary is.To look at it another way, we’ve got, say, 750 people in Software Engineering doing Symbian OS and we can’t make that 1500 overnight and we’recertainly not going to make that 200. So with 750 people, what boundary canwe draw that matches a decent product?There are no easy answers. Not only is the system complex, thetechnologies are complex and the market is complex. The Symbian OSlicensee model is complex.Charles Davies:For example, we could do an OMA DRM plug-in. Or is that an application?Is that in the scope of the OS or is that something for the UI? And the answeris borderline, borderline.
With the borderline cases we will work with ourcustomers when our capacity doesn’t match it.Keith de Mendonca has been on the engineering side of similardecisions in the past. MMS is an example. Writing MMS messagingplug-ins is complex. Providing support for it within the operating systemclearly has an immediate benefit for licensees. The problem is that ifsome licensees take the Symbian OS solution and some do not, then bothfragmentation and duplication result.446SYSTEM EVOLUTION AND RENEWALKeith de Mendonca:We did produce an MMS solution when MMS first appeared.
But we ended upwith multiple solutions, with us and licensees each investing and producingbasically the same technology. It was a waste of resources. Nowadays, SymbianOS no longer supports MMS directly at all, and so our customers have toprovide those MTMs themselves if they want them, and they obviously dowant to support MMS. So although our MMS solution is still in some products,say the Motorola M1000 phones or the v7.0 phones that are shipping, wedon’t supply it any more. I think the truth is, it was one of those situationswhere it’s hard to decide who should really innovate in areas that seem to bevery hot, where the technology was moving very quickly.Avoiding the trap of duplication of effort, however, is hard. Arguably,precisely because customization is required to adapt the operating systemto a given hardware platform, it may be unavoidable toward the bottomof the operating system in the hardware adaptation interfaces.
On theone hand, the risk is of under-providing, which leaves too much work forlicensees in porting the operating system to their hardware, while on theother hand the risk is over-providing, duplicating solutions that at leastsome licensees wish to supply for themselves.17.8Moving Towards Standard C++A quite different, but no less important, perspective on renewal emergesfrom considering recent moves in Symbian OS towards a more standarduse of C++, as discussed in Chapter 15.David Wood:Historically, we were biased towards coping with programmers who couldhandle quite a lot of complexity themselves, so while the operating systemhides many, many complexities, still the bits that spill out are pretty difficult,and it requires a serious and very capable C++ software engineer to deal withit.We used to say, or some of us used to say, that if you’re a Java programmerstick with Java; if you’re a C++ programmer, convert to Java unless you happento be a very good C++ programmer, in which case you can stick with C++when you’re programming Symbian OS.
I’m not sure we quite said it like thatbut that was the implication. We didn’t make concessions for the ‘mid-range’C++ programmer.This is changing now, because we are at the stage where Symbian OS isgoing mainstream. When I say mainstream, I don’t just mean that more phonesare running Symbian OS, I mean that mainstream developers want to get theirMOVING TOWARDS STANDARD C++447applications ported onto Symbian OS and they’re not prepared to put up withthe level of complexity that early adopters have.We are looking at alternative run-time environments that hide more ofthe complexity. And you don’t get quite so much control, certainly, and youprobably end up with programs that are less efficient in several ways, but theadded power of the machine probably makes that a more acceptable trade offthan before.Python may be one of the examples David Wood has in mind.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
