Please help me with block-based callbacks

Question

I have an ill-understanding of block-based callbacks. There seems to be two approaches that I'm aware of and I don't know when I should be using one over the other so could someone please explain to me the differences between the two, correct me and give me some tips if I need any.

Some code I found off stackoverflow as well as a library from elsewhere so thanks to those who wrote this code.

typedef void (^MyClickedIndexBlock)(NSInteger index);
@interface YourInterface : YourSuperClass
@property (nonatomic, strong) MyClickedIndexBlock clickedIndexBlock

.m
//where you have to call the block
if (self.clickedIndexBlock != nil) {self.clickedIndexBlock(buttonIndex)};

// where you want to receive the callback
alert.clickedIndexBlock = ^(NSInteger index){NSLog(@"%d", index);};

my understanding with the above is that:

1. MyClickedIndexBlock is typedef to a NSInteger. Property created with the name "clickedIndexBlock" which is of type MyClickedIndexBlock (meaning that clickedIndexBlock can be a number).

2. Blocks can also be used as methods which is why I can call self.clickedIndexBlock(buttonIndex);

BUT something tells me that this approach as a @property only really supports one parameter eg. NSInteger.

WHEREAS the following approach allows for more than one parameter.

bluetoothMe.h

typedef void (^hardwareStatusBlock)(CBPeripheral *peripheral, BLUETOOTH_STATUS status, NSError *error);

- (void)hardwareResponse:(hardwareStatusBlock)block;

bluetoothMe.m

- (void)hardwareResponse:(hardwareStatusBlock)block {
privateBlock = [block copy]; 
}

- (void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral {
NSLog(@"Did connect to peripheral: %@", peripheral);

privateBlock(peripheral, BLUETOOTH_STATUS_CONNECTED, nil);

NSLog(@"Connected");
[peripheral setDelegate:self];
[peripheral discoverServices:nil];
 }

My understanding that creating a property which is strong and doing a [block copy] will retain the block around until the app terminates. So [block copy] and strong both retain. [block copy] is applied to the block to retain otherwise the block would have vanished when the method goes out of scope.

ViewController.m

[instance hardwareResponse:^(CBPeripheral *peripheral, BLUETOOTH_STATUS status, NSError *error) {

    if (status == BLUETOOTH_STATUS_CONNECTED)
    {
        NSLog(@"connected!");
    }
    else if (status == BLUETOOTH_STATUS_FAIL_TO_CONNECT)
    {
        NSLog(@"fail to connect!");
    }
    else
    {
        NSLog(@"disconnected!");
    }

    NSLog(@"CBUUID: %@, ERROR: %@", (NSString *)peripheral.UUID, error.localizedDescription);
}];

So lets see what my questions were:

1) When would I choose the first approach over the second approach and vice versa?

2) First example, the block was a typedef to a property. Second example, the block was declared a method. Why couldn't the first example be declared a method and why couldn'tt the second example be typedef to a property?

3) Would I need to create a typedef for every type of delegate method that I want a block-based callback for?

4) At of date, ive only seen one delegate method supported. Could you show me an example on how one would implement each approach if I was to create block-based callbacks on multiple delegate methods which are not similar.

Appreciate your feedback. This is hard at times. Need as much help as I can get. Thanks,

Ben

Answer 1

The questions

• Whether to typedef a block or not,
• whether to use a property for a block or not,
• whether a block has a single or multiple arguments,

are completely independent (or orthogonal). All combinations are possible and allowed.

void (^myClickedIndexBlock)(NSInteger index);

declares a block variable myClickedIndexBlock taking an integer argument and returning void. You can use typedef if the same block type occurs repeatedly in your program:

// Define MyClickedIndexBlock as *type* of a block taking an integer argument and returning void:
typedef void (^MyClickedIndexBlock)(NSInteger index);
// Declare myClickedIndexBlock as a *variable* of that type:
MyClickedIndexBlock myClickedIndexBlock;

With multiple arguments:

void (^privateBlock)(CBPeripheral *peripheral, BLUETOOTH_STATUS status, NSError *error);

or

typedef void (^hardwareStatusBlock)(CBPeripheral *peripheral, BLUETOOTH_STATUS status, NSError *error);
hardwareStatusBlock privateBlock;

Instead of (instance) variables, you can use properties. In the first example:

@property (nonatomic, copy) void (^myClickedIndexBlock)(NSInteger index);

declares myClickedIndexBlock as a block property, and is equivalent to

typedef void (^MyClickedIndexBlock)(NSInteger index);
@property (nonatomic, copy) MyClickedIndexBlock clickedIndexBlock;

Contrary to your assumption, block properties are not restricted to blocks with a single argument. You can use a property also in the second example, with or without typedef:

@property (nonatomic, copy) void (^privateBlock)(CBPeripheral *peripheral, BLUETOOTH_STATUS status, NSError *error);

or

typedef void (^hardwareStatusBlock)(CBPeripheral *peripheral, BLUETOOTH_STATUS status, NSError *error);
@property (nonatomic, copy) privateBlock;

It is your choice whether to use instance variables or properties for blocks. I would use properties (with the "copy" attribute).

Whether to typedef or not is purely a matter of taste. It helps to avoid errors if the same block type occurs repeatedly in your program. On the other hand, the Xcode autocompletion seems to work better without typedef (in my experience).

Answer 2

I strongly suggest you read the Blocks Programming Guide.

Blocks are not methods. I'm not going to paraphrase what's said in the Conceptual Overview, but just quote some parts:

Blocks represent typically small, self-contained pieces of code. [...]
They allow you to write code at the point of invocation that is executed later in the context of the method implementation.

It seems you're confused by the syntax.

typedef void (^MyClickedIndexBlock)(NSInteger index);

It's basically just defining a type named MyClickedIndexBlock representing a block that takes a single parameter of type NSInteger and returns nothing (void).
It's not a typedef to a NSInteger.

@property (nonatomic, strong) MyClickedIndexBlock clickedIndexBlock

is a declaration of a property that will contain a MyClickedIndexBlock.
It's not required to typedef blocks, it would be perfectly valid to write

@property (nonatomic, strong) void(^clickedIndexBlock)(NSInteger index);

But for the sake of clarity (or reuse), you may choose to typedef them. Notice that the property name is what follows the ^.

You're stating that blocks can be used as methods because it's possible to call self.clickedIndexBlock(buttonIndex) in your example. But in fact, it's because you've declared a property named clickedIndexBlock that you can call it like that.

There's a lot in your question, but a large part is due to confusion and misunderstanding. The 2 approaches you mention aren't really different. Blocks are objects and can be manipulated as parameters, local variables or ivars / properties just as you would do with NSString or other kinds of objects.

Answer 3

1) The block isn't typedef'd to an integer. It's typedef'd to return void and has an integer parameter. There is no advantage to ethos 1 or method 2; they both can have multiple parameters if declared.

2) No reason why that format has been chosen for either case. They both achieve the same result, but the first one is arguably better semantically.

3) No. You can declare blocks inline to a method. Look at the header for [NSArray enumerateObjectsUsingBlock:] for an example of inline block declaration.

4) You can just create multiple properties and call each distinct block when necessary.