The Observer pattern is also known as the Publish-Subscribe pattern. As its a.k.a. implies, it's just like a magazine subscription. When you order a subscription from a magazine publisher, you provide the publisher your name and mailing address so the new issue can find its own way to your hand. The publisher makes sure the right magazine will be delivered to the right address. You will never (supposedly) get what you have not subscribed to. This is exactly how the Observer pattern works. An observer registers (subscribes) itself for particular notifications (magazines) with a notifier (publisher). The observer only gets what it has subscribed to when it's available from the notifier. Their static relationships are illustrated in Figure 12-1.

Figure 12-1. A class diagram of the Observer pattern

The Observer pattern is a publish-subscribe model. Observers subscribe to notifications from the Subject. ConcreteObservers implement an abstract Observer and override its update method. Once an instance of Subject needs to notify Observers for any new changes, the Subject will send an update message to notify any registered Observers stored in an internal list. Inside an actual implementation of the update method of a ConcreteObserver, the internal state of the Subject can be retrieved and processed later.

The whole idea of the publish-subscribe mechanism is pretty straightforward and quite easy to understand. The Subject provides methods to register and unregister any object that implements the Observer protocol and is interested in handling the update message call. When there is a change in an instance of Subject, it will send a notify message to itself. The notify method contains an algorithm that defines how to broadcast update messages to all registered observers. A common notify-update sequence at runtime is illustrated as a sequence diagram in Figure 12-2.

Figure 12-2. A sequence diagram shows the interaction between aConcreteSubject and other concrete observers that observe updates from the aConcreteSubject object.

aConcreteObserver first modifies the state of aConcreteSubject. Since there is a change in its internal state, aConcreteSubject sends itself a notify message so it broadcasts update messages to a set of aConcreteObservers. aConcreteObserver and anotherConcreteObserver receive the message and send a getState message to aConcreteSubject to retrieve its internal state for further processing.

One of the most obvious benefits of using the Observer pattern is that it can extend the behavior of the Subject with N number of Observers that have specific implementation to process the information stored in the Subject. It's also a very important pattern for decoupling among different objects. The Cocoa Touch framework has provided developers some classes to use the pattern without writing their own.

You'd naturally think about using the pattern when

In earlier chapters, we discussed how the Model-View-Controller pattern (MVC) is a compound of different types of design patterns. Observer is one of them. A view will be associated with a controller for some particular events to occur that would affect the presentation of an application. For example, when the user clicks a "sort" button on the view, then it's passed to the controller to tell the model to sort its data in the back end. When the model successfully performs the operation on the data, it will notify all the associated controllers to update their views with the new data.

By using the Observer pattern in a MVC pattern, each component can be reused and extended independently without much interference with others in the relationships. The achieved high reusability and extensibility could not be achieved with all their logic put together in one class. So extra views can be added to a controller without modifying existing design and code. Likewise, different controllers can use the same model without changing other controllers that are using it. Especially for the model, multiple objects (either local or remote) can modify its internal data. So the model will broadcast specific changes to all observing controllers, and they will, in turn, tell their views to update the presentation with new information from the model. We will discuss more about this update mechanism in later sections.

The Cocoa Touch framework has adapted the Observer pattern with two technologies, Notifications and Key-Value Observing. Despite being two different Cocoa technologies, both of them implement the Observer pattern. We are going to discuss each of their characteristics and the differences between them.

NSNotification *notification = [NSNotification notificationWithName:@"data changes"
                                                             object:self];
NSNotificationCenter * notificationCenter = [NSNotificationCenter defaultCenter];
[notificationCenter postNotification:notification];

[notificationCenter addObserver:self
                       selector:@selector(update:)
                           name:@"data changes"
                         object:subject];

The canvas part of the TouchPainter app that allows the user to scribble is the heart and soul of the app. We briefly cover the components involved in the previous chapters. From a bird's eye view, it is basically a Model-View-Controller structure: Scribble as Model, CanvasView as View, and CanvasViewController as Controller. The CanvasView forwards touches to the CanvasViewController through a responder chain (Chain of Responsibility pattern, Chapter 17). Then the CanvasViewController processes the information of the touches and instructs Scribble to update its internal structure with the information of the new touches. Once the Scribble has updated its internal state (Mark composite; please see the Composite pattern in Chapter 13 for more details), then it will notify any observer that is registered for an update notification. In this case, the CanvasViewController is the only observer that would like to receive any updates from the Scribble. Finally the CanvasViewController will notify the CanvasView to update its presentation. Their relationships are illustrated in a diagram in Figure 12-3.

