When the user taps the palette button on the CanvasViewController, the view will be replaced by the PaletteViewController's view. Likewise, a hit on the button that opens a thumbnail view on the CanvasViewController will bring up the view of the ThumbnailViewController. When the user taps the Done button on the navigation bar to finish his or her business, it will take the user back to the view of the CanvasViewController. Figure 2-4 illustrates their possible interactions.

Figure 2-4. A diagram shows dependencies among CanvasViewController, PaletteViewController, and ThumbnailViewController in a typical iOS application design.

When you look at the diagram Figure 2-4 and you think, "There is nothing wrong with it. I have been doing it and it works all the time," then you may want to know why it may not be a good design in most applications. In a typical iOS application, view transitions like the one shown in Figure 2-4 don't look very complex, even though there are certain dependencies among those controllers. The application can't scale well if views and their controllers are dependent on each other. Also, if we modify the way the views change, code changes in each of them are almost unavoidable. In fact, the dependencies are not just among the view controllers but the buttons as well. Those buttons are indirectly related to particular view controllers. If the app grows larger and more complex, the dependencies could be out of control, and a bunch of hard-to-understand view transition logics will follow. We need a mechanism to reduce interactions between different view controllers and buttons, so it will make the whole structure less coupled but more reusable and extensible. A kind of coordinating controller just like a view controller should help, but its role is not to coordinate a view and a model; it needs to coordinate different view controllers for proper view transitions.

The Mediator pattern (Chapter 11) suggests an object that encapsulates the logic of how a set of objects interacts. A mediator promotes loose coupling among different objects by keeping them from referring to each other explicitly. So their interactions can be varied in a centralized place, and their dependencies can be reduced. A structure for their new interaction patterns is illustrated in Figure 2-5.

Figure 2-5. A diagram shows fewer dependencies among the view controllers and their buttons with the introduction of CoordinatingController as a mediator.

With the introduction of our new member, CoordinatingController, to our architecture, any further changes to the architecture later will be a lot easier. The CoordinatingController encapsulates logic that coordinates the traffic of view-changing requests fired off from different controllers and buttons alike. Interactions are not just limited to view transitions, but they could be information forwarding and operation invocation. Should those interactions need to be modified later, the only place that we need to go to is in CoordinatingController, not any other view controllers. With this structure, the CoordinatingController knows everyone on the interaction map. A button tap will trigger a call to CoordinatingController to request a view transition. Based on the information stored in the button, such as a tag, CoordinatingController can tell what view the button desires to open. If we want to reuse any of those view controllers, we don't need to worry about how they should be connected in the first place.

Now the CanvasViewController, PaletteViewController, ThumbnailViewController, and their buttons perform just like different musicians in an orchestra. They don't depend on each other to perform a piece but just follow what a conductor tells them about when and what to do. Can you imagine an orchestra without a conductor?

Before we think of any possible data structure that can be used to hold the touch data, let's take a look at how we should define a stroke.

If the user first touches the screen and then moves his or her finger, it creates a stroke. However, if the finger doesn't move but finishes the touch at the same location where it started, that should be considered a dot. These are illustrated in Figure 2-6.

Figure 2-6. A dot created by a single touch vs. a line by dragging it on the screen

It's intuitive to think of a dot as just a single location, while a stroke has multiple locations along the path. A stroke is an entity by itself that contains a series of touch locations. The challenge here is how to manage both types of entities as if they were a single type. Can we think of a stroke that has multiple dots? If a stroke has an array to hold all the dots, then can we just use a stroke structure to represent both the dot and stroke? But then for the case of a dot, we will waste memory for having an array that is just a dot in a stroke. The best case is we can have a design pattern to let us have our cake and eat it too.

Before we examine how we can make use of a data structure to represent strokes and dots, let's think about how we can draw a point and line on the screen. The Cocoa Touch framework has a framework called Quartz 2D, which provides an API to draw 2D glyphs on a UIView, including lines and different polygons.

