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

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

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

With the product pushing the limits of its ROM budget,390JUST ADD PHONEmessaging saved the day by shipping some features not in ROM but asoptional installable packages on a companion CD.Keith de Mendonca:When we ran out of ROM space on the Communicator they decided to put thefax MTMs on the CD instead of built into the actual machine. It allowed themsome flexibility in the ROM. Likewise, IMAP4 was originally delivered as a SISfile because it was finished a little later than the messaging application, whichkind of proved that the architecture worked, you really could deliver thingsafter market.The flexible architecture and, in particular, the support for after-marketdelivery of MTMs by third parties and partners, which enabled messagingcapabilities to be extended for any future message types, had been amongNokia’s headline design requirement.Keith de Mendonca:It was responding to a customer-level requirement as far as we were concerned.But I’m not really sure to what extent that flexibility was really needed andyou could argue that it was over-engineered or the requirement was a bit tooheavy-duty, for the actual reality of what the application required.

There wasa vision of a new community of programmers writing corporate email plug-insand suchlike, but the downside of such an extremely flexible architecture isthat, unfortunately, often it can be quite complicated. This was quite a barrierfor programmers and there’s not really been a large market for those kindof MTMs to this day. But of course then you are left with your architecture,which you need to maintain and continue. A lean development model mighthave delivered the best value first, and then grown it as and when the appetiteof both companies grew and we understood better what the market reallywanted.Perhaps one of the more puzzling facts of the phone market to dateis that, despite the apparently huge popularity of products such as theBlackberry, email on phones has not yet proved a core function.

Ingeneral, messaging – other than SMS – seems to have made little impacton users to date.Keith de Mendonca:The Communicator was very advanced but also much of the same code wentinto the Ericsson R380, which was much smaller, but that was a really visionaryproduct as well. Everybody in the messaging team has picked up their mailon their phones ever since that day whenever it was, 1999 or thereabouts, yetMESSAGING: IT’S DIFFERENT ON A PHONE391that’s only becoming a relatively recent phenomenon for other people buyingphones.

So it was extraordinary power that there was inside the actual productright from those earliest days.What is the lesson? That making a phone operating system is not justabout putting cool technology in the box. The harder formula seems tobe – the right technology at the right time in the right product for the rightmarket.Meanwhile, flexibility implies complexity and the complexity of themessaging architecture has, arguably, had its downside.Keith de Mendonca:If I had my way again we would have presented less complex APIs for messaging. This complexity is one reason for the small number of people actuallyinnovating using messaging.

For instance, it’s quite a big job to port your owncorporate email solution that you might already have running on WinCE orsome other device, to then package those into the MTMs, understand thatparadigm and make it work on a Symbian phone. So it’s been a barrier tothat.But also performance became an issue, primarily with email, due tosome design decisions that were made early on. We also have been heldback, perhaps, by feeling very constrained by APIs and data structure storagemethods.

That looks ridiculous looking back now. Of course we are nowvery closely restricted by such considerations, because we sell so manyphones a month, but I felt very restricted about changing those thingsin Symbian OS v6.0 or between v6.0 and v6.1, when we would havesurvived making changes. But there was this compatibility promise verystrongly enshrined in Psion and Symbian in those times, that you couldn’tbreak binary compatibility, so it was quite difficult to make substantialchanges.The Universal InboxThere are two other lessons from the messaging experience, one aboutdesigning for the wrong use case and one about performance.Keith de Mendonca:Although we knew our primary goal was to produce mobile phones and thephone would always be there, there was still quite a lot of work, say in theSymbian OS v6.1 project, for two-box support, even though the particularproduct never came to fruition.

That probably resulted in the two-box concept392JUST ADD PHONEnot dying so quickly, although the company was focusing 100% on its newenvironment.One particular issue concerns the design of the message folders.Keith de Mendonca:When we designed messaging we had a concept of ‘the universal inbox’ [SeeFigure 15.8], so it didn’t matter if it was SMS or emails or whatever, theywould all appear in the same message store and appear physically in the sameinbox view. That’s exactly what we used to have on the Series 5, where, ofcourse, it was a two-box solution.

You put your phone next to it or connecteda modem to it and you downloaded all your email, that was the concept, andit all appeared in the inbox. And if you synchronized your SMSs, they wouldappear there too.But from the beginning we also started toying with an idea of offlineoperations, a remote mailbox view. The point was that because you werea small device and you didn’t have that much memory, you didn’t want todownload everything, because you didn’t know how big those things weregoing to be. Quite frankly you might not want to have them.

