I have a read-only property isFinished
in my interface file:
typedef void (^MyFinishedBlock)(BOOL success, NSError *e);
@interface TMSyncBase : NSObject {
BOOL isFinished_;
}
@property (nonatomic, readonly) BOOL isFinished;
and I want to set it to YES
in a block at some point later, without creating a retain cycle to self
:
- (void)doSomethingWithFinishedBlock:(MyFinishedBlock)theFinishedBlock {
__weak MyClass *weakSelf = self;
MyFinishedBlock finishedBlockWrapper = ^(BOOL success, NSError *e) {
[weakSelf willChangeValueForKey:@"isFinished"];
weakSelf -> isFinished_ = YES;
[weakSelf didChangeValueForKey:@"isFinished"];
theFinishedBlock(success, e);
};
self.finishedBlock = finishedBlockWrapper; // finishedBlock is a class ext. property
}
I'm unsure that this is the right way to do it. Will this code leak, or break, or is it fine? Perhaps there is an easier way I have overlooked?
Passing block variable can be nil, check before calling or add assert on start of the function or you will crash
Since you are not retaining self and we assume that you execute some long task on background thread by the time your code get's executed weakSelf can be nil ( hopefully you are using ARC and 5.0 so you have niled weak references ).
If you don't have real weak references ( < 5.0, no ARC, compiler would still accept __weak but it wouldn't matter ) this would lead to crash.
Also accessing ivar using '->' will lead to crash if object pointer is nil so you need to make sure it doesn't happen.
Even if you do the code as dasblinkenlight wrote it can crash if weakSelf will be nil at the moment, let's say you dispatch the block on background thread and then object get released before block's executes, this makes weakSelf nil thus accesing it by using '->' will lead to crash. In that case I would modify the code as follows:
__weak MyClass *weakSelf = self;
MyFinishedBlock finishedBlockWrapper = ^(BOOL success, NSError *e) {
MyClass *strongSelf = weakSelf;
//! whatever task you want executed
strongSelf.isFinished = YES;
theFinishedBlock(success, e);
};
Also you could test if weakSelf is nil to prevent expensive task from execution if it doesn't make sense ( object is already destroyed ). But this depends on use case.
But there is also other case you need to consider when programming with blocks, for example: You can have a job object instance that's only role is to execute some task in background, in that case this code could fail because you would create new task and it could be deallocated before block executes on background thread, in that case you should retain self and don't retain block in the object ( this will prevent retain cycle ).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With