To draw anything on a UIView, we need to get ahold of a drawing context provided by the runtime. For instance, if we want to draw a dot, then we pass in the drawing context and the size of the dot as a CGRect that contains the width and height as well as the location information to a Quartz 2D function, CGContextFillEllipseInRect(). For drawing a line, we need to first let the context move to the first point with a function call, CGContextMoveToPoint(). After the first point is set to the context, we will add the rest of the points that are supposed to be part of a line to a series of function calls to CGContextAddLineToPoint(). When the last point is added, we will close the line by calling CGContextStrokePath(). Then the points are connected as a line and drawn on a UIView. A visual representation of the process is illustrated in Figure 2-7.

Figure 2-7. A visual representation of drawing a dot and a stroke with Quartz 2D

We can, of course, use whatever primitive data structures we know of for storing strokes, dots, and whatnot. However, if we use, let's say, a multi-dimensional array to store everything, we need a lot of type-checking to use and parse, plus it would take a lot of debugging to make the structure robust and consistent. One object-oriented way of thinking about a kind of structure that can keep independent dots as well as strokes that have other dots (vertices) as children is a tree. A representation of a tree allows complex object relationships like our strokes and dots scenario to be organized and localized in one place. A design pattern that solves this kind of structural problem is called the Composite pattern (Chapter 13).

With the Composite pattern, we can compose our strokes and dots into a tree structure so that we can treat each of the nodes uniformly. A visualized structure of strokes, dots, and vertices is illustrated in Figure 2-8.

Figure 2-8. A diagram showing a composite structure for both Dot and Stroke.

A dot is a leaf node, which is fine on its own. A stroke is a composite that can contain other dots as vertices; at the same time, it can also contain other composites as strokes. They are quite different entities. If we want each of them to represent the same type, then we need to generalize them into a common interface. Therefore, no matter what concrete type each component actually is, the generic type is still the same. With that scheme, we can treat each of them uniformly when we use them.

If the component is just a single dot, then it will be rendered as a filled circle to represent a "dot" onscreen. But if it's a series of dots (vertices) with which they are supposed to be connected together as a group of entities, then they will be plotted as a connected line (stroke). That is the distinction between them.

Either a stroke or a dot is, in fact, a kind of "mark" on a medium, which is the screen in our caseso we add a Mark as a parent type for Vertex, Dot, and Stroke. Their relationships are illustrated as a class diagram in Figure 2-9.

Figure 2-9. A class diagram for the Mark model as a composite structure with Dot and Stroke as concrete classes

The parent type Mark is a protocol. A protocol is an Objective-C feature that defines a contract of behavior without implementation. Concrete classes implement the interface a Mark protocol declares. Vertex, Dot, and Stroke are all concrete classes of Mark. Both Vertex and Dot need location information, but Dot also needs color and size as extra attributes, so Dot inherits Vertex as its subclass.

Mark defines attributes as well as methods for all the concrete classes. So any of them can be treated uniformly when the clients operate each of them based on the interface. There are methods for a Mark object to add other Mark objects as children and behave like a composite. Stroke implements the method for adding other Mark objects as its children. There are some other operations related to child management defined in the Mark protocol, such as removing children, returning a particular child based on an index, and returning the number of children as well as the last child in a children list.

Now we have a data structure set up that allows the app to manage points created by the user's touches in a logical way. The location information of touches plays a vital role when we present it onscreen. But the composite structure that we have examined in the last section doesn't have an algorithm to draw itself on the screen.

We know the only way to put any custom drawing on a UIView is to override its drawRect: instance method. That method will be called upon when an update on the view is requested. For example, we can send a message of setNeedsDisplay to a UIView, and then it will invoke the drawRect: method that defines any custom drawing code. We can then use a current graphics context as CGContextRef to draw whatever we want within the same method call. Let's look at how we can use the mechanism to draw a composite structure.

We can add a drawing operation like drawWithContext:(CGContextRef)context to the Mark protocol so every node can draw itself according to its specific purpose. We can pass a graphics context obtained in the drawRect: method to the drawWithContext: method, so a Mark object can draw in it. A possible implementation of the drawWithContext: method for Dot would go like the one in Listing 2-1.

- (void) drawWithContext:(CGContextRef)context
{
  CGFloat x = self.location.x;
  CGFloat y = self.location.y;
  CGFloat frameSize = self.size;
  CGRect frame = CGRectMake(x - frameSize / 2.0,
                            y - frameSize / 2.0,
                            frameSize,
                            frameSize);

  CGContextSetFillColorWithColor (context,[self.color CGColor]);
  CGContextFillEllipseInRect(context, frame);
}

