Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 6
Текст из файла (страница 6)
This includes a discussion12INTRODUCTIONof any important aspects for resolving the specific example that are notcovered by the analysis elsewhere in the pattern.Other Known UsesOne or more brief descriptions of additional real-world examples, basedon Symbian OS, are given here of the use of the pattern. Often these areuses originating from within Symbian OS since that’s the area we bestunderstand, though we have also included examples drawn from externalsources. These examples are not described in great detail, only enoughto outline how the pattern has been used.Variants and ExtensionsA brief description of similar designs or specializations of the pattern.ReferencesReferences to other patterns that solve similar problems as well as topatterns that help us refine the pattern we are describing.1.7 Structure of this BookThe patterns in this book cover the following topics:• Error-handling strategies: How to handle errors effectively so that theirimpact on the end user is minimized• Resource lifetimes: How to work effectively with the constrainedresources available to a Symbian OS smartphone• Event-driven programming: How to conserve power whilst reducingthe coupling between your components• Cooperative multitasking: How to take advantage of Symbian’s cooperative multitasking framework and get the appearance of multithreading without the associated costs• Providing services: How to make your functionality available tomultiple clients either individually or concurrently• Security: How to use the platform security architecture to secure yourown application and services• Optimizing execution time: How to increase the speed with whichyour software executes and reduce the time it takes to start upOTHER SOURCES OF INFORMATION13• Mapping well-known patterns onto Symbian OS: How to apply wellknown design patterns, such as Adapter, Singleton and Model–View–Controller, on Symbian OSIn each case, whether you’re a device creator or an applicationdeveloper, you’ll find all of these patterns help you to write software thatbetter harnesses the unique characteristics of mobile devices.1.8 ConventionsTo help you get the most out of this book and keep track of what’s happening, we’ve used a number of typographical conventions throughout:• When we refer to words used in code, such as variables, classesand functions, or to filenames, then we use this style: iEikonEnv,ConstructL(), and e32base.h.• When we list code, or the contents of files, we use the followingconvention:This is example code;• URLs are written like this: www.symbian.com/developer .• Classes or objects that form part of Symbian OS are shown in adarker color to indicate that they should be reused when a pattern isimplemented.
Classes or objects that you are expected to implementyourself are shown in a lighter color.1.9 Other Sources of InformationSeveral times in this book we refer to the Symbian Developer Library(SDL). This is available online at developer.symbian.com/main/oslibraryand is integrated into the documentation that comes with the S60 andUIQ SDKs, which can also be found online on Forum Nokia (for S60) atwww.forum.nokia.com and (for UIQ) on the UIQ Developer Communitywebsite at developer.uiq.com.The official website for this book can be found at developer.symbian.com/design patterns book . You can download sample code, read aninterview with the lead author and download an electronic copy of thefirst chapter.
The sample code provided on this site will be a fuller versionof the code snippets given in the implementation sections of selectedpatterns. Whilst this sample code will not be from a real-world example,14INTRODUCTIONit will be illustrative of the associated pattern particularly because it’ll becomplete enough to be run. However, don’t forget that this code shouldnot be simply be cut and pasted into your production code, not leastbecause patterns are not strict templates but rather guidelines that shouldbe modified to suit your specific environment.You can find links to related articles and sites with additional information about patterns on the wiki page at developer.symbian.com/designpatterns wikipage. The wiki can also be used to send us feedbackabout the book or even to submit your own favorite design patterns forSymbian OS.2Error-Handling StrategiesThis chapter deals with patterns for handling errors appropriately so thattheir impact is mitigated and dealt with effectively.
We first need to definethe categories of software errors that can occur:• Domain errors are associated with a particular technology. Theyindicate that a problem that can be expected to happen at somepoint in time has occurred. An example of this type of error is gettingKErrNotFound as a result of a multimedia application trying to openan audio file specified by the end user. The failure to find the file hasa specific meaning for the software receiving the error.• System errors are the result of attempting some operation that fails dueto a restriction of the system. KErrNoMemory is an obvious example,since it occurs whenever a memory allocation fails due to the memoryconstraints imposed by the system.• Faults occur because of programming errors. They result in abnormalconditions that cause a failure to execute the desired functionality ofa particular system.
Examples include null pointer dereferences andout-of-bound array accesses. User applications, core system servicesand the kernel can all suffer faults because of the same commonfactor: the human engineer.Some other useful terms we should define here are:• Defect – also known as a bug, these are flaws, mistakes and failuresin software that prevent it from behaving as intended.
All faults aredefects but not all defects are faults. For example, software could besaid to be defective if it has been not been implemented accordingto the original requirements specified. It is also important to notethat domain and system errors are not defects in themselves, becausethey result from circumstances outside the control of your software.However, the handling of these kinds of errors could result in a defect.16ERROR-HANDLING STRATEGIES• Resolving an error – an action is taken at run time within a softwarecomponent to return the execution back to normal operation. Forinstance, this may be as simple as retrying an operation or providinga useful message to the end user to report what has occurred.• Handling an error – an error is either resolved or deliberately passedon for another component to resolve.Defects in software are a reality and, no matter what we do, theycan never be completely eliminated.
As the size and complexity of asystem increases, so does the potential number of defects present. If weare careless in designing a system, then this increase in defects can beexponential since the number of defects grows in line with the numberof interactions in the system which itself grows exponentially as thenumber of components increases. One of the reasons for using interfacesand patterns such as Façade [Gamma et al., 1994] is that they reducethe number of different interactions.
Another thing to remember is thatany modification made to software has a probability of introducing newdefects which means that defect fixes can give rise to yet more defects.When targeting mobile devices, such as Symbian OS smartphones,there are some specific issues that need to be taken into account whendesigning software:• End users have expectations of high reliability from their deviceswhich means error handling should be considered carefully whendesigning software for Symbian OS.
Mobile phones are consumerelectronics and are considered to be completely reliable. They are notexpected to behave like computers, which are forgiven the need for anoccasional re-boot, but are expected to function perfectly wheneverthey are used.• A significant proportion of mobile phone users are not very technically literate and so do not expect to have to fix software problemsthemselves or try to understand cryptic error dialogs.• Patching your software is possible on most Symbian smartphones butshould be avoided where possible since it’s likely to cost the end userto download the new version over the network.The first pattern in this chapter, Fail Fast (see page 17), helps youreduce the number of faults that are present in your released softwareand minimize the impact that they have when they do occur.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
