Block-based interface to the iOS SDK's REST API.

[jhersh]

I wrote a new block-based interface for issuing and receiving responses to REST requests sent through the iOS SDK. It's contained within a new Blocks category on SFRestAPI.

The block methods exposed here should follow exactly the methods defined in SFRestAPI with one exception: my version of requestForRetrieveWithObjectType:objectId:fieldList: takes an NSArray instead of a comma-separated NSString for the fieldList. My version performs the comma-separation automatically and also eliminates duplicate fields specified in the array.

Using a block method to describe global:

    completeBlock:^(NSDictionary *results) {
        NSLog(@"results %@", results);
    }];

Or to run a query:

failBlock:nil 
completeBlock:^(NSDictionary *results) {
        NSLog(@"results %@", results);
    }];

[khawkins]

Hey Jonathan, what's the significance of the 'V' in the 'SFV' prefix that you're using?

[khawkins]

In addition to unit tests, we'll want to add AppleDoc-formatted documentation for all public members/interfaces.

[jhersh]

Just refactored the block methods to use a category and eliminate the need for a singleton. Should hopefully reduce unit test requirements too.

SFV = Salesforce Viewer. It was named as such because this originally started as something I wrote for myself for use in SFV. :) This latest refactoring removes any references to SFV.

[khawkins]

Ah, Salesforce Viewer. It's all clear to me now. :)

[NachoMan]

You might want to return the request that was created, instead of (void). That way you have a way to cancel the operation if necessary.

[jhersh]

Unit tests and docs should now be in place. How's it all looking?

[khawkins]

It's looking pretty good; I'm still poking through some of the details. One of the things I think would be good would be to change the SFV prefix on the block types, just because it doesn't have any particular context in this case.

[jhersh]

Whoops, right you are. Should be fixed now

[khawkins]

There are some compile-time errors in the unit tests. If you "Build for Testing", you'll see them; they're all pretty straightforward to fix, I think.

[khawkins]

This is looking good to me. Unit tests are passing. @tstellanova-sfdc did you have any further comments/suggestions/scrutinies?

[tstellanova-sfdc]

Test coverage is looking good. I'll merge these changes in and then see about adding tests for cancel and timeout.

Thanks for the contribution!