Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 44
Текст из файла (страница 44)
Since it is the first state, when should it be sent to the system? If itis changed by the system starter before anything is started then there willbe no responders registered to receive it, but there is no point in sendingthis change too late in device start-up.The domain manager solves this by allowing a responder to requestthe current state of the domain it is joining. This value would be thelast change that was distributed via the domain manager and so allowscomponents that have only just subscribed to obtain the last state changethat was performed.This allows the system starter to request the ECriticalBoot changeat the beginning of start-up so that when other servers, such as thecommunications server, are started they can tell from the domain managerthat the last change was ECriticalBoot and respond accordingly as ifthey had just received that change.The code for performing this would be similar to the following, whereCCommsServer is derived from CDmDomain which is derived fromCActive:30CCommsServer::InitializeStartupCoordinator(){...// First request notification of the next state change30 SeeActive Objects (page 133).230PROVIDING SERVICESRDmDomain::RequestTransitionNotification(iStatus);TInt currentState = GetState();if(currentState >= ECriticalBoot){// Already part-way through boot, so perform// critical initialization actionsPerformCriticalInitialization();}if(currentState >= ENonCriticalBoot){// If it is already past ENonCriticalBoot then perform// the non-critical initialization.PerformNonCriticalInitialization();}...}Care must be taken to request notification of the next change beforeperforming other actions, including acknowledging a notification, toeliminate the possibility of missing any future changes.This highlights how important it is to define the model correctly.In this case, the definition of the ENonCriticalBoot state changemeans that if a responder first sees ENonCriticalBoot then it shouldperform all the actions for ECriticalBoot in addition to the onesfor ENonCriticalBoot.
This is an issue which does not occur in allsituations where this pattern is applicable and the relevance of this issuedepends on what changes are distributed as well as the relationshipbetween the changes. Here the changes are cumulative whereas in othersituations they might not be.Other Known UsesIn addition to the system start-up example, the Coordinator pattern isused in the following examples:• View SwitchingThe view server acts as a coordinator to allow different applicationviews to be brought to the front of the UI. The coordinator canbe accessed through the CCoeAppUi class.
The application views,derived from MCoeView, are each responders, with the views havingactivation or de-activation state changes requested on them accordingto which view was requested to be activated by the controller of theview server. Not all registered views are notified on a view change,only the current view and the view which is going to become thecurrent view, so the dependencies model is more complex than givenin previous examples in this pattern.
Note that the view server uses atimeout when switching views to prevent hung clients from stoppingall view-switching activity.COORDINATOR231The view server architecture is described in detail in the SymbianDeveloper Library and the full complexity of it goes beyond what isdescribed here.• Save NotifiersThe save notifications provided by the shutdown server via CSaveNotifier is another example of this pattern being used, with ‘save data’events being the state changes distributed across the system. This givescomponents the opportunity to save their data before the device shutsdown. The shutdown server acts as coordinator between the responders deriving the CSaveNotifier class.
The Look and Feel (LaF)shutdown manager generates the save data events and so acts as thecontroller, with the shutdown server acting as the coordinator.Variants and Extensions• Multiple ControllersThis pattern assumes that there is only one controller in the system.However, it can be extended such that a controller service is exposedby the coordinator process. This would allow multiple controllers torequest state changes from all the responders. One problem with thisvariation is that it divides up the control responsibility between multiple objects which makes maintenance that much harder. However,this variation can work well when the state changes sent by eachcontroller do not overlap.• Response TimeoutsThis pattern is susceptible to being blocked by a responder whodoesn’t respond to the state change notifications quickly enoughor even at all.
One way to deal with this is to start a timer onceall responders at a particular layer have been notified of the statechange. Those that don’t respond within a specific time are senta StateChangeCancel() and the entire state change is failed.However, this is a fairly inflexible approach and you should alsoconsider more sophisticated approaches such as first sending an ’Areyou alive?’ signal to slow responders to give them the opportunity torequest more time.• Status ReportingYou may find it necessary for the coordinator to provide a statusreporting service that allows clients, such as the controller, to obtainuseful information such as the most recent state change and what itsstatus was.
If a state change did fail then you could provide diagnosisinformation such as which layer it failed in.This is particularly useful when the coordinator fails to completea state change across all the responders: they will probably be in232PROVIDING SERVICESan inconsistent state. With the current pattern implementation whenthe controller is resolving the error it does not have any informationabout which responders did manage to successfully complete theirstate change.
This additional service would rectify this.One danger is that you expose the responders to the controller andhence start introducing dependencies between them and reducing theflexibility of your implementation.• Combined Acknowledgement and Re-registrationThis description of the pattern assumes that responders don’t alwayswant to re-register for state changes.
However, if this is not the casethen you may wish provide an additional acknowledgement method toMCoordinator. This method would combine the standard responderacknowledgement with a request to re-register the responder for thenext state change.References• Client–Server (see page 182) can be used to implement the IPCneeded to use this pattern with responders in different processes fromthe coordinator.• Escalate Errors (see page 32) is used within this pattern to move theerror handling from the coordinator to the controller where it can behandled more appropriately.• Proxy [Gamma et al., 1994] is used to hide the need for IPC communication.• Mediator [Gamma et al., 1994] solves a related problem to thispattern. The Mediator object described by that pattern is tightlycoupled with the colleagues with which it interacts, with the Mediatortypically creating all the colleagues. A Mediator generally performsunique actions on each of the colleagues, understanding that eachcolleague has a different role in a system.
The Coordinator pattern isdifferent from the Mediator pattern in that it moves the intelligenceand understanding of what to do for particular changes out to theresponders, removing almost all understanding from the coordinator.The coordinator in this pattern could be seen as an unintelligentMediator. An additional difference from the Mediator pattern is theseparation of controller from responder; in the Mediator pattern thecolleagues are both controllers and responders.7SecurityThis chapter outlines a number of patterns that can be used to secure yourcomponents from attack by software agents, known as malware.
Beforewe get into the details of the patterns themselves, we cover some of thebasics of the platform security provided by Symbian OS v9 so that theyare put into context. For a fuller description please see [Shackman, 2006]and [Heath, 2006].Security on Symbian OS follows a strategy of defense in depth1in which there exist multiple security privileges which each provide theright to perform a specified group of actions or access specific informationor resources. These security privileges are known as capabilities2 onSymbian OS and are assigned to executables during development.
Duringdevelopment, you may also assign to an executable a secure identifier(SID) or a vendor identifier (VID).3 The capabilities, SID, and VID areknown collectively as security credentials.In addition to this, Symbian OS platform security defines the followingconcepts:• The smallest zone of trust is a process – Symbian OS has beendesigned to control what each process can do. This reflects the fact thata process is the unit of memory protection and this hardware-assistedprotection provides the foundation of platform security.• Capabilities determine privileges at run time – whilst both DLLs andEXEs can be assigned security credentials during development, onlythe security credentials of an EXE translate directly into run-timecredentials.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