With an active context, an ellipse (a dot) can be drawn in the context with location, color, and size.

As for a vertex, it provides only a particular location in a stroke. So a Vertex object will add a point to a line only in the context (well, in terms of Quartz 2D, we add a line to a point) with its own location (coordinates), as shown in Listing 2-2.

- (void) drawWithContext:(CGContextRef)context
{
  CGFloat x = self.location.x;
  CGFloat y = self.location.y;

  CGContextAddLineToPoint(context, x, y);
}

For a Stroke object, it needs to move the context to the first point, pass the same drawWithContext: message and graphics context to each child, and set its stroke color. Then it wraps up the whole line drawing operation with the Quartz 2D functions CGContextSetStrokeColorWithColor and CGContextStrokePath, as shown in Listing 2-3.

- (void) drawWithContext:(CGContextRef)context
{
  CGContextMoveToPoint(context, self.location.x, self.location.y);

  for (id <Mark> mark in children_)
  {
    [mark drawWithContext:context];
  }

  CGContextSetLineWidth(context, self.size);
  CGContextSetLineCap(context, kCGLineCapRound);
  CGContextSetStrokeColorWithColor(context,[self.color CGColor]);
  CGContextStrokePath(context);
}

The primary challenge when designing the Mark protocol is to come up with a minimal set of operations to provide open-ended functionality. Performing surgery on the Mark protocol and its subclasses for adding new functionality is both invasive and error-prone. Eventually, the classes get harder to understand, extend, and reuse. So the key is to focus on a sufficient set of primitives for a simple and coherent interface.

Another way to extend the behavior of a composite structure like Mark, we can use another design pattern called the Visitor pattern. The Visitor pattern (Chapter 15) allows us to define any external behavior that can be applied to a composite structure as a "visitor." Visitors "visit" each node in a complex structure to perform particular operations based on the actual type of a visited node.

Based on our problem, we need to separate the original object structure from its own captured state. But before we dive into any details, we need to figure out what we need to archive and unarchive later. In Figure 2-3, we drafted a user interface that allows the user to browse through all thumbnails of previously saved scribbles. Beyond the fact that we need to save Mark objects, we also need to save the corresponding snapshot image of the canvas view during the saving process.

Also, we may decide to archive more elements, such as a canvas and some other attributes that could be applicable to a drawing. Things can evolve when we keep releasing new versions of the app later. For the sake of flexibility, we decide to create another class that manages all these bells and whistles. We call the new class Scribble. A Scribble object encapsulates an instance of Mark composite object as its internal state. Scribble acts like a model in the Model-View-Controller paradigm, as explained in Chapter 1. In this problem domain, we need a Scribble object to be part of the capturing and restoring process with its Mark composite state instead of using Mark directly. Mark is very difficult to use directly, as it provides only primitive operations on a composite structure.

Besides Scribble being the model in the system, we also need a caretaker to save the state of a Scribble object. Let's add another class to play that role and call it ScribbleManager. An actual process of saving a scribble could be very complicated and involve a lot of other objects and such, so we will discuss only saving the internal state of a Scribble object in the rest of the section.

As illustrated in Figure 2-11, CanvasViewController initiates a call to ScribbleManager to save a scribble. ScribbleManager then asks the Scribble object that was passed in to create a memento. The Scribble object in turn creates an instance of ScribbleMemento and saves its internal Mark reference to it. At this stage, ScribbleManager can either keep the returned memento object in the memory or save it in the file system. In this "saving a scribble" process, we want the ScribbleManager to save the memento object in the file systems so the ScribbleMemento object needs to encode itself into a form of data, which is an instance of NSData. The ScribbleManager doesn't know anything about the data but just stores it in the file system with a path that only ScribbleManager has knowledge about. The overall process is like passing a black box of memento objects around, in that only the originating object can wrap and unwrap it. Everything starts from a simple message call of saveScribble:scribble from CanvasViewController to ScribbleManager.

Figure 2-11. A sequence diagram shows how the state of a Scribble can be saved as a ScribbleMemento object.

There are at least two benefits when we use the Memento pattern as our object-archiving solution:

