Category Archives: Code

Block Delegates

Often I find myself implementing the same delegate protocol over and over. Consider, for example, the Facebook SDK for iOS. I’d like to make lots of requests to the Graph API, and not have a single callback method

request:didLoad:

in a single class that looks like:

-(void)request:(FBRequest*)request didLoad:(id)result
{
    if (request == mainRequest)
    {
        // handle result
    }
    else if (request == subRequest1)
    {
        // handle result
    }
    else if (request == anotherRequest)
    {
        // handle result
    }
    //... far too many if blocks for my liking
}

This happens because we use one class as the delegate for all the requests. The alternative is to implement multiple classes, but then the handling code becomes spread across, well, multiple classes, which is yucky.

So what to do? Well (this has probably been done before but) my solution is to implement a delegate class once, and for each request, instantiate one, and pass it implementations using block properties. I will call this pattern Block Delegates. It goes like this.

First, set up a skeleton delegate, which implements the delegate protocol and has block properties for each delegate method that might be called:

@interface FBRequestBlockDelegate : NSObject <FBRequestDelegate> {}
@property (nonatomic, copy) void(^requestLoading)(FBRequest*);
@property (nonatomic, copy) void(^requestDidReceiveResponse)(FBRequest*,NSURLResponse*);
@property (nonatomic, copy) void(^requestDidFailWithError)(FBRequest*,NSError*);
@property (nonatomic, copy) void(^requestDidLoad)(FBRequest*,id);
@property (nonatomic, copy) void(^requestDidLoadRawResponse)(FBRequest*,NSData*);
@end

Then use an implementation like this:

@implementation FBRequestBlockDelegate
@synthesize requestDidFailWithError, requestDidLoad, requestLoading, requestDidLoadRawResponse, requestDidReceiveResponse;
- (void)requestLoading:(FBRequest*)request
{
    if (self.requestLoading) self.requestLoading(request);
}
- (void)request:(FBRequest*)request didReceiveResponse:(NSURLResponse*)response
{
    if (self.requestDidReceiveResponse) self.requestDidReceiveResponse(request, response);
}
- (void)request:(FBRequest*)request didFailWithError:(NSError*)error
{
    if (self.requestDidFailWithError) self.requestDidFailWithError(request, error);
}
- (void)request:(FBRequest*)request didLoad:(id)result
{
    if (self.requestDidLoad) self.requestDidLoad(request,result);
}
- (void)request:(FBRequest*)request didLoadRawResponse:(NSData*)data
{
    if (self.requestDidLoadRawResponse) self.requestDidLoadRawResponse(request,data);
}
-(void)dealloc {
    self.requestDidFailWithError = nil;
    self.requestDidLoad = nil;
    self.requestDidLoadRawResponse = nil;
    self.requestDidReceiveResponse = nil;
    self.requestLoading = nil;
    [super dealloc];
}
@end

Now you can bundle the delegate code right next to the request. It only has to handle the current case, so no massive sequence of unnecessary if-statements.

    FBRequestBlockDelegate *delegate = [FBRequestBlockDelegate new];
    delegate.requestDidLoad = ^(FBRequest *request, id result) {
        // Process this particular request
        [delegate release];
    };

    [self.facebook requestWithGraphPath:@"some path"
                            andDelegate:delegate];

Don’t forget that delegates aren’t usually retained by the class it is a delegate of, so a good idea is to release the delegate at the end of the last that will be called block.

Less is More :(

The majority of work I do, as a programmer who wears a shirt and tie, involves databases. And I try to keep things nice and simple when working with databases. What I mean by simple is, extra tables in a database is fine, even triple the “minimum number” (whatever that is), if they all mostly follow some pattern. Constructing a database schema is then a simple application of the rules devised when designing the pattern, and means there’s not much to think about or have go wrong. With a judicious choice of pattern, ORM tools like Hibernate or other things like .NET Entity Framework can start working for you rather than against you. It’s even possible to write code to check over the schema and ensure that the pattern is being followed, and then write code to write code to do all the data access (yes, write code to write code…)

My boss, on the other hand, has a slightly different idea of simplicity. Namely, in his view, simplicity = minimise number of tables, and rely on stored procedures for everything.  The arguments I want to win with him are not really what I want to blog about today.

Today I’d like to describe how I implemented strongly-typed lists of objects (think List<SomeType> in C# / list<AClass> in C++) adhering to my boss’s vision of minimising table count, using only three tables and a pile of T-SQL and custom constraints, instead of the “more complex” system of lots of join tables and foreign key constraints. I do not particularly recommend this mode of implementation. For a start, it has made use of .NET Entity Framework, shall we say, “interesting.”

Continue reading

A brief history of ACM-SPPC T-shirts, and more

Yesterday was the South-Pacific region event for the annual ACM ICPC. You can read more about it in general at http://cm.baylor.edu/welcome.icpc and our regional at http://sppcontest.org/.

Every year, among the IBM-branded schwag that the members of competing teams receive for their five hours of keyboard-mashing, swearing, headdesking and facepalming, is a t-shirt. Shirts are also given to the organisers and are generally a different colour. This is an attempt to chronicle the various colours of competitor shirt given out over recent years. Continue reading