Figure 12-3. An action-flow diagram shows how CanvasView, CanvasViewController, and Scribble interact with each other.

We will implement the solution with the Key-Value Observing mechanism, or KVO, with NSKeyValueObserving protocol. Luckily, NSObject has implemented that for us so we don't need to create everything from scratch. A class diagram that shows a possible structure is illustrated in Figure 12-4.

Figure 12-4. A class diagram shows a static relationship between Scribble and CanvasViewController through the Key-Value Observing mechanism implemented by NSObject.

The class diagram looks a little scary, doesn't it? For the sake of brevity, other unrelated methods are omitted in the diagram. Because we are using KVO to implement the pattern and a lot of bells and whistles are hidden from view, the class diagram in Figure 12-4 doesn't quite reconcile with the one shown in Figure 12-1. But there are two key methods in NSObject shown in the figure that will ring a bell. addObserver:forKeyPath: options:context: allows an object to be added as an observer to a receiver. The observer needs to override observeValueForKeyPath:ofObject:change:context: to receive any callback from changes in the subject and process any returned value. In the previous sections, we have mentioned that the KVO update mechanism is usually automatic whenever a key-matching property is updated through its accessor method (i.e., set<key> method). If we want to manually trigger the KVO update broadcast, then we need to use willChangeValueForKey: and didChangeValueForKey: to wrap the changes before and after they occur.

Every time a different instance of Scribble is assigned to an instance of CanvasViewController, it will add itself as an observer to the instance of Scribble with the addObserver:forKeyPath:options:context: method. If there are changes to the internal state of the instance of Scribble (adding / removing components in its Mark composite object), we need to manually trigger the universal update by a pair of wrapping calls of willChangeValueForKey:@"mark" and didChangeValueForKey:@"mark". The KVO implementation in NSObject will forward a message of observeValueForKeyPath:ofObject:change:context: to the observer CanvasViewController. In the callback method, it will update its canvasView_ with a new instance of Mark from the message and ask it to redraw itself. The class declaration of Scribble is shown in Listing 12-1.

#import "Mark.h"

@interface Scribble : NSObject
{
  @private
  id <Mark> parentMark_;
}

// methods for Mark management
- (void) addMark:(id <Mark>)aMark shouldAddToPreviousMark:(BOOL)shouldAddToPreviousMark;
- (void) removeMark:(id <Mark>)aMark;

@end

Scribble keeps an instance of Mark as its internal state so it won't expose to other objects. Clients can send Scribble a message of addMark:(id <Mark>)aMark shouldAddToPreviousMark:(BOOL)shouldAddToPreviousMark to insert any Mark instance to its internal composite. The BOOL parameter shouldAddToPreviousMark tells the method whether the input Mark object should be attached to the previous one as part of its aggregation (for example, a Vertex in a Stroke). removeMark:(id <Mark>)aMark allows a removal of aMark from the parent Mark.

A message of either addMark: or removeMark: for an instance of Scribble will trigger an update broadcast to its observers. Listing 12-2 shows how they are implemented.

#import "Scribble.h"
#import "Stroke.h"

// A private category for Scribble
// that contains a mark property available
// only to its objects
@interface Scribble ()

@property (nonatomic, retain) id <Mark> mark;

@end


@implementation Scribble

@synthesize mark=parentMark_;

- (id) init

{
  if (self = [super init])
  {
    // the parent should be a composite
    // object (i.e. Stroke)
    parentMark_ = [[Stroke alloc] init];
  }

  return self;
}

#pragma mark -
#pragma mark Methods for Mark management

