The Symbian OS (779886), страница 83
Текст из файла (страница 83)
This meant you had an awfullot of files or objects for representing one message. This was true especiallyfor HTML-style emails which are the standard way of sending emails now,because they not only send you the HTML version which has the completecontent associated with it, but they also send you a simple text version as well,and of course we stored that as well. You may have 8 or 10 individual files representing an email, and if you have 8 to 10 files to write then obviously it willbe slow.
That’s a basic challenge that we have even today, the performance ofdownloading emails, where we still have to create all those physical objects.As in any other areas of the operating system, performance issues arecontinually reviewed and implementations tuned. But no one likes to havebeen wrong-footed by designing for a use case which changes becausethe overall device design point changes, as happens, for example, in themove from PDA to phone assumptions.Keith de Mendonca:Obviously, you would like to start again knowing where a lot of the faults are.But we are still constrained, we can’t break this binary compatibility which wehave offered so long, because the cost to customers and others of changing themessage applications is quite expensive if we make any changes.
So we workwithin the boundaries of our compatibility requirements and we’re alwaysmaking improvements.Another compounding problem was the unfortunate interaction of theStore design with the behavior of Flash memory systems. Having beendesigned in the context of a conventional, fast, random-access, RAMdisk-based file system, the design turned out to be weak in the contextof sequential-access, fast-reading but slow-writing flash hardware. Store,designed to offer a transaction-style, robust, append-based file system396JUST ADD PHONEdoes not have a natural concept of updating already written data.
Streamsare appended sequentially to the physical medium and the header indexis updated to point to them.In the worst possible use case for a flash-based system, the designof Store ensures that it only ever grows and, in the worst possible usecase, it even grows to delete things, depending for its space performance(so that it does not outgrow available memory resources) on a regularcompaction cycle.
The reason, of course, is data integrity, and that mostbasic, fundamental guiding principle of the operating system: ‘Thou shaltnot lose the user’s data’.To some extent, the problems with the early version of the messagingframework highlight a more subtle problem.Martin Tasker:The ground rules that we gave ourselves when we were making the PDAare not the same as the ground rules in the mobile phone space. We toldourselves that the ground rules are that you should assume you’ve got verylittle memory, and you should assume that the process is going to run forever,but also to assume that you’re not in an embedded OS context where you cangive a fixed partition to everything.The thing is that in the mobile phone world, you do have system restartsand memory management is more complicated.
If you look at the phonefrom a high-level perspective, don’t just ask about the details of programming.Instead, ask about the dynamics of the number of applications and the numberof services and how often it is turned on and off and how you allocate memorywhen you’re sharing it between the programs, and look at the data storageand the RAM. The answers to those questions are different from those that weoriginally looked at in the PDA context.It is not that the problem is one of greater complexity; it is differentcomplexity.For Ian Hutton, the distance between the early phone projects suchas the Nokia 9210 and the Ericsson R380 and the phone projects thatSymbian is involved in today, is the best demonstration that the hardlessons have been absorbed and the big step has already been made.Ian Hutton:I think the fact that we really are now beginning to see very, very ordinaryphones, not just the incredible phones but ordinary phones with Symbian OSinside, phones that will still do anything you want, but are very similar toordinary mid-range phones.
In a way, that’s the biggest step.16One Size Does Not Fit All: The RadicalUser Interface Solution16.1 IntroductionSymbian OS is an inherently GUI-centric operating system which shipswithout a GUI of its own.1 Moreover it targets a market (wireless devicesgenerally and mobile phones in particular) in which the user interface isa critical competitive element. Delivering an operating system without auser interface is a radical software solution to a business dilemma: howto create a common, multi-vendor platform for phones, while at the sametime not merely supporting but positively driving vendor differentiation.This case study traces the evolution of Symbian’s user interface architecture and strategy.
User interface issues are particularly interestingbecause they highlight many of the unique problems of the mobile phonemarket. It is significant that Symbian’s user interface architecture and userinterface strategy have both undergone some quite radical transformationssince the company was first created.Although in computing terms the specification of a typical phone basedon Symbian OS in mid-2006 is equivalent to that of a mid-range PC of themid-1990s and exceeds that of a mid-range PC of the 1980s by an order ofmagnitude,2 nonetheless a mobile phone is only incidentally a computingdevice. It is simply not thought of by users as being ‘a computer’ (What1I use the terms GUI and UI almost interchangeably in this chapter; and use ‘GUI’ whenI want to emphasize the graphical aspect in particular.280386-based PCs clocked at a maximum of 33 MHz in 1985; 80486-based PCsreached 100 MHz by 1994; Nokia N series phones have reached 300 MHz in mid-2006.IBM’s top of the range PS/2 machine, the 1987 Model 80 (with a list price of more than$10 000 – without adjusting for inflation!) featured a 16 MHz processor, 16 MB RAM, and140 MB hard drive.
The Nokia 5500 shipped with 64 MB RAM and supported removeablecards up to 1 GB.398ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONis it then? It’s a phone, stupid!). As I have argued in previous chaptersphones are ‘just different’ from PCs and PDAs.Phones have evolved rapidly from the clunky business tool of the1980s to the seemingly essential ‘upscale accessory’ of 2006. In particular they have become consumer goods – ‘and we cannot expect theuser to configure them’.3 But high-end phones have also become application platforms and this, in particular, has been the ground staked outby Symbian, which has deliberately set out to create an open platformfor third-party software development.
Where mobile phones began asthe ‘functionally direct replacements of their wired forebears’, they haveevolved a long way beyond those beginnings, boosted by the rich varietyof available applications and by dizzying competition between vendorsto outdo each other with new software and hardware features. Theyhave become quite independent platforms for personal communicationin modes both new (picture messaging, text messaging, and phoninghome from the train, plane, street or shop), nearly new (email on the go)and old (plain old voice from home or office); for personal broadcasting(mobile blogging, web-sharable photo albums); and personal entertainment (games, MP3 players, pocket web browsers, pocket TVs).
If they everwere just functional replacements for fixed-line phones, they certainlyare no longer. With astonishing speed, mobile phones have become‘platforms for entertainment and commerce and tools for informationmanagement and media consumption’; everything in other words frombusiness tools to games players to shopping tools to fashion accessories.Differentiation: The Big IdeaThe goal of differentiation is to avoid selling on price alone.
Operatorslook for ways to apply their own branding to phones and to add valuethat will not be available from competing operators. On occasion theystrike exclusive licensing deals or negotiate periods of exclusivity withvendors for particular phones. At the very least, most operators demand aminimum degree of customization of phones from vendors, for exampleoperator-specific packaging, stenciling of the operator name or brandedlogo onto phones, and inclusion of custom operator applications orsupport for dedicated operator services on phones (for example, O2’sHomezone and Vodafone live!).This is not quite the same as vendor differentiation, which is the mostvisible form of differentiation.
For phone vendors, differentiation – of theirphones from those of their competitors – encompasses everything fromdesign philosophy and style through reliability and build quality to easeof use and, of course, technologies and features.3The quotes in this section are from Keinonen [Lindholm et al. 2003, p. 4] and Kiljanderand Jarnstrom [Lindholm et al.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
