Return a value from a block - ios

I have been reading up on Objectice-C blocks as I have been running into them more and more lately. I have been able to solve most of my asynchronous block execution problems, however I have found one that I cannot seem to fix. I thought about making an __block BOOL for what to return, but I know that the return statement at the end of the method will be executed before the block is finished running. I also know that I cannot return a value inside the block.
- (BOOL)shouldPerformSegueWithIdentifier:(NSString *)identifier sender:(id)sender {
if ([identifier isEqualToString:#"Reminder Segue"]) {
eventStore = [[EKEventStore alloc] init];
[eventStore requestAccessToEntityType:EKEntityTypeReminder completion:^(BOOL granted, NSError *error) {
if (!granted) {
UIAlertView *remindersNotEnabledAlert;
remindersNotEnabledAlert = [[UIAlertView alloc] initWithTitle:#"Reminders Not Enabled" message:#"In order for the watering reminder feature to function, please allow reminders for the app under the Privacy menu in the Settings app." delegate:self cancelButtonTitle:#"OK" otherButtonTitles:nil, nil];
//I would like to put a simple return NO statement here, but I know it is impossible
}
}];
}
return YES;
}
How do I create a simple return statement from a block?

While the immediate idea might be to make your asynchronous request synchronous, that's rarely a good idea, and do to so in the middle of a segue, such as this case, is likely to be problematic. It's almost never a good idea to try to make an asynchronous method synchronous.
And, as smyrgl points out, the idea of "can't I just return a value from the block" is intuitively attractive, but while you can define your own blocks that return values (as Duncan points out), you cannot change the behavior of requestAccessToEntityType such that it returns a value in that manner. It's inherent in its asynchronous pattern that you have to act upon the grant state within the block, not after the block.
So, instead, I would suggest a refactoring of this code. I would suggest that you remove the segue (which is likely being initiated from a control in the "from" scene) and not try to rely upon shouldPerformSegueWithIdentifier to determine whether the segue can be performed as a result of a call to this asynchronous method.
Instead, I would completely remove that existing segue and replace it with an IBAction method that programmatically initiates a segue based upon the result of requestAccessToEntityType. Thus:
Remove the segue from the button (or whatever) to the next scene and remove this shouldPerformSegueWithIdentifier method;
Create a new segue between the view controllers themselves (not from any control in the "from" scene, but rather between the view controllers themselves) and give this segue a storyboard ID (for example, see the screen snapshots here or here);
Connect the control to an IBAction method, in which you perform this requestAccessToEntityType, and if granted, you will then perform this segue, otherwise present the appropriate warning.
Thus, it might look something like:
- (IBAction)didTouchUpInsideButton:(id)sender
{
eventStore = [[EKEventStore alloc] init];
[eventStore requestAccessToEntityType:EKEntityTypeReminder completion:^(BOOL granted, NSError *error) {
// by the way, this completion block is not run on the main queue, so
// given that you want to do UI interaction, make sure to dispatch it
// to the main queue
dispatch_async(dispatch_get_main_queue(), ^{
if (granted) {
[self performSegueWithIdentifier:kSegueToNextScreenIdentifier sender:self];
} else {
UIAlertView *remindersNotEnabledAlert;
remindersNotEnabledAlert = [[UIAlertView alloc] initWithTitle:#"Reminders Not Enabled" message:#"In order for the watering reminder feature to function, please allow reminders for the app under the Privacy menu in the Settings app." delegate:nil cancelButtonTitle:#"OK" otherButtonTitles:nil];
[remindersNotEnabledAlert show];
}
});
}];
}

You CAN return a value from a block, just like from any function or method. However, returning a value from a completion block on an async method does not make sense. That's because the block doesn't get called until after the method finishes running at some later date, and by then, there is no place to return a result. The completion method gets called asynchronously.
In order to make a block return a value you need to define the block as a type that does return a value, just like you have to define a method that returns a value.
Blocks are a bit odd in that the return value is assumed to be void if it's not specified.
An example of a block that returns a value is the block used in the NSArray method indexOfObjectPassingTest. The signature of that block looks like this:
(BOOL (^)(id obj, NSUInteger idx, BOOL *stop))predicate
The block returns a BOOL. It takes an object, an integer, and a pointer to a BOOL as parameters. When you write a block of code using this method, your code gets called repeatedly for each object in the array, and when you find the object that matches whatever test you are doing, you return TRUE.

If you really want to make a block synchronous (although I question the validity of doing so) your best bet is to use a dispatch_semaphore. You can do it like this:
dispatch_semaphore_t mySemaphore = dispatch_semaphore_create(0);
__block BOOL success;
[eventStore requestAccessToEntityType:EKEntityTypeReminder completion:^(BOOL granted, NSError *error) {
success = granted;
dispatch_semaphore_signal(mySemaphore);
}];
dispatch_semaphore_wait(mySemaphore, DISPATCH_TIME_FOREVER);
However again I don't think you want to do this, especially in a segue as it will stall the UI. Your better bet is to rearchitect what you are doing so that you don't have a dependency on the async process being completed in order to continue.

Related

NSURLConnection does not call complete across multiple Views

Earlier today I asked the following question: iOS block being stoped when view pushed
The operation I mentioned (OP1) is actually a "http get" to my server, using NSURLConnection.
After even more investigation I discovered that the block doesn't actually "die". What really happens is that the request is actually SENT (the server side logs it), even after the view is pushed (verified via [NSThread sleep:10]). The server responds but then NOTHING happens on the app side if the view2 has been pushed! almost as if the connection had lost its delegate! Another possibility im looking at is "the fact that NSURLConnection is on the rsMainLoop related?"
Can anyone help?
Pls don't forget that:
0. Everything works fine as long as the view2 is not pushed until operation completion.
1. The request is sent async
2. I set the delegate and it works as long as the view dont change
3. view1 starts the operation using the "singleton object reference" property "OP1Completed"
4. view2 checks the completion of OP1 via propertie on the "singleton object reference"
5. view2 gets the "result" by going to the "singleton.OP1Result" property
Edit 1:
Ok lets have some code. First here is the relevant code of my singleton (named "Interaction"):
-(void)loadAllContextsForUser:(NSString *)username{
userNameAux = username;
_loadingContextsCompleted = NO;
if (contextsLoaderQueue == NULL) {
contextsLoaderQueue = dispatch_queue_create("contextsLoaderQueue", NULL);
}
dispatch_async(contextsLoaderQueue, ^{
NSLog(#"Loading all contexts block started");
[self requestConnectivity];
dispatch_async(dispatch_get_main_queue(), ^{
[Util Get:[NSString stringWithFormat:#"%#/userContext?username=%#", Util.azureBaseUrl, [username stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]]
successBlock:^(NSData *data, id jsonData){
NSLog(#"Loading all contexts block succeeded");
if([userNameAux isEqualToString:username]){
_allContextsForCurrentUser = [[NSSet alloc]initWithArray: jsonData];
}
} errorBlock:^(NSError *error){
NSLog(#"%#",error);
} completeBlock:^{
NSLog(#"load all contexts for user async block completed.");
_loadingContextsCompleted = YES;
[self releaseConnectivity];
}];
});
while (!_loadingContextsCompleted) {
NSLog(#"loading all contexts block waiting.");
[NSThread sleepForTimeInterval:.5];
}
});
NSLog(#"Load All Contexts Dispatched. It should start at any moment if it not already.");
}
And here is the class Util, which actually handles the request/response
-(id)initGet:(NSString *)resourceURL successBlock:(successBlock_t)successBlock errorBlock:(errorBlock_t)errorBlock completeBlock:(completeBlock_t)completeBlock;{
if(self=[super init]){
_data=[[NSMutableData alloc]init];
}
_successBlock = [successBlock copy];
_completeBlock = [completeBlock copy];
_errorBlock = [errorBlock copy];
NSURL *url = [NSURL URLWithString:resourceURL];
NSMutableURLRequest *request = [NSURLRequest requestWithURL:url];
[[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];
//[_conn scheduleInRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
//[_conn start];
NSLog(#"Request Started.");
return self;
}
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response
{
[_data setLength:0];
}
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
[_data appendData:data];
}
- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
id jsonObjects = [NSJSONSerialization JSONObjectWithData:_data options:NSJSONReadingMutableContainers error:nil];
id key = [[jsonObjects allKeys] objectAtIndex:0];
id jsonResult = [jsonObjects objectForKey:key];
_successBlock(_data, jsonResult);
_completeBlock();
}
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
_errorBlock(error);
_completeBlock();
}
And finally here is the relevant part VC1 (pushing in VC2)
- (IBAction)loginClicked {
NSLog(#"login clicked. Preparing to exibit next view");
UIStoryboard *storyboard = [UIStoryboard storyboardWithName:#"MainStoryboard_iPhone" bundle:nil];
AuthenticationViewController *viewController = (AuthenticationViewController *)[storyboard instantiateViewControllerWithIdentifier:#"ContextSelectionView"];
NSLog(#"Preparation completed. pushing view now");
[self presentViewController:viewController animated:YES completion:nil];
}
You might be surprised, but there are a couple of solutions - some of which are very common and can be implemented very easily ;) Even though, this answer is ridiculous elaborate, the actual solution to your problem will not exceed a few lines of code. :)
You ran into a typical "async problem" - well, it's less than a problem, rather a typical programming task nowadays.
What you have is an asynchronous task, OP1. This will be started from within ViewController 1 (VC1), and at some indeterminate time later, it will eventually produce either a result or an error.
The eventual result of OP1 should be handled later in VC2.
There are a few approaches how a client can obtain the eventual result, for example: via KVO, delegate method, completion block, callback function, future or promise and per notification.
These approaches above have one property in common: the call-site gets notified by the asynchronous result provider (and not vice versa).
Polling for the result until it is available, is a bad approach. Likewse, hanging in a semaphore and blocking the current thread until the result is "signaled" is equally suboptimal.
You are probably familiar with completion blocks. A typical asynchronous method which notifies the call-site when the result is available looks like this:
typedef void (^completion_block_t)(id result);
- (void) doSomethingAsyncWithCompletion:(completion_block_t)completionHandler;
Note: the call-site provides the completion handler, while the async tasks calls the block when it is finished, and passes its result (or error) to the result parameter of the block. Unless otherwise stated, the execution context - that is the thread or dispatch queue or NSOperationQueue - of where the block will be executed is not known.
But when thinking about your problem, a simple async function and a completion handler doesn't yield a viable solution. You cannot pass that "method" easily from VC1 to VC2 and then later "attach" somehow a completion block in VC2.
Luckily, any asynchronous task can be encapsulated into an NSOperation. An NSOperation has a completion block as a property which can be set by the call-site or elsewhere. And an NSOperation object can be easily passed from VC1 to VC2. VC2 simply adds a completion block to the operation, and eventually gets notified when its finished and the result is available.
However, while this would be a viable solution for your problem - there are in fact a few issues with this approach - which I don't want to elaborate, but instead propose an even better one: "Promises".
A "Promise" represents the eventual result of an asynchronous task. That is, a promise will exist even though the result of the asynchronous task is not yet evaluated. A Promise is an ordinary object which you can send messages. Thus, Promises can be passed around much like NSOperations. A Promise is the return value of an asynchronous method/function:
-(Promise*) doSomethingAsync;
Don't mismatch a Promise with the asynchronous function/method/task/operation - the promise is just a representation of the eventual result of the task.
A Promise MUST be eventually resolved by the asynchronous task - that is, the task MUST send the promise a "fulfill" message along with the result value, or it MUST send the promise the "reject" message along with an error. The promise keeps a reference of that result value passed from the task.
A Promise can be resolved only once!
In order to obtain the eventual result a client can "register" a success handler and an error handler . The success handler will be called when the task fulfills the promise (that is, it was successful), and the error handler will be called when the task rejected the promise passing along the reason as an error object.
Assuming a particular implementation of a promise, resolving a promise may look like this:
- (Promise*) task {
Promise* promise = [Promise new];
dispatch_async(private_queue, ^{
...
if (success) {
[promise fulfillWithValue:result];
}
else {
NSError* error = ...;
[promise rejectWithReason:error];
}
});
return promise;
}
A client "registers" handlers for obtaining the eventual result as follows:
Promise* promise = [self fetchUsers];
promise.then( <success handler block>, <error handler block> );
The success handler and error handler block are declared as follows:
typedef id (^success_handler_block)(id result);
typedef id (^error_handler_block)(NSError* error);
In order to just "register" a success handler (for the case, the async tasks "returns" successfully) one would write:
promise.then(^id(id users) {
NSLog(#"Users:", users);
return nil;
}, nil);
If the task succeeds, the handler will be called - which prints the users to the console.
When the task fails, the success handler will not be called.
In order to just "register" an error handler (for the case, the async tasks fails) one would write:
promise.then(nil, ^id(NSError* error) {
NSLog(#"ERROR:", error);
return nil;
}, nil);
If the task succeeds, the error handler will not be called. Only if the task fails (or any children tasks), this error handler will be invoked.
When the result of the async task is eventually available, the code within the handlers will be executed "in some unspecified execution context". That means, it may execute on any thread. (Note: there are ways to specify the execution context, say the main thread).
A promise can register more than one handler pair. You can add as many handlers as you want, and where and when you want. Now, you should understand the connection with your actual problem:
You can start an asynchronous task in VC1, and get a promise. Then pass this promise to VC2. In VC2 you can add your handler, which will get invoked when the result is eventually available.
Don't worry when the result is actually already available when passing the promise to VC2, that is, when the promise has been resolved already. You can still add handlers and they get fired properly (immediately).
You can also "chain" multiple tasks - that is, invoke task2 once when task1 is finished. A "chain" or "continuation" of four async tasks looks as follows:
Promise* task4Promise =
[self task1]
.then(^id(id result1){
return [task2WithInput:result1];
}, nil)
.then(^id(id result2){
return [task3WithInput:result2];
}, nil)
.then(^id(id result3){
return [task4WithInput:result3];
}, nil);
task4Promise represents the eventual result of task4WithInput:.
One can also execute tasks in parallel, like taskB and taskC which will get started in parallel when taskA has been finished successfully:
Promise* root = [self taskA];
root.then(^id(id result){
return [self taskB];
}, nil);
root.then(^id(id result){
return [self taskC];
}, nil);
With this scheme, one can define an acyclic graph of tasks, where each is dependent on the successful execution of its successor ("parent"). "Errors" will be passed through to the root, and handled by the last error handler (if any).
There are a few implementations for Objective-C. I've written one myself: "RXPromise" (available on GitHub). One of the strongest feature is "Cancellation" - which is NOT a standard feature of promises, but implemented in RXPromise. With this, you can selectively cancel a tree of asynchronous tasks.
There is a lot more about promises. You may search the web, especially in the JavaScript community.
I'm not sure I understand the work flow that goes on in the first controller -- specifically, what the user does to initiate the download, and what else he does before the next controller gets presented (and when that controller gets instantiated). When I've made apps in the past that required doing downloads from multiple classes, I've created a download class that creates the NSURLConnection, and implements all the call backs. It has one delegate protocol method to send back the data (either raw data or error object) to its delegate.
I made a simple test case simulating what I think your work flow is, using two buttons. One instantiates a Downloader class instance, creates the next controller, sets it as the delegate of the downloader, and starts the download. The second button does the push to that second controller. This works, no matter when the push happens, but I don't know if it's relevant to your situation (I test using the Network Link Conditioner to simulate a slow connection).
The first Controller:
#import "ViewController.h"
#import "ReceivingViewController.h"
#import "Downloader.h"
#interface ViewController ()
#property (strong,nonatomic) ReceivingViewController *receiver;
#end
#implementation ViewController
-(IBAction)buttonClicked:(id)sender {
Downloader *loader = [Downloader new];
self.receiver = [self.storyboard instantiateViewControllerWithIdentifier:#"Receiver"];
loader.delegate = self.receiver;
[loader startLoad];
}
-(IBAction)goToReceiver:(id)sender {
[self.navigationController pushViewController:self.receiver animated:YES];
}
The Download class .h:
#protocol DownloadCompleted <NSObject>
-(void)downloadedFinished:(id) dataOrError;
#end
#interface Downloader : NSObject
#property (strong,nonatomic) NSMutableData *receivedData;
#property (weak,nonatomic) id <DownloadCompleted> delegate;
-(void)startLoad;
Downloader .m:
-(void)startLoad {
NSLog(#"start");
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:#"http://www.google.com"] cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:10];
NSURLConnection *connection = [NSURLConnection connectionWithRequest:request delegate:self];
if (connection) self.receivedData = [NSMutableData new];
}
-(void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response {
self.receivedData.length = 0;
}
-(void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
[self.receivedData appendData:data];
}
-(void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
[self.delegate downloadedFinished:error];
}
-(void)connectionDidFinishLoading:(NSURLConnection *)connection {
[self.delegate downloadedFinished:self.receivedData];
}
-(void)dealloc {
NSLog(#"In Downloader dealloc. loader is: %#",self);
}
The second controller:
#interface ReceivingViewController ()
#property (strong,nonatomic) NSData *theData;
#end
#implementation ReceivingViewController
-(void)downloadedFinished:(id)dataOrError {
self.theData = (NSData *)dataOrError;
NSLog(#"%#",self.theData);
}
-(void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
NSLog(#"%#",self.theData);
}
So, here is what I think will work for sure:
Pass the flag to the new controller. If the flag is unfinished, then start over loading in the new VC and make sure none of the data shows up until it is done loading.
I do think it is weird that the thread stops though, with the new VC being pushed, because when I dispatch asynchronous calls with AFNetworking, it does continue to load even after a new VC is pushed. Perhaps if you are using a different framework, you should use AFNetworking.
So, if your thread actually does continue after the new VC is pushed on (as I suspect it does - you just think it doesn't keep going because it crashes the code), then try the following:
a) pass flag, if operation finished, proceed normally
b) if not, don't load anything and invoke some kind of delegate method between the two that checks if the flag is set, and returns the data if so.
If you have questions on how to set up a delegate, just ask and I can fill in some details on that.
As already mentioned in a comment in you first question: you have probably two issues:
A design problem
A code issue, causing the block. (but without code this is difficult to figure out).
Lets propose a practical approach:
Say, our singleton is some "Loader" class which performs HTTP requests. Instead of polling a property which determines the state of the network request, you should return some object which you can ask for the state, or even better where VC2 can register a completion block which gets called when the request is finished.
An NSOperation could be "used" to represent the eventual result of the asynchronous network request. But this is a bit unwieldy - suppose we have a subclass RequestOperation:
RequestOperation* requestOp = [[Loader sharedLoader] fetchWithURL:url];
Now, "requestOp" represents your network request, including the eventual result.
You can obtain this operation in VC1.
You may not want to ask the shared loader about a particular operation, because it may stateless -- that is, it does not itself track the request operations. Consider, you want to use class Loader several times for starting network requests - possible in parallel. Then, which request do you mean when you ask one property of Loader which tells you something about the state of a request? (it won't work).
So, again back to a working approach and to VC1:
Suppose, in VC1 you obtained the RequestOperation object which is a subclass of NSOperation. Suppose, RequestOperation has a property responseBody - which is a NSData object representing the eventual response data of the request operation.
In order to obtain the eventual response body of the request, you cannot just ask the property: the connection could possibly still running - the you would get nil or garbage, or you might block the thread. The behavior is dependent on the implementation of RequestOperation.
The solution is as follows:
In VC2:
We assume, VC1 has "passed" the requestOp to VC2 (for example in prepareForSegue:sender:).
In order to retrieve the response body in an asynchronous correct manner, you need some extra steps:
Create a NSBlockOperation which executes a block which handles the response body, for example:
NSBlockOperation* handlerOp = [NSBlockOperation blockOperationWithBlock:^{
NSData* body = requestOp.responseBody;
dispatch_async(dispatch_get_main_queue(), ^{
self.model = body;
[self.tableView reloadData];
});
}];
Then, make the handlerOp dependent on the requestOp - that is, start executing handlerOp when requestOp finished:
[handlerOP addDependency:requestOp];
Add the handlerOp to a queue, in order to execute:
[[NSOperation mainQueue] addOperation:handlerOp];
This still requires you to think "asynchronously" - there is no way around this. The best is, to get used to the practical patterns and idioms.
An alternative approach is using RXPromise (from a third party library):
In VC1:
requestPromise = [Loader fetchWithURL:url];
Now, in VC2:
We assume, VC1 has "passed" the requestPromise to VC2 (for example in prepareForSegue:sender:).
For example in viewDidLoad:
requestPromise.thenOn(dispatch_get_main_queue(), ^id(id responseBody){
// executes on main thread!
self.model = responseBody;
[self.tableView reloadData];
return nil;
}, nil);
Bonus:
If required, you can cancel the network request at any time through sending cancel to the promise:
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.requestPromise cancel];
self.requestPromise = nil;
}
I've figured it out. In my second view (where i w8 for the operation complete) I cannot w8 using ThreadSleep! I have to use [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

iOS block being stoped when view pushed [duplicate]

Earlier today I asked the following question: iOS block being stoped when view pushed
The operation I mentioned (OP1) is actually a "http get" to my server, using NSURLConnection.
After even more investigation I discovered that the block doesn't actually "die". What really happens is that the request is actually SENT (the server side logs it), even after the view is pushed (verified via [NSThread sleep:10]). The server responds but then NOTHING happens on the app side if the view2 has been pushed! almost as if the connection had lost its delegate! Another possibility im looking at is "the fact that NSURLConnection is on the rsMainLoop related?"
Can anyone help?
Pls don't forget that:
0. Everything works fine as long as the view2 is not pushed until operation completion.
1. The request is sent async
2. I set the delegate and it works as long as the view dont change
3. view1 starts the operation using the "singleton object reference" property "OP1Completed"
4. view2 checks the completion of OP1 via propertie on the "singleton object reference"
5. view2 gets the "result" by going to the "singleton.OP1Result" property
Edit 1:
Ok lets have some code. First here is the relevant code of my singleton (named "Interaction"):
-(void)loadAllContextsForUser:(NSString *)username{
userNameAux = username;
_loadingContextsCompleted = NO;
if (contextsLoaderQueue == NULL) {
contextsLoaderQueue = dispatch_queue_create("contextsLoaderQueue", NULL);
}
dispatch_async(contextsLoaderQueue, ^{
NSLog(#"Loading all contexts block started");
[self requestConnectivity];
dispatch_async(dispatch_get_main_queue(), ^{
[Util Get:[NSString stringWithFormat:#"%#/userContext?username=%#", Util.azureBaseUrl, [username stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]]
successBlock:^(NSData *data, id jsonData){
NSLog(#"Loading all contexts block succeeded");
if([userNameAux isEqualToString:username]){
_allContextsForCurrentUser = [[NSSet alloc]initWithArray: jsonData];
}
} errorBlock:^(NSError *error){
NSLog(#"%#",error);
} completeBlock:^{
NSLog(#"load all contexts for user async block completed.");
_loadingContextsCompleted = YES;
[self releaseConnectivity];
}];
});
while (!_loadingContextsCompleted) {
NSLog(#"loading all contexts block waiting.");
[NSThread sleepForTimeInterval:.5];
}
});
NSLog(#"Load All Contexts Dispatched. It should start at any moment if it not already.");
}
And here is the class Util, which actually handles the request/response
-(id)initGet:(NSString *)resourceURL successBlock:(successBlock_t)successBlock errorBlock:(errorBlock_t)errorBlock completeBlock:(completeBlock_t)completeBlock;{
if(self=[super init]){
_data=[[NSMutableData alloc]init];
}
_successBlock = [successBlock copy];
_completeBlock = [completeBlock copy];
_errorBlock = [errorBlock copy];
NSURL *url = [NSURL URLWithString:resourceURL];
NSMutableURLRequest *request = [NSURLRequest requestWithURL:url];
[[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];
//[_conn scheduleInRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
//[_conn start];
NSLog(#"Request Started.");
return self;
}
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response
{
[_data setLength:0];
}
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
[_data appendData:data];
}
- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
id jsonObjects = [NSJSONSerialization JSONObjectWithData:_data options:NSJSONReadingMutableContainers error:nil];
id key = [[jsonObjects allKeys] objectAtIndex:0];
id jsonResult = [jsonObjects objectForKey:key];
_successBlock(_data, jsonResult);
_completeBlock();
}
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
_errorBlock(error);
_completeBlock();
}
And finally here is the relevant part VC1 (pushing in VC2)
- (IBAction)loginClicked {
NSLog(#"login clicked. Preparing to exibit next view");
UIStoryboard *storyboard = [UIStoryboard storyboardWithName:#"MainStoryboard_iPhone" bundle:nil];
AuthenticationViewController *viewController = (AuthenticationViewController *)[storyboard instantiateViewControllerWithIdentifier:#"ContextSelectionView"];
NSLog(#"Preparation completed. pushing view now");
[self presentViewController:viewController animated:YES completion:nil];
}
You might be surprised, but there are a couple of solutions - some of which are very common and can be implemented very easily ;) Even though, this answer is ridiculous elaborate, the actual solution to your problem will not exceed a few lines of code. :)
You ran into a typical "async problem" - well, it's less than a problem, rather a typical programming task nowadays.
What you have is an asynchronous task, OP1. This will be started from within ViewController 1 (VC1), and at some indeterminate time later, it will eventually produce either a result or an error.
The eventual result of OP1 should be handled later in VC2.
There are a few approaches how a client can obtain the eventual result, for example: via KVO, delegate method, completion block, callback function, future or promise and per notification.
These approaches above have one property in common: the call-site gets notified by the asynchronous result provider (and not vice versa).
Polling for the result until it is available, is a bad approach. Likewse, hanging in a semaphore and blocking the current thread until the result is "signaled" is equally suboptimal.
You are probably familiar with completion blocks. A typical asynchronous method which notifies the call-site when the result is available looks like this:
typedef void (^completion_block_t)(id result);
- (void) doSomethingAsyncWithCompletion:(completion_block_t)completionHandler;
Note: the call-site provides the completion handler, while the async tasks calls the block when it is finished, and passes its result (or error) to the result parameter of the block. Unless otherwise stated, the execution context - that is the thread or dispatch queue or NSOperationQueue - of where the block will be executed is not known.
But when thinking about your problem, a simple async function and a completion handler doesn't yield a viable solution. You cannot pass that "method" easily from VC1 to VC2 and then later "attach" somehow a completion block in VC2.
Luckily, any asynchronous task can be encapsulated into an NSOperation. An NSOperation has a completion block as a property which can be set by the call-site or elsewhere. And an NSOperation object can be easily passed from VC1 to VC2. VC2 simply adds a completion block to the operation, and eventually gets notified when its finished and the result is available.
However, while this would be a viable solution for your problem - there are in fact a few issues with this approach - which I don't want to elaborate, but instead propose an even better one: "Promises".
A "Promise" represents the eventual result of an asynchronous task. That is, a promise will exist even though the result of the asynchronous task is not yet evaluated. A Promise is an ordinary object which you can send messages. Thus, Promises can be passed around much like NSOperations. A Promise is the return value of an asynchronous method/function:
-(Promise*) doSomethingAsync;
Don't mismatch a Promise with the asynchronous function/method/task/operation - the promise is just a representation of the eventual result of the task.
A Promise MUST be eventually resolved by the asynchronous task - that is, the task MUST send the promise a "fulfill" message along with the result value, or it MUST send the promise the "reject" message along with an error. The promise keeps a reference of that result value passed from the task.
A Promise can be resolved only once!
In order to obtain the eventual result a client can "register" a success handler and an error handler . The success handler will be called when the task fulfills the promise (that is, it was successful), and the error handler will be called when the task rejected the promise passing along the reason as an error object.
Assuming a particular implementation of a promise, resolving a promise may look like this:
- (Promise*) task {
Promise* promise = [Promise new];
dispatch_async(private_queue, ^{
...
if (success) {
[promise fulfillWithValue:result];
}
else {
NSError* error = ...;
[promise rejectWithReason:error];
}
});
return promise;
}
A client "registers" handlers for obtaining the eventual result as follows:
Promise* promise = [self fetchUsers];
promise.then( <success handler block>, <error handler block> );
The success handler and error handler block are declared as follows:
typedef id (^success_handler_block)(id result);
typedef id (^error_handler_block)(NSError* error);
In order to just "register" a success handler (for the case, the async tasks "returns" successfully) one would write:
promise.then(^id(id users) {
NSLog(#"Users:", users);
return nil;
}, nil);
If the task succeeds, the handler will be called - which prints the users to the console.
When the task fails, the success handler will not be called.
In order to just "register" an error handler (for the case, the async tasks fails) one would write:
promise.then(nil, ^id(NSError* error) {
NSLog(#"ERROR:", error);
return nil;
}, nil);
If the task succeeds, the error handler will not be called. Only if the task fails (or any children tasks), this error handler will be invoked.
When the result of the async task is eventually available, the code within the handlers will be executed "in some unspecified execution context". That means, it may execute on any thread. (Note: there are ways to specify the execution context, say the main thread).
A promise can register more than one handler pair. You can add as many handlers as you want, and where and when you want. Now, you should understand the connection with your actual problem:
You can start an asynchronous task in VC1, and get a promise. Then pass this promise to VC2. In VC2 you can add your handler, which will get invoked when the result is eventually available.
Don't worry when the result is actually already available when passing the promise to VC2, that is, when the promise has been resolved already. You can still add handlers and they get fired properly (immediately).
You can also "chain" multiple tasks - that is, invoke task2 once when task1 is finished. A "chain" or "continuation" of four async tasks looks as follows:
Promise* task4Promise =
[self task1]
.then(^id(id result1){
return [task2WithInput:result1];
}, nil)
.then(^id(id result2){
return [task3WithInput:result2];
}, nil)
.then(^id(id result3){
return [task4WithInput:result3];
}, nil);
task4Promise represents the eventual result of task4WithInput:.
One can also execute tasks in parallel, like taskB and taskC which will get started in parallel when taskA has been finished successfully:
Promise* root = [self taskA];
root.then(^id(id result){
return [self taskB];
}, nil);
root.then(^id(id result){
return [self taskC];
}, nil);
With this scheme, one can define an acyclic graph of tasks, where each is dependent on the successful execution of its successor ("parent"). "Errors" will be passed through to the root, and handled by the last error handler (if any).
There are a few implementations for Objective-C. I've written one myself: "RXPromise" (available on GitHub). One of the strongest feature is "Cancellation" - which is NOT a standard feature of promises, but implemented in RXPromise. With this, you can selectively cancel a tree of asynchronous tasks.
There is a lot more about promises. You may search the web, especially in the JavaScript community.
I'm not sure I understand the work flow that goes on in the first controller -- specifically, what the user does to initiate the download, and what else he does before the next controller gets presented (and when that controller gets instantiated). When I've made apps in the past that required doing downloads from multiple classes, I've created a download class that creates the NSURLConnection, and implements all the call backs. It has one delegate protocol method to send back the data (either raw data or error object) to its delegate.
I made a simple test case simulating what I think your work flow is, using two buttons. One instantiates a Downloader class instance, creates the next controller, sets it as the delegate of the downloader, and starts the download. The second button does the push to that second controller. This works, no matter when the push happens, but I don't know if it's relevant to your situation (I test using the Network Link Conditioner to simulate a slow connection).
The first Controller:
#import "ViewController.h"
#import "ReceivingViewController.h"
#import "Downloader.h"
#interface ViewController ()
#property (strong,nonatomic) ReceivingViewController *receiver;
#end
#implementation ViewController
-(IBAction)buttonClicked:(id)sender {
Downloader *loader = [Downloader new];
self.receiver = [self.storyboard instantiateViewControllerWithIdentifier:#"Receiver"];
loader.delegate = self.receiver;
[loader startLoad];
}
-(IBAction)goToReceiver:(id)sender {
[self.navigationController pushViewController:self.receiver animated:YES];
}
The Download class .h:
#protocol DownloadCompleted <NSObject>
-(void)downloadedFinished:(id) dataOrError;
#end
#interface Downloader : NSObject
#property (strong,nonatomic) NSMutableData *receivedData;
#property (weak,nonatomic) id <DownloadCompleted> delegate;
-(void)startLoad;
Downloader .m:
-(void)startLoad {
NSLog(#"start");
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:#"http://www.google.com"] cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:10];
NSURLConnection *connection = [NSURLConnection connectionWithRequest:request delegate:self];
if (connection) self.receivedData = [NSMutableData new];
}
-(void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response {
self.receivedData.length = 0;
}
-(void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
[self.receivedData appendData:data];
}
-(void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
[self.delegate downloadedFinished:error];
}
-(void)connectionDidFinishLoading:(NSURLConnection *)connection {
[self.delegate downloadedFinished:self.receivedData];
}
-(void)dealloc {
NSLog(#"In Downloader dealloc. loader is: %#",self);
}
The second controller:
#interface ReceivingViewController ()
#property (strong,nonatomic) NSData *theData;
#end
#implementation ReceivingViewController
-(void)downloadedFinished:(id)dataOrError {
self.theData = (NSData *)dataOrError;
NSLog(#"%#",self.theData);
}
-(void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
NSLog(#"%#",self.theData);
}
So, here is what I think will work for sure:
Pass the flag to the new controller. If the flag is unfinished, then start over loading in the new VC and make sure none of the data shows up until it is done loading.
I do think it is weird that the thread stops though, with the new VC being pushed, because when I dispatch asynchronous calls with AFNetworking, it does continue to load even after a new VC is pushed. Perhaps if you are using a different framework, you should use AFNetworking.
So, if your thread actually does continue after the new VC is pushed on (as I suspect it does - you just think it doesn't keep going because it crashes the code), then try the following:
a) pass flag, if operation finished, proceed normally
b) if not, don't load anything and invoke some kind of delegate method between the two that checks if the flag is set, and returns the data if so.
If you have questions on how to set up a delegate, just ask and I can fill in some details on that.
As already mentioned in a comment in you first question: you have probably two issues:
A design problem
A code issue, causing the block. (but without code this is difficult to figure out).
Lets propose a practical approach:
Say, our singleton is some "Loader" class which performs HTTP requests. Instead of polling a property which determines the state of the network request, you should return some object which you can ask for the state, or even better where VC2 can register a completion block which gets called when the request is finished.
An NSOperation could be "used" to represent the eventual result of the asynchronous network request. But this is a bit unwieldy - suppose we have a subclass RequestOperation:
RequestOperation* requestOp = [[Loader sharedLoader] fetchWithURL:url];
Now, "requestOp" represents your network request, including the eventual result.
You can obtain this operation in VC1.
You may not want to ask the shared loader about a particular operation, because it may stateless -- that is, it does not itself track the request operations. Consider, you want to use class Loader several times for starting network requests - possible in parallel. Then, which request do you mean when you ask one property of Loader which tells you something about the state of a request? (it won't work).
So, again back to a working approach and to VC1:
Suppose, in VC1 you obtained the RequestOperation object which is a subclass of NSOperation. Suppose, RequestOperation has a property responseBody - which is a NSData object representing the eventual response data of the request operation.
In order to obtain the eventual response body of the request, you cannot just ask the property: the connection could possibly still running - the you would get nil or garbage, or you might block the thread. The behavior is dependent on the implementation of RequestOperation.
The solution is as follows:
In VC2:
We assume, VC1 has "passed" the requestOp to VC2 (for example in prepareForSegue:sender:).
In order to retrieve the response body in an asynchronous correct manner, you need some extra steps:
Create a NSBlockOperation which executes a block which handles the response body, for example:
NSBlockOperation* handlerOp = [NSBlockOperation blockOperationWithBlock:^{
NSData* body = requestOp.responseBody;
dispatch_async(dispatch_get_main_queue(), ^{
self.model = body;
[self.tableView reloadData];
});
}];
Then, make the handlerOp dependent on the requestOp - that is, start executing handlerOp when requestOp finished:
[handlerOP addDependency:requestOp];
Add the handlerOp to a queue, in order to execute:
[[NSOperation mainQueue] addOperation:handlerOp];
This still requires you to think "asynchronously" - there is no way around this. The best is, to get used to the practical patterns and idioms.
An alternative approach is using RXPromise (from a third party library):
In VC1:
requestPromise = [Loader fetchWithURL:url];
Now, in VC2:
We assume, VC1 has "passed" the requestPromise to VC2 (for example in prepareForSegue:sender:).
For example in viewDidLoad:
requestPromise.thenOn(dispatch_get_main_queue(), ^id(id responseBody){
// executes on main thread!
self.model = responseBody;
[self.tableView reloadData];
return nil;
}, nil);
Bonus:
If required, you can cancel the network request at any time through sending cancel to the promise:
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.requestPromise cancel];
self.requestPromise = nil;
}
I've figured it out. In my second view (where i w8 for the operation complete) I cannot w8 using ThreadSleep! I have to use [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

Use dispatch_async() inside a method or when calling that method

I'm working with some code that downloads data. The code is using blocks as callbacks. There are several download methods with very similar code: In the callback block they show a UIAlertView if something goes wrong. The alert view always looks like this:
[req performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) {
if(error) {
dispatch_async(dispatch_get_main_queue(), ^{
[[NSNotificationCenter defaultCenter] postNotificationName:kFailed object:nil];
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:#"Error"
message:#"Connection failed"
delegate:nil
cancelButtonTitle:#"Ok"
otherButtonTitles:nil];
[alertView show];
});
}
}];
I want to move the alert view code to a method of its own since it's called several times with the same parameters. Should I move the dispatch_async() to the method too, or should I just wrap calls to that method in dispatch_async()?
This has nothing to do with wrong or correct.
Advantage: If you place the dispatch_async() inside the method, you can send the message from every place of your program regardless of the thread you are running in.
Disadvantage: If you place the dispatch_async() inside the method, the code is always executed async even the message is sent from the main thread. (In this case dispatch_async() is simply not necessary and a dispatch_sync() would dead lock.)
And vice versa.
To me something different is more important: Define a layer of "dispatch methods". Only use dispatch_async() and dispatch_sync() inside this layer, not in layers built on top of this, not in layers built underneath this.
From higher levels of your software use always this layer. Inside the layer use only methods on a lower layer.
You can do it either way. Functionally these two blocks of code are the same:
Method 1
//.... Assuming this is called in a block
dispatch_async(dispatch_get_main_queue(), ^{
[self showMyAlertView];
});
- (void) showMyAlertView {
// Show the alert view and other stuff
}
Method 2
//.... Assuming this is also called in your block
[self showMyAlertView];
- (void) showMyAlertView {
dispatch_async(dispatch_get_main_queue(), ^{
// Show the alert view and other stuff
});
}
Obviously the second way requires the fewest lines of code, but if you want to do other stuff asynchronously (besides show your alert view), you might want to do method 1 so you can add other stuff to the queue.
Hope this helped!

Is it possible to perform an API call in a delegate method that returns a BOOL?

Strange title, I know, but here is the quickest way to explain my issue. The Parse service has a prebuilt Sign Up controller for letting new users sign up for whatever service you may have. There is no way to edit it's implementation, you can only handle events in it's delegate methods. So I can't just place this in the IBAction of the "Sign Up" button. What I want to do is, when a user touches "Sign up", is that I need to make a call to some API to check if something exists or not, and then if it does already exist then don't let the user sign up. Here is the delegate method meant to handle validation when the button is pressed:
// Sent to the delegate to determine whether the sign up request should be submitted to the server.
- (BOOL)signUpViewController:(PFSignUpViewController *)signUpController shouldBeginSignUp:(NSDictionary *)info {
Here is what I'm trying to place in it:
[self processJSONDataWithURLString:[NSString stringWithFormat:#"https://www.someapi.com/api/profile.json?username=%#",username] andBlock:^(NSData *jsonData) {
NSDictionary *attributes = [jsonData objectFromJSONData];
// Check to see if username has data key, if so, that means it already exists
if ([attributes objectForKey:#"Data"]) {
return NO; // Do not continue, username already exists
// I've also tried:
dispatch_sync(dispatch_get_main_queue(), ^{ return NO; } );
}
else
return YES; //Continue with sign up
dispatch_sync(dispatch_get_main_queue(), ^{ return YES; } );
}];
I get errors when I try to return anything, though. When I just do a straight return YES, "^(NSData *jsonData)" is underlined in yellow and I get "Incompatible block pointer types sending BOOL (^)NSData *_strong to parameter of type void(^)NSData *_strong".
Basically, in there any way to make an API call in this method to check something and then return YES or NO depending on the result?
Thanks!
No.
You are invoking an asynchronous method that is using the block as a callback. The processJSON… method is invoked and immediately returns from the call. After it runs in the background the block is invoked. You cannot "return" from within the block. The method was popped off the stack and returned some time previously.
You need to re-architect the logic of this. Invoking a refresh on the main queue is in the right direction.
Try this:
[self processJSONDataWithURLString:[NSString stringWithFormat:#"https://www.someapi.com/api/profile.json?username=%#",username] andBlock:^(NSData *jsonData) {
NSDictionary *attributes = [jsonData objectFromJSONData];
BOOL status=YES;
// Check to see if username has data key, if so, that means it already exists
if ([attributes objectForKey:#"Data"]) {
status=NO; // Do not continue, username already exists
[self performSelectorOnMainThread:#selector(callDelegate:) withObject:[NSNumber numberWithBool:status] waitUntilDone:YES];
}];
-(void)callDelegate:(NSNumber*) status
{
BOOL returnStatus = [status boolValue];
//now retutn returnStatus to your delegate.
}
But this is not the right way to do it, you gotta change the logic you have written to support asynchronous communication. You could consider mine, only if you want to do it your way.

iOS: Grand Central Dispatch and ViewControllers

At this point I'm pretty frustrated but I'm sure it is something I'm missing. In this code my segue to my new viewController is showing up after the rest of the function is executed. How do I get my viewController to be the code being executed? Basically stop the tweetText function from happening until that view is closed I'm trying to give the user an option to select a twitter account if there is more than one. I have tried many different ways. In Apples own example code they suggest to give the user an option but give nothing on how to do it without blowing through the rest of the code.
Here is the code:
[accountStore requestAccessToAccountsWithType:accountType withCompletionHandler:^(BOOL granted, NSError *error) {
if(granted) {
dispatch_sync(dispatch_get_main_queue(), ^{
// Get the list of Twitter accounts.
self.accountsArray = [accountStore accountsWithAccountType:accountType];
if([self.accountsArray count] > 1 /* Check method to see if preference is still a valid account */) {
// Display user accounts if no preference has been set
[self performSegueWithIdentifier:#"TwitterAccounts" sender:self.accountsArray];
[tweet tweetText:tweetString account:self.twitterAccount type:AchievementTweet];
} else {
[tweet tweetText:tweetString account:[self.accountsArray lastObject] type:AchievementTweet];
}
});
} else {
[tweet performSelectorOnMainThread:#selector(displayText:) withObject:[NSNumber numberWithInt:403] waitUntilDone:NO];
}
}];
I am a little confused on what is your purpose but you got 2 options.
There is really no need for GCD here.
I would suggest to register for a notification which will perform your second action once your first action has been accomplished. (Similar to how apple handles the image picker, on their code they inform of when the picture has finally been saved to execute another function).
The other way is using delegates, on this approach you would put the second part of the code on a separate function, then declare that controller as the delegate of the viewcontroller you want executed first, then after whatever you want acomplished is done on the viewcontroller you would ask the delegate to perform the second code and if necessary ask the delegate to close the view as well.

Resources