- (void) addMark:(id <Mark>)aMark shouldAddToPreviousMark:(BOOL)shouldAddToPreviousMark
{
  // manual KVO invocation
  [self willChangeValueForKey:@"mark"];

  // if the flag is set to YES
  // then add this aMark to the
  // *PREVIOUS* Mark as part of an
  // aggregate.
  // Based on our design, it's supposed
  // to be the last child of the main
  // parent
  if (shouldAddToPreviousMark)
  {
    [[parentMark_ lastChild] addMark:aMark];
  }
  // otherwise attach it to the parent
  else
  {
    [parentMark_ addMark:aMark];
  }

  // manual KVO invocation
  [self didChangeValueForKey:@"mark"];
}

- (void) removeMark:(id <Mark>)aMark
{
  // do nothing if aMark is the parent
  if (aMark == parentMark_) return;

  // manual KVO invocation
  [self willChangeValueForKey:@"mark"];

  [parentMark_ removeMark:aMark];

  // manual KVO invocation
  [self didChangeValueForKey:@"mark"];
}


- (void) dealloc
{

[parentMark_ release];
  [super dealloc];
}

@end

@"mark" is the only key in the KVO in Scribble. Normally speaking, if we want to modify its internal mark, then we can use one of its accessor methods (e.g., setMark:). In that case, we don't need to do anything extra to broadcast an update once a modification is done as it's being handled by the default KVO mechanism defined in NSObject. We definitely need manual update because Scribble allows part-whole modifications to its mark but not just a complete replacement of it through its set method. In fact, we want both automatic and manual updates. So we will keep the original mechanism offered by NSObject and add a couple lines of code around where actual modifications to mark occur in the methods. In the addMark: method, there is an if block that tells whether the incoming aMark needs to be added to a parent or the last Mark. In either case, there will be a change to the internal mark, so we wrap the whole block with two statements: [self willChangeValueForKey:@"mark"] and [self didChangeValueForKey:@"mark"]. The first statement tells NSObject to keep the old value of the mark while the second one keeps the new one. Either one or both of the values will be passed to observers, depending on what they want to get from an update.

How should an observer handle an update? It's not the business of Scribble anymore once it hands off a whole bunch of update messages. Let's see how CanvasViewController can handle an update message to update its canvasView_ with code snippets shown in Listings 12-3 and 12-4.

#import <UIKit/UIKit.h>
#import "Scribble.h"
#import "CanvasView.h"
#import "CanvasViewGenerator.h"

@interface CanvasViewController : UIViewController
{
  @private
  Scribble *scribble_;
  CanvasView *canvasView_;

  CGPoint startPoint_;
  UIColor *strokeColor_;
  CGFloat strokeSize_;
}

@property (nonatomic, retain) CanvasView *canvasView;
@property (nonatomic, retain) Scribble *scribble;
@property (nonatomic, retain) UIColor *strokeColor;
@property (nonatomic, assign) CGFloat strokeSize;
@end

We are reusing pretty much the same CanvasViewController that appears in other chapters. Scribble is served as a model (as in Model-View-Controller) that helps store the user's stroke and dot information. A member instance of Scribble sits squarely inside a CanvasViewController object just for the purpose.

CanvasViewController also manages an instance of CanvasView as a member variable canvasView_. It uses an instance of Mark to do that actual drawing on the screen.

The implementation code for the CanvasViewController is quite long, so I will break it into multiple parts to discuss. We are going to get the setup part of the controller, as in Listing 12-4.

#import "CanvasViewController.h"
#import "Dot.h"
#import "Stroke.h"

@implementation CanvasViewController

@synthesize canvasView=canvasView_;
@synthesize scribble=scribble_;
@synthesize strokeColor=strokeColor_;
@synthesize strokeSize=strokeSize_;


// hook up everything with a new Scribble instance
- (void) setScribble:(Scribble *)aScribble
{
  if (scribble_ != aScribble)
  {
    [scribble_ autorelease];
    scribble_ = [aScribble retain];

    // add itself to the scribble as
    // an observer for any changes to
    // its internal state - mark
    [scribble_ addObserver:self
                forKeyPath:@"mark"
                   options:NSKeyValueObservingOptionInitial |
                           NSKeyValueObservingOptionNew
                   context:nil];
  }
}


// Implement viewDidLoad to do additional setup after loading the view,
// typically from a nib.
- (void)viewDidLoad
{
  [super viewDidLoad];

  // ...
  // Setup a default canvas view
  // but we snip that part for brevity
  // ...

  // initialize a Scribble model
  Scribble *scribble = [[[Scribble alloc] init] autorelease];

[self setScribble:scribble];

  // other setups...
}