So you wouldsynchronize the headers, that’s all that appeared in the inbox, and then if youwere interested in anything, then you would populate the individual items andfill them up with their content. The view was then represented as an externalview, those messages didn’t appear as just headers inside the inbox, they wereactually shown as a separate independent view representing to the user thatthey were looking somewhere else, and in fact they were inside my very nicetree-structured message store browsing the complete structure of the messagecontents, which was very expensive in performance, not at all like just lookingat the headers.Now, in effect, the view on a phone is actually that offline view, certainlyit’s the way that Nokia displays them, it’s the view of your mailbox.

You nolonger just synchronize the headers, on a phone you go straight into browsingand opening and reading. So the concept of the universal inbox immediatelydies, because in the new model that we followed you had a remote viewof each of your email accounts and those messages never appeared in yourInbox.The difference between browsing the simple, inbox view of the messageheaders and browsing the elaborate, tree-structured representation of thecomplete contents of messages has a significant performance impact, onewhich, moreover, is tricky to resolve because the design is being used inan unintended way.There are other impacts too, which ripple down throughout the wholedesign. For example, the basic assumptions underlying the design of themessaging APIs are the wrong ones for some of the most common phoneuse cases.MESSAGING: IT’S DIFFERENT ON A PHONEMessagesMy Inbox393MessagingemailMessage...SMSMessage...MMSMessage...emailMessage...SMSMessage...My InboxRemote MailboxFigure 15.8 The universal InboxKeith de Mendonca:Consider the generic API for the MTMs, which includes Copy and Move, forexample.

Actually, you never copy or move anything to your inbox on ourphones. Those methods on that generic API for all of those MTMs are probablynever used nowadays, because the API doesn’t match the common usage, sothe methods are redundant. Should we have predicted that? But take a differentexample, along comes MMS and suddenly our original assumptions about theuniversal inbox start to make sense again, because now you can have amixture of SMS and MMS messages in the inbox. It’s become universal again!But it’s only when that MMS technology reared its head that you actually hadsomething else to go in your universal inbox, because remember, emails arealways set off alone in their own view anyway.

But can we claim that ourdesign was right after all?It is not so much a point about user interface design, because theunderlying conceptual design is interpreted by the user interface in a waythat suits the user interface paradigm.Keith de Mendonca:Of course it’s up to the UI how it actually presents those things. On UIQphones, it doesn’t mix them all together in the inbox. It shows you differentmessage types and it ‘pretends’ they’re all in the same general location.394JUST ADD PHONEConceptually they’re stored in a different structure underneath these remoteservices.The underlying conceptual design does, however, have a strong impacton how the system APIs below it, and which support it, are used.

Inthe case of the original design of messaging, the supporting APIs aremisused.Misusing StoreKeith de Mendonca:The conceptual model for the message store is a logical tree structure withthe root at the top. Underneath the root there are the folders that you knowabout, the Inbox, Outbox, Drafts and Sent, also some representations of otherthings that are on the device; those are all seen as local services. It also has theconcept of remote services, so your email at work technically would be theSMTP email server at work, or there’s the fax machine you are trying to sendto or the SMS service centre that you’re sending your message to. Normallythose things are invisible, but they still exist physically and are representedinside the message store.Symbian OS supports folders, and it’s very flexible – you can create anynumber of folders and put any number of messages in folders.

Logically that’sjust a tree stored in RAM, in a RAM index effectively, but also it’s written ontodisk in case the battery fails, and it uses the Stream interfaces which are partof the Store in Symbian OS. It was designed in the same way that we designedmost things, to be robust and never to lose data if you lost power. Thereforethere’s a lot of writing to disk, and as we know and have learnt, the Storecomponents themselves, because they are so careful in making sure that youcan never lose any data, are also quite expensive in disk writing.This wasn’t a problem when we wrote the message architecture, because itwas designed for the Psion Series 5 which had a RAM disk and didn’t have anyperformance problems.

However, it started to create some problems if you putyour message store on a removable CF card, which was the first-generationflash technology.The team made minor modifications to their implementation whenperformance problems began to manifest themselves on real hardware.The fact that development was in the first instance carried out underemulation didn’t help matters and the inevitable desire of licensees tokeep prototype hardware under wraps didn’t help either.MESSAGING: IT’S DIFFERENT ON A PHONE395Keith de Mendonca:A lot of last minute changes were made to try to improve the performance,including for the Symbian OS v6.0 release which went into the Communicator.One change was that we decided we couldn’t afford to use Store for thosesmall files, and we actually created our own store without changing the API.So from the public interface it would seem as if Store classes still exist, but wejust wrote a binary file format which was faster, with some loss of robustnessif the battery failed.Also, email messages were described in the filing system not as a singlemessage containing all the data for an email, but as a tree of objects representing exactly the MIME structure of that email.

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

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