OK, now we know how to save the state of a Scribble object as a memento object. Then how can we resurrect a Scribble object with the same mechanism? The loading part is pretty much like the saving process in reverse gear. A client (in this case, it may not be the original CanvasViewController, though) tells an instance of ScribbleManager what particular Scribble to load, which could be identified by an index. Then the ScribbleManager object reconstructs the path that was used for saving the old ScribbleMemento object and loads it from the file system as an instance of NSData. The ScribbleMemento class decodes the data and regenerates an instance of ScribbleMemento. The ScribbleManager passes the memento to the Scribble class. The Scribble class uses the memento to resurrect the original instance of Scribble with the Mark reference stored in the memento. The resurrected Scribble object that was previously archived will be returned to the client. The cycle is then complete, as illustrated in Figure 2-12.

Figure 2-12. A sequence diagram shows how a Scribble object can be restored with a ScribbleMemento object.

At this point, we probably have a question about the loading process. How does the client know what scribble to open in the first place? So our next step is to set up a view so that the user can browse through all thumbnails of previously saved scribbles. When the user taps, one of them will open it back on the CanvasView through its controller, CanvasViewController, with a corresponding index of the thumbnail to tell ScribbleManager what scribble to open.

We know now how to save scribbles and their thumbnails. How can we browse through all of them so we can open any one of them? Let's flash back to the UI wireframe of a thumbnail view in Figure 2-3; the thumbnail view populates all saved scribbles as individual thumbnails for browsing. When there are a lot of thumbnails fighting each other to display on the view as fast as possible, it makes us think that they could bog down the main thread of the application. It could then slow down the responsiveness for any user actions.

Instead of taking the chance of letting the main thread handle tons of image loading operations one after the other, we should take the better approach of letting each individual thumbnail load its real image in a background thread. That can improve responsiveness while a bunch of thumbnails are busy doing their business independently. But here is a question, though—what would happen to some thumbnails with their own threads waiting in line for the others to finish? When should the user expect to see them? We need some kind of placeholder image for each of them to display while it's waiting for a chance to load the actual image. When the real images are completely loaded, they will show in place of the placeholder images. It makes for a consistent and predictable user experience. Figure 2-13 illustrates the thumbnail view in action, in which it is partially filled with loaded scribble images.

Figure 2-13. The thumbnail view filled with placeholder images and fully loaded scribble thumbnails

How can we design a class to do that? Well, in fact, there is a design pattern called the Proxy pattern (Chapter 22). A proxy is a placeholder or a surrogate of a real resource or object. One aspect of the Proxy pattern is to have a virtual proxy to help lazy-load heavy-weighted resources when it's requested to do so.

We need to create a thumbnail proxy class that returns a default placeholder image while it's doing some sort of lazy-loading for an actual image in the background. A typical example application on iOS is Mail. Every attachment in an e-mail is shown as a rectangular placeholder image. Until you tap it, it will load the actual attachment in the background. Instead of taking extra time to load potentially bulky email messages due to the size of the attachments, it displays a placeholder image for each attachment so the user can read the content immediately without waiting for the whole thing to be downloaded. Figure 2-14 illustrates the concept of the design.

Figure 2-14. A thumbnail proxy for a scribble is first showing a placeholder image and then loading a real thumbnail in the background. When the loading process is completed, the proxy shows the real image in place of the placeholder image.

We can create a proxy class called ScribbleThumbnailProxy. Since it knows how to draw something on a view, ScribbleThumbnailProxy should be a subclass of UIView. A ScribbleThumbnailProxy object represents a thumbnail image. Each of the thumbnails does the following things when it is first loaded on the thumbnail view:

The user can browse through the whole thumbnail view to select which one to open. By tapping one of them, the real scribble represented by the thumbnail will be opened on the canvas view again, as shown in Figure 2-15.

Figure 2-15. An illustrative diagram shows that a scribble thumbnail can be used as a button to invoke loading the real scribble on the canvas view.

One of our requirements is to allow the user to undo or redo what is drawn on the screen so each stroke or dot can be undone, or if it's necessary, redone. We've already put two buttons for these purposes in the original wireframe in Figure 2-1. The left-turning button is for undoing and the right-turning one is for redoing, as illustrated in Figure 2-16.

Figure 2-16. The undo and redo buttons on the canvas view's toolbar

