Recapturing Strong References to Weakly Referenced Objects Inside Blocks - ios

Question

I am a Obj-C programmer who was born, and has only lived in a post ARC world. For my own efficacy though, I recently decided to go through Apple's Transitioning to ARC Release Notes. In the ARC Introduces New Lifetime Qualifiers section, there is a subsection titled Use Lifetime Qualifiers to Avoid Strong Reference Cycles that describes various ways to use qualifiers in potential in order to avoid potential retain cycles.
My question has to do with the last two examples. The first of the last two examples uses a pattern that I often utilize in order to avoid deallocating a UIKit object prematurely from a non-main thread:
MyViewController *myController = [[MyViewController alloc] init…];
// ...
MyViewController * __weak weakMyViewController = myController;
myController.completionHandler = ^(NSInteger result) {
[weakMyViewController dismissViewControllerAnimated:YES completion:nil];
};
In the above example, the weakMyViewController object is created with a weak reference to myController so that the block referencing weakMyViewController can use it, and upon return of the block, weakMyViewController can safely fall out of scope without decrementing the reference count of the underlying UIKit object being referenced.
In the next example though, Apple shows the following code for "non-trivial cycles":
MyViewController *myController = [[MyViewController alloc] init…];
// ...
MyViewController * __weak weakMyController = myController;
myController.completionHandler = ^(NSInteger result) {
MyViewController *strongMyController = weakMyController;
if (strongMyController) {
// ...
[strongMyController dismissViewControllerAnimated:YES completion:nil];
// ...
}
else {
// Probably nothing...
}
};
In the above "non-trivial" example offered, the same __weak qualifier is used to reference the UIKit object from within the block, but then the code creates an local implicit __strong reference to the same object. Then that local __strong reference is tested for a non-nil condition, and is then operated on.
My two questions are:
Under what considerations should an Obj-C programmer implement the second design pattern (as opposed the former)? I don't understand Apple's comment about "non-trivial cycles"
How does the __strong reference to weakMyController not increment the retain count of the original myController object? If weakMyController is only a pointer to the underlying object that myController points to, wouldn't a strong pointer (i.e. stringMyController) increment the retain count of the underlying object (the object that myController is pointing to)?

Answer 1

Regarding your first example, the motivation you ascribe to having the block literal only keep a weak reference to the instance pointed to by myController is not quite correct. weak references won't stop an object from deallocating, and the purpose of the weak reference is to prevent a strong reference cycle (also called a retain cycle). In this situation, the strong reference cycle would be manifested by myController maintaining a strong reference to the block stored in completionHandler, while the block maintains a strong reference back to myController - neither would ever be deallocated (without un-setting the completionHandler property at some future time). Thus, the motivation here is quite the opposite of keeping an object alive - it's to allow myController to deallocate normally when all other references to it cease to exist.
The second example is an extension of the first, but by assigning the captured weak reference to a strong reference local to the block, we can ensure that so long as the controller is still alive when block execution begins, it will remain alive until the end of block execution. Since the strong reference is scoped only to the block, it doesn't create a strong reference cycle. In other words, strongMyController is local only to the scope of the block's code, and is not retained by the block object itself.
Now, to address your specific questions:
You would take this approach when you want to ensure the block completes execution with a reference to a live, non-nil object from its enclosing scope, if that object was alive when the block begins execution. If there's a chance that all other strong references to an object may disappear during execution of the block, you should seriously consider using this.
The strong reference certainly does increment the reference count, and is the point - while the scope of the block's code is active, the controller will be kept alive. This does not form a strong reference cycle since, again, it's not the block object that maintains the reference, but the variable used in the block's code, which only exists when the block is executing. Assuming the block does not continue execution to infinity, then the cycle will be broken.