Here’s a design I’ve had knocking around my head for a while, and between a discussion we had a few weeks ago at work and Saul Mora’s excellent design patterns talk at QCon I’ve built it.
A quick heads-up: currently the logic is all built into a side project app I’ve been working on so I don’t have a single project download I can point to. The post here should explain all of the relevant code, which is made available under the terms of the MIT Licence. A reusable component is forthcoming.
Motivation
Remove the Massive View Controller from our applications’ architectures. Push Cocoa, Cocoa Touch, or other frameworks to the edges of our codebase, responsible only for working with the UI. Separate the concerns of user interaction, work scheduling and the actual work.
There are maintainability reasons for doing so. We separate unrelated work into different classes, localising the responsibilities and removing coupling between them. The same code can be used in multiple contexts, because the UI frameworks are decoupled from the work that they’re doing. This is not only a benefit for cross-platform work but for re-using the same logic in different places in a single user interface.
We also notice performance optimisations that become possible. With a clear delineation between the user interface code and the work, it’s much easier to understand which parts of the application must be run on the user interface thread and which can be done in other contexts.
Solution
Implement the Message Bus pattern from server applications. In response to a user event, the user interface creates a command object and sends it to a command bus. The command bus picks an appropriate handler, passes it the command and schedules it. The user interface, the work done and the scheduling of that work are therefore all decoupled.
Workflow
At application launch, the application accesses the shared IKBCommandBus object:
@interface IKBCommandBus : NSObject + (instancetype)applicationCommandBus; - (void)execute: (id <IKBCommand>)command; - (void)registerCommandHandler: (Class)handlerClass; @end
and registers command handlers. Command handlers know what commands they can process, and can tell the bus whether they will accept a given command. Handlers can also be loaded later, for example in Mac applications or server processes when a new dynamic bundle is loaded.
Once the application is running, the command bus can be used by user interface controllers. These controllers are typically UIViewControllers in an iOS app, NSViewControllers, NSDocuments or other objects in a Cocoa app, or maybe something else in other contexts. A controller receives an action related to a user interface event, and creates a specific IKBCommand.
@protocol IKBCommand <NSObject, NSCoding> @property (nonatomic, readonly) NSUUID *identifier; @end
Commands represent requests to do specific work, so the controller needs to configure the properties of the command it created based on user input such as the current state of text fields and so on. This is done on the user interface thread to ensure that the controller accesses its UI objects correctly.
The controller then tells the application’s command bus to execute the command. This does not need to be done on the user interface thread. The bus looks up the correct handler:
@interface IKBCommandHandler : NSObject + (BOOL)canHandleCommand: (id <IKBCommand>)command; - (void)executeCommand: (id <IKBCommand>)command; @end
Then the bus schedules the handler’s executeCommand: method.
Implementation and Discussion
The Command protocol includes a unique identifier and conformance to the NSCoding protocol. This supports the Event Sourcing pattern, in which changes to the application can be stored directly as a sequence of events. Rather than storing the current state in a database, the app could just replay all events it has received when it starts up.
This opens up possibilities including journaling (the app can replay messages it received but didn’t get a chance to complete due to some outage) and syncing (the app can retrieve a set of events from a remote source and play those it hasn’t already seen). An extension to the implementation provided here is that the event source acts as a natural undo stack, if commands can express how to revert their work. In fact, even if an event can’t be reversed, you can “undo” it by removing it from the event store and replaying the whole log back into the application from scratch.
When a command is received by the bus, it looks through the handlers that have been registered to find one that can handle the command. Then it schedules that handler on a queue.
@implementation IKBCommandBus
{
NSOperationQueue *_queue;
NSSet *_handlers;
}
static IKBCommandBus *_defaultBus;
+ (void)initialize
{
if (self == [IKBCommandBus class])
{
_defaultBus = [self new];
}
}
+ (instancetype)applicationCommandBus
{
return _defaultBus;
}
- (id)init
{
self = [super init];
if (self)
{
_queue = [NSOperationQueue new];
_handlers = [[NSSet set] retain];
}
return self;
}
- (void)registerCommandHandler: (Class)handlerClass
{
_handlers = [[[_handlers autorelease] setByAddingObject: handlerClass] retain];
}
- (void)execute: (id <IKBCommand>)command
{
IKBCommandHandler *handler = nil;
for (Class handlerClass in _handlers)
{
if ([handlerClass canHandleCommand: command])
{
handler = [handlerClass new];
break;
}
}
NSAssert(handler != nil, @"No handler defined for command %@", command);
NSInvocationOperation *executeOperation = [[NSInvocationOperation alloc] initWithTarget: handler selector: @selector(executeCommand:) object: command];
[_queue addOperation: executeOperation];
[executeOperation release];
[handler release];
}
- (void)dealloc
{
[_queue release];
[_handlers release];
[super dealloc];
}
@end
Updating the UI
By the time a command is actually causing code to be run it’s far away from the UI, running a command handler’s method in an operation queue. The application can use the Observer pattern (for example Key Value Observing, or Cocoa Bindings) to update the user interface when command handlers change the data model.
