Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 19
Текст из файла (страница 19)
The software running on a mobile device has a direct influenceupon the power consumed by the CPU. This is because the CPU usespower for each CPU cycle executed. The fewer CPU cycles neededto execute a piece of functionality, the less power the device uses. Thisapplies to all types of software, from device drivers for hardware resourcesto user-level applications. All Symbian developers should understand andapply these patterns throughout their software design and development.Consider an indicator on a mobile phone that shows whether aBluetooth communication link is active by displaying one icon whenit is in use and another icon when it is not.
One approach to keepingthis icon updated would be to have a thread running that periodicallyrequests information from the Bluetooth subsystem and updates the iconaccordingly. This periodic approach is generally known as polling.The difficulty with polling is that, while it is easy to write, every time themonitoring thread wakes up and requests information from the Bluetoothsubsystem, it causes the CPU to be woken up and made to do work,whether the icon needs to be updated or not.
This is clearly wasteful of88EVENT-DRIVEN PROGRAMMINGCPU time. Worse, because this thread would be running all the time,1the cumulative effect of this thread running could be a marked reductionin battery life.Arguably, this could be ameliorated by lengthening the period betweenupdates, but this would then worsen the other drawback of polling – thatit can produce unresponsive software.
For instance, if the Bluetoothsubsystem became inactive just after the icon had been redrawn, it wouldtake at least an entire polling period before the display is updated.The alternative to polling is ‘event-driven programming’, which allowsthe CPU and other hardware components to be used in the most powerefficient and responsive way.Fundamentally, there are four concepts in event-driven programming:• An event is some significant occurrence. In the Bluetooth iconexample, a link becoming active or being disconnected is an event.Examples of events in the user interface domain are keystrokes, screenclicks and screen redraws.• An event signal is an indication that an event has occurred. Events andthe resulting event signals also occur in middleware and low-levelsoftware such as when hardware data buffers have been filled withincoming data, an email has been sent or a USB cable has beenattached.
Event signals also drive activity at the hardware level wherethey are more commonly known as interrupts. For the Bluetooth iconexample, the event signal is the notification sent by the Bluetoothsubsystem about the new state of the Bluetooth link.The amount of information carried in an event signal can vary fromnothing more than an indication that a particular event has happened(a warm event signal) to a comprehensive description of the event (ahot event signal). In the former case, the event consumer may thenneed to make an additional effort to discover details about the eventthat occurred. In the latter case, the event signal can be consideredself-contained.• An event consumer is an entity which requests notification of aparticular event or type of event from an event generator.
For theBluetooth icon example, the event consumer is the UI componentthat owns the Bluetooth icon.• An event generator is an entity which produces events and sendsevent signals to registered event consumers. For the Bluetooth iconexample, the event generator is the Bluetooth subsystem. Some eventgenerators produce events as a result of stimuli in the environment,such as a keyboard driver producing keystroke events, while others generate events prompted by the action of the event consumer1Potentially even when the user is not operating the phone.EVENT-DRIVEN PROGRAMMING89requesting a notification. For instance, a communications stack sendsan event indicating the establishment of a connection to the clientthat requested the connection.It is worth noting that many components operating in an event-drivenenvironment are both event consumers and event generators.
Such eventconsumer–generators may be linked in long chains or networks to achievesome overall task, known as an event-driven chain.Figure 4.1 illustrates the following event-driven chain:• A piece of communications hardware (an event generator) generatesan interrupt when data is received (an event) that is picked up by adevice driver (an event consumer).• A communications stack (an event consumer) is informed by a devicedriver (an event generator) that some data has been received (anevent).• The communications stack (an event generator) then determines if thenew data is bound for one of its clients (an event consumer) and, ifso, sends it a notification (an event signal).• The messaging application client (an event generator) determines thatthe data is a new message and informs its UI (an event consumer) thata new message has arrived (the event).Note how the CPU goes into low power mode between processingthe various event signals.
Of course in a full system there could be otheractivities that keep the CPU from going into a low power mode for atleast some of the time between the steps in this sequence.In addition to being more power efficient and responsive, event-drivenprogramming helps you to decouple your components. This is becauseyou are able to distribute responsibility for generating or consumingevents as needed to the appropriate components because an event canbe almost anything and exist almost anywhere.
In addition an event generator doesn’t need to know about the consequences of the event signalnor does an event consumer need to worry about where the event signalhas come from. In the Bluetooth icon example, the Bluetooth subsystemdoesn’t need to worry about any dependencies on the higher UI layer. Itjust provides the event signal and carries on regardless of what is donewith it by the Bluetooth icon component.Symbian OS has a number of classes and common idioms that supportevent-driven programming which can be adopted by developers into thedesign of their own components.One of the most common event-driven programming tools in SymbianOS is the use of active objects, commonly known as AOs.
They aredescribed by the Active Objects pattern (see page 133).90EVENT-DRIVEN PROGRAMMING«Event Generator»Device Driver«Event Consumer & Generator»Communications Stack«Event Consumer & Generator»Messaging EngineHardware«Event Consumer»Messaging UIApplicationHardware Interrupt (Event Signal)Process Interrupt()... CPU goes into low power mode ...Hardware Interrupt (Event Signal)Process Interrupt()FIFO Buffer Full Event Signal()Process Buffer Full Event()In this example, ittakes two hardwareinterrupts to fill theFIFO buffer held bythe device driver.... CPU goes into low power mode ...Hardware Interrupt (Event Signal)Process Interrupt()...
CPU goes into low power mode ...Hardware Interrupt (Event Signal)Process Interrupt()FIFO Buffer Full Event Signal()Process Buffer Full Event()... CPU goes into low power mode ...Hardware Interrupt (Event Signal)Process Interrupt()... CPU goes into low power mode ...Hardware Interrupt()Process Interrupt()FIFO Buffer Full Event Signal()Process Buffer Full Event()In this example, it takesthree FIFO buffers of data tofulfil the messagingapplication’ s data readrequest on thecommunications stack.Data Received Event Signal()Process Data Received Event()New Message Event Signal()Figure 4.1 An event-driven chainEVENT-DRIVEN PROGRAMMING91It is worth considering that, in event-driven programming terms, an AOis an event consumer; the CActive class contains a TRequestStatusmember variable which, when an AO is activated, is passed to someasynchronous function, putting the AO into the role of event consumer.This asynchronous function then acts as the event generator.
The eventsignal is the completion of this TRequestStatus, which triggers theAO’s RunL() function.Aside from AOs, there are a number of other common event-drivenprogramming idioms used in Symbian OS. These are represented as thefollowing patterns:• Event Mixin (see page 93)• Request Completion (see page 104)• Publish and Subscribe (see page 114)The following list summarizes the main characteristics of these patternsto help you to understand when to use each of them.Event Mixin:• Both the event generator and the event consumer must be in the samethread.• There is one event generator and one event consumer per eventsignal.2• Both warm and hot event signals are supported.• Reliable but not secure event signals are supported.3• The event generator knows whether an event consumer is listening.Request Completion:• The event generator and the event consumer need not be in the samethread.• There is one event generator and one event consumer per event signal.• Both warm and hot event signals are supported.• Reliable but not secure event signals are supported.• The event generator knows whether an event consumer is listening.2Event Mixin (see page 93) is, by default, one-to-one but can be extended to supportmultiple event generators and event consumers.3 When each event consumer can be guaranteed to receive each and every event signal,it is known as Reliable event signals.92EVENT-DRIVEN PROGRAMMINGPublish and Subscribe:• The event generator and the event consumer need not be in the samethread.• There can be zero to many event generators and zero to many eventconsumers per event signal.• Secure but not reliable event signals are supported.• The event generator does not know whether an event consumer islistening.EVENT MIXIN93Event MixinIntentSave power and decouple your components by defining an interfacethrough which event signals are sent to another component in the samethread.AKAObserver [Gamma et al., 1994]ProblemContextYou wish to propagate event signals synchronously between an eventgenerator and an event consumer operating within the same thread.Summary• You wish to reduce the power usage of your component.• You want to promote encapsulation of and loose coupling betweenyour event generators and event consumers so that testing and maintaining your component is made easier.DescriptionAn event generator wishes to propagate event signals to an event consumer that is running in the same thread.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
