Thoughts on formatting blocks

When I first started writing serious Objective-C code in 2005, I had the benefit of a stern taskmaster in Aaron Hillegas of the Big Nerd Ranch, on proper style. He read us a list of standards to follow, such as class methods always appear before instance ones, that all braces for methods and ivar wrappers appear as the first character of a line (well I think that’s what he said). In addition, this is the proper method syntax:

- (NSString *)foo:(SomeClass *)name;

The ‘-‘ or ‘+’ the first character, a space, the type, the name, no spaces between the ‘:’ and the next character, etc as you can see.

With blocks, well, I never saw a style I liked in sample code, and the sample code is all over the place in terms of styles. After a few months I’ve settled down to an uncommon style (which I hope to make less common by publicizing it!):

[dict enumerateKeysAndObjectsUsingBlock:^(NSString *key, NSArray *obj, BOOL *stop))
    {
        ... the code
    } ];

Using this style makes it very easy to spot the blocks in code, and also to visually identify where blocks are when you quickly scan a big file.

To my eye, putting the braces directly under the ‘[‘ makes it look too much like a simple C block unconnected to the line above.

Note that I’ve changed the id key and id obj to specific types. I totally forget where I picked this up – I may in fact have just tried to use it and found it would work. It sure saves me a lot of time in created a second object casted to the id value or using one or more casts within an expression.

When I assign a block variable, it gets a bit more tricky, but this is what I do for multi-line blocks:

dispatch_block_t b = ^{
                          ... code
                      };

I’ve really gotten to like this style, now with my strong opinions on C, Objective-C, and blocks styles I’m afraid I’ll never be able to integrate into a coding group that has already written a style guide. YMMV

I finally figured out weakSelf and strongSelf

One problem with using blocks and asynchronous dispatch is that you can get into a retain cycle – the block can retain ‘self’, sometimes in mysterious ways. For instance, if you reference an ivar directly, what appears in the code is ‘theIvar’, the compiler generates ‘self->theIvar’. Thus, ‘self’, as a strong variable, is retained, and the queue retains the block, and the object retains the queue.

Apple recommends first assigning ‘self’ into a weak automatic variable, then referencing that in a block (see 1). Since the block captures the variable along with its decorators (i.e. weak qualifier), there is no strong reference to ‘self’, and the object can get dealloced, and at that moment the weak captured variable turns to nil.

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
{
[weakSelf doSomething];
} );

Thinking about this, it occurred to me that ‘weakSelf’ might turn to nil in the middle of ‘doSomething’, but after a few posts on the xcode list, I was given a reference to a clang document that explicitly states that any object within an expression is retained for the complete expression, and only released thereafter (see 2). Whew!

But how about:

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
{
[weakSelf doSomething];
[weakSelf doSomethingElse];
} );

Well, in this case, its possible for ‘weakSelf’ to be non-nil for the first method, but not for the second. Hmmm – the above is a simple example, most real code would get much more complex with other usages of ‘weakSelf’.

Apple calls this second example ‘non-trivial’ (see 1), and does what first seems like a bizarre set of steps: first create the ‘weakSelf’ object, then assign that to a ‘strongSelf’:

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
{
__typeof__(self) strongSelf = weakSelf;
[strongSelf doSomething];
[strongSelf doSomethingElse];
} );

or in Swift:

dispatch_async(dispatch_get_main_queue()) { [weak self] in
if let strongSelf = self {
//…
}
}
// See “Resolving Strong Reference Cycles for Closures” in The Swift Programming Language

I looked and looked at this trying to reason it out (guess I’m just slow). Finally, the light bulb lit, and I figured it out! When the block runs, it’s only captured ‘weakSelf’. At the instant the block starts up, ‘weakSelf’ is either ‘self’, or it’s nil. Your code (as Apple’s example does) can test to see if ‘strongSelf’ is set, and if so you can use ‘strongSelf->theIvar’ or the more normal ‘strongSelf.someProperty’ (the latter works fine with nil messaging, the former will crash if ‘strongSelf’ is nil).

If ‘weakSelf’ is equal to ‘self’, then ‘strongSelf’ retains it, and it stays retained until the block returns, when its released. It’s all or nothing.

I felt really good finally getting this, and its making my coding of blocks much easier.

NOTE:

If you’re puzzled by the use of __typeof__(self), it’s a non-standard clang macro that turns into the class of the parenthesized object, and was taken from GCC. The nice thing about using it is that you can make this line a Code Snippet (mine is called ‘WeakSelf’), and you don’t have to continually adjust the class type.

1) “Programming With ARC Release Notes, search for “For non-trivial cycles, however, you should use”

2) http://clang.llvm.org/docs/AutomaticReferenceCounting.html :

For __weak objects, the current pointee is retained and then released at the end of the current full-expression. This must execute atomically with respect to assignments and to the final release of the pointee.

NSOperation-WebFetches-MadeEasy

In late 2011 I found the need to use the same concurrent NSOperation feature, but in a class not descended from UIViewController. I had two choices: either duplicate the NSOperations code in a second subclass, or find a way to extract it into something I could re-use anywhere.

I choose the second approach, and created OperationRunner, a helper class that I use to this day. In the end, this helper class can be incorporated into any Objective-C class by taking 6 or so simple steps as outlined in the OperationsRunner.h file. This involves adding imports for this header file and another header with a single protocol callback method. The actual operations are subclasses of a single NSOperation subclass, ConcurrentOperation. A further subclass, WebFetcher, adds web functionality. [In my current code I have a half dozen or so such subclasses.] I created this code on my own time, and thus can incorporate it elsewhere as I see fit as I own it.

The helper class provides a small set of methods:

  • (id)initWithDelegate:(id <OperationsRunnerProtocol>)del;
  • (void)runOperation:(NSOperation *)op withMsg:(NSString *)msg;
  • (NSSet *)operationsSet;
  • (NSUInteger)operationsCount;
  • (void)cancelOperations;
  • (void)enumerateOperations:(void(^)(NSOperation *op)) b;

Operations are submitted with the runOperation and an optional debug message, which can get logged when the operations gets submitted to the NSOperationsQueue, and also when it completes. This is quite handy during debugging, and in my code I always supply a string, but suppress logging if the build is Deployment.

The completed operation is returned to the caller object via a delegate message:

– (void)operationFinished:(NSOperation *)op;

Within that message, the OperationsRunner object can report back whether this is the last operations, or others are still pending (they might even be all complete but have not been fed back via the delegate message.)

Queued operations can be cancelled at any time, and the whole stack quickly and gracefully collapses—cancelled operations do not result in delegate callbacks either.

My code has made extensive use of this class, and actually uses the exact code found in the NSOperation-WebFetches-MadeEasy repository. My last App Store App, Lot18, made extensive use of it, and often had hundreds of html and image fetches going on in multiple instances of the OperationsRunner. Refinements made at this time included the ability to vary the maximum number of concurrent operations, and the priority of the serial dispatch queue used to manage the operations. This architecture let the UI be responsive even in the face of a huge amount of background work (and the app has a 5 star rating!)

I am aware of many other networking frameworks, but mine does not try to be all inclusive—it does one thing really well—and it does what it aims to do quite well (YMMV). It’s something I’m very proud of, and I hope others will find it useful.