4 ms·

I was hoping to see an integrated completion and error block as I tend to wrap AFNetworking calls to achieve exactly that. I'm sure everyone has their preferenc

I was hoping to see an integrated completion and error block as I tend to wrap AFNetworking calls to achieve exactly that. I'm sure everyone has their preference but I really like getting everything back in one callback and being able to check for a non-nil error object to handle things accordingly. I do like the idea of something simpler than AFNetworking though. While AFNetworking is a great library it feels a bit too complex for what it's doing at times. Depending on whether or not I need RestKit in the next project I do I might use this instead of AFNetworking. Thanks for sharing this.

eunoia 12y ago
I too always end up wrapping AFNetworking calls with an integrated (error, response) block. I think another wonderful addition would be a client side router to match response serializers with request urls.
gbrhaz 12y ago
100% yes regarding a single completion/error block. Blocks are verbose at the best of times, and I find having two in the same method is a pain to look at. If there's an error, it's not nil, sorted.
- matttthompson 12y ago
  Nothing in AFNetworking forces a success/failure block. For request operations, `completionBlock` can be set directly. For session tasks, the parameter is a `completionHandler`.
BSousa 12y ago
Since Apple advises not to use the error variable for checking for an error, but the return value, I think the decision to have both blocks suits the Obj-C patterns a bit more: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html https://developer.apple.com/library/mac/documentation/Cocoa/... (first Important block just down the page)
- mbenjaminsmith 12y ago
  I appreciate that. I had never seen that. Of course I've never seen a case where checking for an NSError object failed either. > Although Cocoa methods that indirectly return error objects in the Cocoa error domain are guaranteed to return such objects if the method indicates failure by directly returning nil or NO, you should always check that the return value is nil or NO before attempting to do anything with the NSError object. I wish it were a little bit less cryptic. If it's guaranteed then it's guaranteed, no? Is it possible to get a non-nil error object even after a successful call? Is it possible to have the opposite happen? Makes very little sense. [Edited]
  - jurip 12y ago
    Yeah, that's really badly worded. What it's trying to say is that if a Cocoa method has a NSError parameter, it will indicate error state by nil/NO return value. It doesn't say anything about the value of the NSError if the return value is not nil/NO. So for example you could have the out parameter pointing at an existing NSError* at it's possible it will still point there if everything went ok.
    - mbenjaminsmith 12y ago
      I get what you're saying, thanks. I wouldn't ever do that personally, so I guess it's moot.
- jurip 12y ago
  That page doesn't mention blocks at all, though. Apple themselves use the (id value, NSError *error) completion block style with NSURLSession: https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSURLSession_class/Introduction/Introduction.html#//apple_ref/occ/instm/NSURLSession/dataTaskWithURL:completionHandler%3A https://developer.apple.com/library/ios/documentation/Founda... It makes sense with blocks where you have actual multiple values you can pass in without futzing with pointers to pointers.
  - mbenjaminsmith 12y ago

eunoia 12y ago

I too always end up wrapping AFNetworking calls with an integrated (error, response) block. I think another wonderful addition would be a client side router to match response serializers with request urls.

gbrhaz 12y ago

100% yes regarding a single completion/error block. Blocks are verbose at the best of times, and I find having two in the same method is a pain to look at. If there's an error, it's not nil, sorted.

matttthompson 12y ago
Nothing in AFNetworking forces a success/failure block. For request operations, `completionBlock` can be set directly. For session tasks, the parameter is a `completionHandler`.

BSousa 12y ago

Since Apple advises not to use the error variable for checking for an error, but the return value, I think the decision to have both blocks suits the Obj-C patterns a bit more: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html https://developer.apple.com/library/mac/documentation/Cocoa/... (first Important block just down the page)

mbenjaminsmith 12y ago
I appreciate that. I had never seen that. Of course I've never seen a case where checking for an NSError object failed either. > Although Cocoa methods that indirectly return error objects in the Cocoa error domain are guaranteed to return such objects if the method indicates failure by directly returning nil or NO, you should always check that the return value is nil or NO before attempting to do anything with the NSError object. I wish it were a little bit less cryptic. If it's guaranteed then it's guaranteed, no? Is it possible to get a non-nil error object even after a successful call? Is it possible to have the opposite happen? Makes very little sense. [Edited]
- jurip 12y ago
  Yeah, that's really badly worded. What it's trying to say is that if a Cocoa method has a NSError parameter, it will indicate error state by nil/NO return value. It doesn't say anything about the value of the NSError if the return value is not nil/NO. So for example you could have the out parameter pointing at an existing NSError* at it's possible it will still point there if everything went ok.
  - mbenjaminsmith 12y ago
    I get what you're saying, thanks. I wouldn't ever do that personally, so I guess it's moot.
jurip 12y ago
That page doesn't mention blocks at all, though. Apple themselves use the (id value, NSError *error) completion block style with NSURLSession: https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSURLSession_class/Introduction/Introduction.html#//apple_ref/occ/instm/NSURLSession/dataTaskWithURL:completionHandler%3A https://developer.apple.com/library/ios/documentation/Founda... It makes sense with blocks where you have actual multiple values you can pass in without futzing with pointers to pointers.
- mbenjaminsmith 12y ago