In order to achieve the undo capability, we need to somehow keep track of what has been drawn so we can remove it from the view, one at a time. At the same time, what has been removed from the view can also be replayed onscreen. For these reasons, it would be very difficult, if not impossible, to put any drawing mechanism in instance methods or functions. There is almost no way to reuse those functions and methods for keeping a history of drawing commands effectively. We need to put a drawing command into an object, so it can be kept in a history, as shown in Figure 2-17.

Figure 2-17. Each command object is added to a list of command history. By iterating through the list, one can undo/redo particular commands.

Each command has methods to "execute" an operation and "undo" to reverse the action. By enumerating the list, we can ask any one of the commands to undo/redo its operations. We can use an index to keep track of the current command. Moving the index in the direction toward the commands invoked in the past, we can undo each command one at a time. Likewise, moving the index forward up to the present command allows us to redo each of them. A design pattern that can help solve this kind of design problem is called the Command pattern (Chapter 20).

There are a few framework classes available in the Cocoa Touch framework for you to implement the Command pattern—for example, an object of NSInvocation encapsulates a command in the form of a target-selector entity. An NSUndoManager instance maintains a list of NSInvocation objects in its undo and redo stacks. Once an NSInvocation object is pushed in the NSUndoManager's undo stack, it can be popped and invoke its registered undo operation. Any popped NSInvocation object from the undo stack will be pushed to a redo stack. Then the undo/redo cycles can continue. The details of implementing the Command pattern are explained in Chapter 20.

The Command pattern (Chapter 20) is not only for implementing an undo/redo infrastructure but can also be used for implementing any deferred-command mechanism. In the sense of traditional desktop applications, each menu item of the main menu encapsulates a command object. When the user activates the menu item, the embedded command will be invoked. The command is first assigned to each menu item when the application is loaded, but an invocation of the command is deferred until the menu item is activated later. One of the benefits of using the Command pattern in a menu design is that the commands used in menu items can be reused in other areas, such as keyboard shortcuts or some other user interface elements for the same commands.

Based on our requirements for our PaletteViewController, the user can change stroke sizes and colors that will be used for the next stroke/dot creation in CanvasViewController. We need some commands to change stroke colors and sizes for that reason and purpose. PaletteViewController has three sliders to let the user adjust the color of a stroke by setting each color component—red, green, and blue—individually. Instead of creating separate commands that operate on individual color components, we rather create one single command that deals with the overall color change.

Let's say we create a SetStrokeColorCommand class just for that. According to the wireframe in Figure 2-2, there are three sliders and each of them is for adjusting one particular color component. After we hook them up with a SetStrokeColorCommand object, it will do its job in its execute operation to update the color of the next stroke and the color palette view located right below the sliders. The color palette reflects the current stroke color based on the values from the RGB sliders. The SetStrokeColorCommand object becomes a liaison for them. The SetStrokeColorCommand object notifies other observing components of any color changes made by moving the RGB sliders. For some reason, we need to have more than one component to monitor color changes; we can let SetStrokeColorCommand maintain a list of multiple observers. SetStrokeColorCommand can notify its observers when color changes occur, so they can perform appropriate operations. The observe-notify or publish-subscribe model is known as the Observer pattern (Chapter 12). Making a command object notify observers is an example of using compound design patterns for solving design problems. Likewise, we can create a similar class, SetStrokeSizeCommand, for updating the size of the next stroke created on the canvas view.

Figure 2-18 illustrates how SetStrokeColorCommand and SetStrokeSizeCommand objects interact with various UISlider controls as well as the small color palette view on the PaletteViewController and CanvasViewController.

Figure 2-18. An interactive flow diagram shows how the controls on the PaletteViewController interact with various command objects and their targets (i.e., PaletteViewController and CanvasViewController).

Should we need to change the UI elements to present a different way to change stroke colors and sizes, we can still reuse what's in SetStrokeColorCommand and SetStrokeSizeCommand objects. We can, for example, use a circular color selection wheel instead of separate RGB sliders to change the stroke color with the same SetStrokeColorCommand object.

We can use the same idea to create another command class and use its object to delete the current scribble onscreen. A toolbar button is bound to the delete command. When the button is tapped, the command will be executed and the embedded instructions to delete the current scribble data will be carried out. When the canvas view is refreshed by the command, the original scribble will be gone, and the user can start drawing a new one again.