- (void)dealloc
{
  [canvasView_ release];
  [scribble_ release];
  [super dealloc];
}

Because CanvasViewController's scribble property is synthesized automatically, we normally don't need to provide any custom accessor methods for it. But here is the thing: CanvasViewController is depending on any update notifications sent from scribble_ in order to further instruct how its canvasView_ (re)draws any mark in scribble_. It needs to add itself to its private member variable scribble_ as an observer with a message call:

[scribble_ addObserver:self
            forKeyPath:@"mark"
               options:NSKeyValueObservingOptionInitial |
                       NSKeyValueObservingOptionNew
               context:nil];

The NSKeyValueObservingOptionInitial option tells scribble_ to notify CanvasViewController right after this message call to provide the initial value for its mark property. That option is important because CanvasViewController also needs to be notified when a Scribble object is being initialized in its init* method and the mark property is being set for the first time. NSKeyValueObservingOptionNew instructs scribble_ to notifiy CanvasViewController every time when the mark property of scribble_ is set with a new value. The context parameter provides an optional object as a parameter for a notification. Ok, let's get back to the message call itself. The question is, where should we put it in? If it's only in the viewDidLoad method, then when a client assigns a different Scribble instance to the controller, the observing link will be broken. So the best place to establish a link between them is in a set accessor method for scribble_. It serves as a gateway to prevent any possibility of breaking the observing link. Also, after a different Scribble reference is assigned to the CanvasViewController, the accessor method will send a message to canvasView_ to redraw itself with the mark in a new Scribble. Details on how canvasView_ draws a complete Mark composite on the screen are discussed in Chapter 15.

So instead of putting the part where we set up an observing link between CanvasViewController and its scribble_ in the viewDidLoad method, we create the first-ever instance of Scribble there every time the controller is loaded and assign it with the accessor method.

CanvasViewController and its scribble_ are now hooked up, and we are ready to see some actions on updating scribble_ with touches on the canvasView_. We put some touch event handlers in CanvasViewController, as in Listing 12-5.

#pragma mark -
#pragma mark Touch Event Handlers

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
  startPoint_ = [[touches anyObject] locationInView:canvasView_];
}

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
  CGPoint lastPoint = [[touches anyObject] previousLocationInView:canvasView_];

  // add a new stroke to scribble
  // if this is indeed a drag from
  // a finger
  if (CGPointEqualToPoint(lastPoint, startPoint_))
  {
    id <Mark> newStroke = [[[Stroke alloc] init] autorelease];
    [newStroke setColor:strokeColor_];
    [newStroke setSize:strokeSize_];
    [scribble_ addMark:newStroke shouldAddToPreviousMark:NO];
  }

  // add the current touch as another vertex to the
  // temp stroke
  CGPoint thisPoint = [[touches anyObject] locationInView:canvasView_];
  Vertex *vertex = [[[Vertex alloc]
                     initWithLocation:thisPoint]
                     autorelease];

  [scribble_ addMark:vertex shouldAddToPreviousMark:YES];
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
  CGPoint lastPoint = [[touches anyObject] previousLocationInView:canvasView_];
  CGPoint thisPoint = [[touches anyObject] locationInView:canvasView_];

  // if the touch never moves (stays at the same spot until lifed now)
  // just add a dot to an existing stroke composite
  // otherwise add it to the temp stroke as the last vertex
  if (CGPointEqualToPoint(lastPoint, thisPoint))
  {
    Dot *singleDot = [[[Dot alloc]
                       initWithLocation:thisPoint]
                       autorelease];
    [singleDot setColor:strokeColor_];
    [singleDot setSize:strokeSize_];

    [scribble_ addMark:singleDot shouldAddToPreviousMark:NO];
  }

  // reset the start point here
  startPoint_ = CGPointZero;

  // if this is the last point of stroke

// don't bother to draw it as the user
  // won't tell the difference
}

- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
  // we don't actually need to
  // reset the start point here
  // but just in case
  startPoint_ = CGPointZero;
}

Please see Chapters 2, 13, and 15 for detailed discussions on the requirements for the drawing part of the app.

