Symbian OS Explained - Effective C++ Programming For Smartphones (2005) (779885), страница 3
Текст из файла (страница 3)
This places huge importance on efficient power management. Theoperating system cannot drain the battery and must allow the processorto power parts of the system down where possible, although it cannotever power off completely because it must handle incoming calls andmessages, and signal alarms.The user expects the phone to be responsive, not sluggish to respondto each key press; the operating system and hardware must carefullybalance demands for good performance speed with the consumptionrequirements of power-hungry processors.
Costs are also important: theylimit the processor and amount of memory in a mobile device. Theoperating system must be efficient, to make best use of the limitedprocessor and memory resources available, whilst using the least power.Besides being efficient, the operating system must be robust whenthe limited resources are exhausted. It must be engineered to cope withlow memory conditions, loss of power or when a communications linkis unavailable. Memory management is key.
The operating system musttrack precious system resources accurately and free them when theyare not required. It’s not acceptable for memory to slowly leak away,resulting in disintegration in performance and usability until the user isforced to reboot. The operating system should make it easy for softwareengineers to write code that runs without memory leaks and can handleout-of-memory conditions when they occur.The mobile phone market is a mass market, with many millions ofunits shipped. It’s difficult, if not impossible, to recall them or require theuser to upgrade through service packs.
So when a phone is shipped, it’sshipped. It must not have any serious defects. Not only must the platformon which a phone is based be well-engineered, it must also provide themeans for developers to build, debug and test robust code.As users, we also demand that our mobile phones are as cheap aspossible. We want the latest, trendiest phone, which may just be smallerthan the last, or have additional features like Bluetooth, an integratedcamera or video player, or an MP3 player. This means that the lifetime ofa phone in the marketplace is limited.
When a manufacturer develops aABOUT THIS BOOKxixphone it must be ready for market as quickly as possible and the operatingsystem should ideally be flexible so the basic design can be extended orupgraded and released in a different model.Symbian OS was designed for mobile devices, from its earliest incarnation as EPOC32 in the Psion Series 5. Many of the requirements oftoday’s mobile phones applied equally well in those days, and its designreflects that. The huge demands upon a mobile operating system haveshaped Symbian OS, from resilient power-management and careful useof memory resources, to the sophisticated use of C++ and object-orientedprogramming techniques. As a developer on Symbian OS, you benefitfrom a platform which was created specifically for mobile devices andwhich has evolved with the market.Of course, the responsibilities don’t stop with the operating system.To work most successfully on a mobile phone, your code must alsobe efficient, robust, responsive and extensible.
Some of the problems ofmobile computing are notoriously difficult to solve and programming inC++ is complex at the best of times. It’s not easy, but opting to work onSymbian OS gives you the benefits of a purpose-built platform. This bookbrings you the best advice from those experienced in working with it.Author BiographyJo StichburyJo Stichbury was educated at Magdalene College, Cambridge, where sheheld the Stothert Bye-Fellowship. She has an MA in Natural Sciences(Chemistry) and a PhD in the chemistry of organometallic Molybdenumcomplexes. After a brief spell in postdoctoral research at Imperial College,she joined Psion Software in 1997, when Symbian OS was still knownfondly as EPOC32.
She has worked with the operating system ever since,within the Base, Connectivity and Security teams of Symbian, and alsofor Advansys, Sony Ericsson and Nokia.As the contents of this book will reveal, Jo has a somewhat unhealthyinterest in the Clangers and Greek mythology. She currently lives inVancouver with her partner and two cats.Author’s AcknowledgmentsOnce upon a time, when I joined Psion Software, there weren’t any booksavailable on Symbian OS (which was known then as EPOC32). So I’dlike to acknowledge, with gratitude, the support I received from MorganHenry, Matthew Lewis, Peter Scobie and Graham Darnell, who helpedme take my first steps as a programmer.
I intend this book to record theirinsight and knowledge as I’ve interpreted it, as well as that of all the otherSymbian OS developers I’ve worked with since.I am grateful to everyone who has contributed to this book. Leon Clarke,Will Bamberg, Mark Jacobs and Paul Stevens made useful suggestions atthe early stages; later on, Julian Lee, Keith Robertson and Dennis Mayanswered my technical questions. Will Bamberg provided me with hisown well-crafted documents on leaves and out-of-memory testing – anddidn’t complain when I de-articulated them for inclusion in Chapters 2and 17.The input from all my reviewers was much appreciated. I would like tothank the official reviewers: Keith, David, John, Colin, Andrew, Morgan,Martin, Phil and Reem who all contributed enormously to the technicalaccuracy of this book and to my peace of mind.
I also received manyhelpful contributions from Peter van Sebille and John Blaiklock at SonyEricsson, Mark Jacobs and William Roberts at Symbian and Will Bamberg.I’m very grateful to Dave Morten, Steve Burke and Brigid Mullally atSony Ericsson, for showing understanding about the time it took me towrite this book. I couldn’t have done it without their cooperation. Thediagrams in this book were inspired by Brigid.This book would also have been impossible without the help andsupport of my partner Mark, who makes everything possible. Since Istarted writing, I’ve also acquired two Siamese cats, who have spentmore time distracting me than helping but, for that alone, they deserveinclusion here.xxivAUTHOR’S ACKNOWLEDGMENTSI would like to thank Symbian Press, particularly Freddie Gjertsen andPhil Northam, for their patience and fortitude.
Thanks must also go toGaynor Redvers-Mutton at John Wiley and to Karen Mosman who startedthe ball rolling.I’d also like to thank Oliver Postgate for granting me permission toinclude the Clangers.Symbian Press AcknowledgmentsFirst and foremost we would like to thank Jo for her tireless endeavour inthe production of this book.Thanks are also due to all our reviewers, named and otherwise, andespecially to young Phil, choleric beyond his years. Where would we bewithout ”constructive” criticism?And last, but not least, thanks to the lovely Boundary Row tea-ladies,Gayle and Victoria.
Without constant refreshment to sustain us, SymbianPress would be nought.Cover design based upon a concept by Jonathan Tastard.Code checklist based on the documentation of System ManagementGroup, Symbian.1Class Name Conventionson Symbian OSLlanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogochThe longest place name in the British Isles, said to be invented toattract touristsSymbian OS defines several different class types, each of which hasdifferent characteristics. The categories are used to describe the mainproperties and behavior of objects of each class, such as where they maybe created (on the heap, on the stack or on either) and, particularly, howthey should be cleaned up. Each of the class types has a well-definedset of rules which makes the creation and destruction of instances of thatclass quite straightforward.To enable the types to be easily distinguished, Symbian OS uses asimple naming convention which prefixes the class name with a letter(usually T, C, R or M).
Naming conventions aren’t always popular,but this one isn’t difficult to follow and is clearly of value, since itallows the behavior of a class to be easily identified, particularly withrespect to cleanup. As a class designer, the class types simplify matters.You consider the required behavior of your class, and match it to thedefinitions of the basic Symbian OS types. Having chosen a type, youcan then concentrate on the role of the class. By the same token, asa client of an unfamiliar class, the naming convention indicates howyou are expected to instantiate an object, use it and then destroy it in aleave-safe way.1.1 Fundamental TypesI’ll discuss the main features of each class type in this chapter. However,before doing so let’s go back to basics and consider the fundamentaltypes.
Symbian OS provides a set of typedefs of the built-in types,2CLASS NAME CONVENTIONS ON SYMBIAN OSwhich are guaranteed to be compiler-independent; these should alwaysbe used instead of the native types.• TIntX and TUintX (for X = 8, 16 and 32) for 8-, 16- and 32-bitsigned and unsigned integers respectively. Unless you have a goodreason to do so, such as for size optimization or compatibility, youshould use the non-specific TInt or TUint types, which correspondto signed and unsigned 32-bit integers, respectively.• TInt64. Releases of Symbian OS prior to v8.0 had no built-in ARMsupport for 64-bit arithmetic, so the TInt64 class implemented a64-bit integer as two 32-bit values.
On Symbian OS v8.0, TInt64and TUInt64 are typedef’d to long long and use the availablenative 64-bit support.• TReal32 and TReal64 (and TReal, which equates to TReal64)for single- and double-precision floating point numbers, equivalent tofloat and double respectively.1 Operations on these are likely tobe slower than upon integers so you should try to avoid using themunless necessary.• TTextX (for X = 8 or 16), for narrow and wide characters, correspondto 8-bit and 16-bit unsigned integers, respectively.• TAny* should be used in preference to void*, effectively replacingit with a typedef’d ”pointer to anything”.
TAny is thus equivalentto void but, in the context where void means ”nothing”, it is notnecessary to replace the native void type. Thus, a function takinga void* pointer (to anything) and returning void (nothing) willtypically have a signature as follows on Symbian OS:void TypicalFunction(TAny* aPointerParameter);This is the one exception to the rule of replacing a native typewith a Symbian OS typedef; it occurs because void is effectivelycompiler-independent when referring to ”nothing”.• TBool should be used for boolean types.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
