The Symbian OS (779886), страница 86
Текст из файла (страница 86)
It may have ultimatelydisappointed in terms of sales, but it did come up with a lot of good ideasand it solved quite a lot of problems in terms of turning what was then EPOCRelease 5 into fully-fledged phone platform.The project also contributed key technology back into the operatingsystem. The View Server for example was originally developed by theEricsson R380 team but has evolved into a key feature of the UI frameworkarchitecture.Ian Hutton:Initially it was used to solve a slightly different problem in the Ericsson R380,which was the flip mode. So it was initially written for flip open and, infact, not just for the flip, it was for landscape mode too.
It was written bySymbian’s Licensee Technical Consulting (LTC) team for the customer project,and then the larger software engineering group was presented with it by theUI architects. Consequently, it was adopted back into the core architecture.Accepting licensee (or LTC) changes back into the operating systembaseline and evolving them forwards thereafter as part of the platform hasbeen a central principle of the licensing model, right from the beginning.Making the mechanism work has not always been so easy, however.Ian Hutton:The issue is how to manage migration of changes initiated by projects tosupport project-specific and even device-specific requirements which thenmay have more general applicability and value, and migrate them back intothe software base to avoid the base branching. So there’s really a continuousprocess of splitting and some fragmentation, and then reunification – bringingit back together.In part, the problem came from organizational tensions, the support forlicensee projects being provided by a different engineering organizationthan the main operating-system engineering teams.
Over time, the company has become adept at managing the process but there are still keyhotspots around defect triage, change requests, engineering changes, andproduct requirements and the inevitable balancing of priorities betweenthem.41016.4ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONThe Device Family StrategyPlatformization of the operating system had always been a goal, whetheror not it was a licensed platform or simply a Psion internal one. Thelicensing strategy was a logical next step.
However, it is reasonable toargue that Symbian was not well prepared for the reality of running multiple licensee projects either in the practical sense of the straightforwardlogistics involved – it was highly difficult to resource and put immensestrain on the company – or in the more narrow technical sense of how tomanage the codebase-development practicalities.Ian Hutton thinks that the Ericsson R380 project was significant in atleast one other respect.Ian Hutton:Pretty much through the whole of that project it was difficult for LTC to workwith the software-engineering organization.
It was at the end of that projectthat the DFRD strategy was written.For all the problems of branching and the resulting wrangles tomigrate changes back into the main codeline, there was an underlyingstrategy emerging. It was eventually announced at CeBIT in Hanoverin February 2000 as the ‘reference design’ strategy, based on so-calledDevice Family Reference Designs (DFRDs). As well as announcing a jointMotorola–Psion device, Symbian was showing off Ericsson ‘mediaphone’prototypes based on what it called the Quartz DFRD – quarter-VGA,pen-based, PDA-style tablet devices with built-in phones and Bluetooth(enabling the use of remote headsets).DFRDs emerged out of the need to resolve the problem of multiple, incompatible UIs.
And it provided direction for Symbian and itsengineering practice.Martin Budden:The problem was that it was not possible to come to agreement for a Symbianbased UI that was suitable for all parties. So this was when the idea of resolvingall these conflicts with the DFRD approach emerged.The engineering teams were at least in a position to abstract fromthe day-to-day problems of competing and conflicting projects and agreesome higher design principles.THE DEVICE FAMILY STRATEGY411Martin Budden:The idea was to have families of UIs. There would be one family which wasbased on the Nokia Communicator and the Series 5; there would be a familythat was based on the Ericsson R380; and at about this time Quartz was startedup for Ericsson, which was for the quarter-VGA tablet form factor.The actual reference design specifications were based around a combination of screen size and orientation and input method.
To an extent,the design points were really just rationalizations of the known preferences of the different licensees and were closely modeled on actualproducts that were already in development in licensee collaborationprojects.The DFRD strategy helped Symbian recognize that the phone worldwas complex and took a step forward from simply solving problems tosystematizing the solutions.The DFRD model set out to provide enough flexibility to supportlicensees across a wide spectrum from those, such as Nokia or DoCoMo,who had both the resources and the desire to create their own bespokeUIs, through a middle band of licensees who while not looking fora complete off-the-shelf solution preferred to work closely with a UIsupplier like UIQ Technology than make the considerable investment tocreate their own UIs from scratch, to the smallest licensees who werelooking for a near-complete solution and a fast product-developmentcycle.
In effect, it reflected the standard tiering of phone vendors used byindustry analysts:• Tier One licensees create complete devices end-to-end: typically theyexpect to buy in Symbian OS and create or license bespoke UIs; theycreate lead products for new Symbian OS releases.• Tier Two licensees create hardware platforms from standard parts:typically they expect to buy in Symbian OS with a pre-integrated UI;they create follow-on products from proven Symbian OS releases.• Tier Three licensees focus on custom packaging of external phonedesign: typically they expect to buy in complete (‘80%’) hardwarereference designs (from silicon vendors such as Intel and TI), withSymbian OS and their chosen UI pre-integrated onto hardware.Bob Dewolf joined Symbian in early 1999 when Symbian acquiredthe Origin software consultancy.
He had been working on embeddedsoftware for pagers and fixed-line phones.412ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONBob Dewolf:I had just done a Farsi pager for Philips, and a smaller pager written in 16 KB ofassembler, so that was quite the opposite of smartphones. But it wasn’t a badmatch because you had the embedded aspect from both pagers and telephonework and I had UI experience.Symbian’s DFRD strategy was newly in place.
As a veteran of the earlyevolution from Eikon to what became Series 60, he knows as much asanyone, and probably an awful lot more, about the problems of craftinga phone GUI.Bob Dewolf:In that period between April and July 1999, we were in meetings with licensees,primarily in London, and they would get up and talk about their various plansfor screen sizes and other key GUI design features.
Those meetings were very,very important for Symbian to define a DRFD which fitted those users.The first two DFRDs, known as Crystal and Quartz, were relativelystraightforward to define since each in effect abstracted the actual properties of the particular target devices of projects which were well advanced.Each, in other words, had a single, clear customer. Crystal defined akeyboard-based device in the style of the Nokia Communicator, applicable to the Nokia 9210 and the Psion Series 5. Quartz defined apen-based, tablet-style device applicable to prototypes that Ericsson (aswell as other licensees) publicly demonstrated not long after.
BetweenCrystal and Quartz, however, there was a missing form factor – that ofa more or less conventional phone or, at any rate, a high-end devicethat was recognizably a phone in the sense in which the Ericsson R380clearly was. The Sapphire DFRD was defined to meet the need of thethird category.Bob Dewolf:The categories were QWERTY-keyboard-oriented, which was Crystal; penoriented, which was Quartz; and telephone keypad, which came to be calledSapphire.Even then, the licensees who wanted to pursue designs in the Sapphirecategory had conflicting design philosophies.THE DEVICE FAMILY STRATEGY413Bob Dewolf:One licensee would not be pen-oriented, while another didn’t want to doanything without a pen. One licensee was very Java-oriented; another licenseewasn’t.
We talked about Blue Sapphire and Red Sapphire at that point,and I remember people trying to figure out how we’d have polymorphism.David Wood then produced some extremely interesting and abstract workabout data and layout separation, and about abstract specification of components. I remember thinking, ‘Yes, this is the way to do it’, and saying, ‘weshouldn’t talk about those screen sizes, that’s the last possible thing we wantto talk about, we should be talking about the abstract definition of controlsets!’However, at the end of summer 1999, Sapphire was still blocked.Bob Dewolf:Then Nokia said they had a full design concept, and simply wanted tostart developing. So one day about four people from Nokia arrived and wedecided to see what happened. Originally, they were working from Sapphiredocuments, but not long after the name was changed to Pearl.Out of the ashes of Sapphire, the DFRD that emerged was Pearl.By defining a new DFRD, the unresolved problems of Sapphire werecircumvented.
It seemed clear to those close to it that Pearl was stronglydriven by Nokia.Bob Dewolf:Nokia had very strong time constraints. I remember sitting in meetings wherewe cut up responsibility for various types of things like soft keys and notes andqueries and list boxes to various people and asked when they could get thatdone.A lot of the main decisions for the architecture were made during thatperiod.
In fact it’s surprising how many of the things we still have are based ondecisions made in that period, things like doing all our multitap and key tries,like internationalization in the FEP (Front End Processor); using CEikDialogas the base class for notes and queries and forms, which you use in contacts;using the listbox-based classes, using the view architecture, and that was beingpushed very strongly because of the Ericsson R380’s success with the viewarchitecture.Some of the core architectural decisions were made at that point.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