We have a whole chunk of code for handling touch events. Our goal there is to create two different drawing scenarios. It'll be a single dot if the finger lifts off at the same spot where it first touched or a stroke (line) if it is a drag with the finger. The majority of the algorithm that deals with those conditions is in the touchesMoved: and touchesEnded: methods. In the touchesMoved: method, it will create a new instance of Stroke if it is the second point of the drag and assign it to the scribble_ with a message call, [scribble_ addMark:vertex shouldAddToPreviousMark:NO]. Further touches along the drag will be added as instances of Vertex to a previously added Mark (as a form of Stroke) with the same type of message call to scribble_. But this time the shouldAddToPreviousMark parameter is set to YES.

If it's a single touch from a finger, then touchesEnded: will create a new instance of Dot as singleDot and ask scribble_ to add it to its internal structure with shouldAddToPreviousMark set to NO.

scribble_ notifies its observers (maintained by NSObject) in every addMark: message call. We know that the CanvasViewController was hooked up with scribble_ with the addObserver: message a moment ago. But it also needs to define a callback method so when an update notification comes in from scribble_, it will do something meaningful. Part of the KVO deal requires observers to override at least one observing method. For this example, we need CanvasViewController to listen to an observeValueForKeyPath: message, as in Listing 12-6.

#pragma mark -
#pragma mark Scribble observer method

- (void) observeValueForKeyPath:(NSString *)keyPath
                       ofObject:(id)object
                         change:(NSDictionary *)change
                        context:(void *)context
{
  if ([object isKindOfClass:[Scribble class]] &&
      [keyPath isEqualToString:@"mark"])
  {
    id <Mark> mark = [change objectForKey:NSKeyValueChangeNewKey];
    [canvasView_ setMark:mark];

[canvasView_ setNeedsDisplay];
  }
}

It first double-checks to make sure an update message is from an instance of Scribble and for its @"mark" state. If so, it will retrieve a new Mark from a change dictionary by sending it [change objectForKey:NSKeyValueChangeNewKey]. The value that is associated with NSKeyValueChangeNewKey in the dictionary will be the new value from the mark property in scribble_. After that, it tells canvasView_ to draw itself with the new Mark.

We've covered some code to show a possible way to implement the Observer pattern for the TouchPainter app. At this point, you may wonder why we needed to let the CanvasViewController update the Scribble with touch information and at the same time, expect a notification from the Scribble, and then tell the CanvasView to update itself. It seems to us there are a few extra steps for something that can be done in an easier way. If you think so, then you should go back and look at the Scribble code again. In Scribble, there are two methods that allow modifications to its internal Mark composite reference. One is to add a new Mark to a parent Mark and the other one is to remove a Mark in the parent. We already knew that the CanvasViewController would use the addMark: method to add any Dot and Stroke to the Scribble. But how about removing a Mark from it then? Who will use that one? We didn't put any code in CanvasViewController to remove a Mark in scribble_. That operation would most probably be invoked by another entity—for example, a command object (see the Command pattern, Chapter 20). An undo/redo operation can modify scribble_ without CanvasViewController's knowledge. In that case, CanvasViewController needs to know what's going on with its scribble_ behind its back. Another type of aspect that could also modify scribble_ outside the knowledge of CanvasViewController is when the model (again as in Model-View-Controller) needs to be shared with other objects just like what databases do. A database can be read and modified by objects sitting in different processes or even across the network. Changes made by one object could be vital if they are important to other objects that are supposed to be in sync but are not.

If we implemented the same thing with NSNotification and NSNotificationCenter that we have discussed in one of the previous sections instead of using KVO, then here is what's going to happen:

Besides using those two approaches provided by the framework, some of you may be tempted to homebrew your own Observer infrastructure from the ground up.

In this chapter, we have covered the background information on the Observer pattern and its uses. We have also explored how we can implement it in the TouchPainter app for its Model-View-Controller architecture as a mechanism to reflect stroke changes on the screen as the user draws with a finger.

One can also take advantage of the canned implementation of the pattern with Key-Value Observing (KVO) as well as NSNotification and NSNotificationCenter objects in the Cocoa Touch framework without implementing the whole solution from scratch.

In the next part, we are going to see some design patterns that are useful for forming structures for abstract collections and other patterns that are directly related to their behaviors.