objective-c-blocks

Possible Duplicate: Do code blocks completely replace delegates? I just encountered the following declaration from a forum: "Delegates is the past. Blocks are the future." 1) Are blocks the preferred way to do 'delegation' duties over delegates? 2) Is there any particular benefit of using a delegate vs a block? I think there's a slight misunderstanding in what delegates do and what blocks do. In Objective-C, there are three ways to handle callbacks: Delegation -> where you make one object the delegate of another object and you have to specify which kinds of events generated by the "parent"

I'm looking to create a category to replace delegate methods with callbacks blocks for a lot of the simple iOS APIs. Similar to the sendAsyc block on NSURLConnection. There are 2 techniques that are leak free and seem to work fine. What are the pros/cons about each? Is there a better way? Option 1. Use a category to implement the delegate's callback method on NSObject with the external callback block scoped. // Add category on NSObject to respond to the delegate @interface NSObject(BlocksDelegate) - (void) alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex; @end

I am trying to create a (network) synchronized array for the company I work for. While the networking part works fine, I have dwelled into an issue. My wish was to create a new queue using dispatch_create_queue , to which I would add two blocks that are not to run on the main thread, but in a serial manner, meaning that first the first block has to run, then the second, and never in parallel. I've read the apple documentation, but it is confusing to say the least. When I create my queue using dispatch_queue_create and then add the blocks (after they have been defined) using dispatch_sync , I

every time I have to use a global var or property inside a block like this: self.save = ^(){ if (isItSaving == NO) { [self saveMyFile]; } }; I have to rewrite this like BOOL *iis = isItSaving; id myself = self; self.save = ^(){ if (iis == NO) { [myself saveMyFile]; } }; or Xcode will complain "capturing self strongly in this block is likely to lead to a retain cycle... It complains even about BOOL variables? Redeclaring everything before a block appears to be a lame solution. Is this the correctly way? Is there an elegant way? This stuff is ugly. I am using ARC. Nikolai Ruhe The problem only

When designing a block-based API in ObjC, which approach is better, one completion block or two, one each for success and failure? Let's say we have a method retrieving something asynchronously to a block, with one completion block it would be: - (void) retrieveSomethingCompletion:(void (^)(id retrievedObject, NSError *error))completionBlock; And with success/failure blocks (AFNetworking style): - (void) retrieveSomethingSuccess:(void(^)(id retrievedObject))successBlock failure:(void(^)(NSError *error))failureBlock; I always use the second approach, but what are the pro/cons of each option?

I was reading the documentation from apple about memory management when I got to autorelease pool blocks and something got me thinking. Any object sent an autorelease message inside the autorelease pool block is released at the end of the block. I am not sure I fully understand this. Any object created inside an autorelease pool block gets released at the end of the block anyway because that is it's life span. Why would you need to call autorelease to the object when it is going to get released anyway when it reaches the end of the block? To be clearer, I will give an example, of what I am

Question We're developing a custom EventEmitter inspired message system in Objective-C. For listeners to provide callbacks, should we require blocks or selectors and why? Which would you rather use, as a developer consuming a third party library? Which seems most in line with Apple's trajectory, guidelines and practices? Background We're developing a brand new iOS SDK in Objective-C which other third parties will use to embed functionality into their app. A big part of our SDK will require the communication of events to listeners. There are five patterns I know of for doing callbacks in

In my iOS ARC-enabled code, I need to pass "self" and other objects to a block. More specifically, I need to interact with self and an ASIHTTPRequest object inside the ASIHTTPRequest 's completionBlock . _operation = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(parseServerReply) object:nil]; _request = [ASIHTTPRequest requestWithURL:@"server.address"]; // ... [_request setCompletionBlock:^{ [self setResponseString:_request.responseString]; [[MyAppDelegate getQueue] addOperation:_operation]; }]; In order to avoid the following warning: Capturing "self" strongly in this

I have those methods to retrieve some object information from the internet: - (void)downloadAppInfo:(void(^)())success failure:(void(^)(NSError *error))failure; - (void)getAvailableHosts:(void(^)())success failure:(void(^)(NSError *error))failure; - (void)getAvailableServices:(void(^)())success failure:(void(^)(NSError *error))failure; - (void)getAvailableActions:(void(^)())success failure:(void(^)(NSError *error))failure; The downloaded stuff gets stored in object properties, so that is why the success functions return nothing. Now, I want to have one method like this: - (void)syncEverything: