CODEWITHSUNDEEP
iosobjective-c-blockssemaphore
Shumais Ul Haq
Shumais Ul Haq

Reputation: 1447

iOS Stop block execution from progressing until block has finished

I have a method in an iOS app that is supposed to return a bool value depending upon whether or not a web call succeeds.

The web call is structured in a way such that it takes a block as a callback parameter and that callback is called when the web call has a result. Based on that result my method needs to return a True/False value.

So, I need to stop execution from progressing any further without first having a result to return.

I am trying to achieve this via semaphores, after looking at some examples that others have shared, but the callback is never called, if I remove the semaphore then the callback is always called.

What am I missing here?

+ (BOOL)getUserInformation {
__block BOOL flag = false;

dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);

[[WebServicesManager sharedManager] getUserInformationWithCallback:^(NSInteger statusCode, NSString *response, NSDictionary *responseHeaders, id obj, NSError *error) {

    if (error) {
        //Handle error case and perform appropriate cleanup actions.
    }
    else
    {
        //Save user information
        flag = true;
    }

    dispatch_semaphore_signal(semaphore);
}];

dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);

return flag;
}

I put a break point on if(error) to check if the callback gets called, it doesnt, unless I remove the semaphore.

I could give this method its own callback block or I could give the containing class a delegate and achieve what I need but I would really like to make this approach work.

Upvotes: 0

Views: 696

Answers (2)

Rob
Rob

Reputation: 438287

You are undoubtedly deadlocking because you're using semaphore on same thread to which the web services manager (or the API that that is using) dispatches its completion handler.

If you want a rendition that avoids the deadlock scenario, but also avoids the pitfalls of blocking the main thread, you can do something like:

+ (void)getUserInformation:(nonnull void (^)(BOOL))completionHandler {
    [[WebServicesManager sharedManager] getUserInformationWithCallback:^(NSInteger statusCode, NSString *response, NSDictionary *responseHeaders, id obj, NSError *error) {
        if (error) {
            completionHandler(false);
        } else {
            //Save user information
            completionHandler(true);
        }
    }];
}

Then, rather than doing something like:

BOOL success = [YourClass getUserInformation];
if (success) {
    ...
}

You can instead do:

[YourClass getUserInformation:^(BOOL success) {
    if (success) {
        ...
    }
}];

// but do not try to use `success` here ... put everything
// contingent upon success inside the above completion handler

Upvotes: 0

Tobi Nary
Tobi Nary

Reputation: 4596

The WebServicesManager is probably dispatching it's block on the same thread the semaphore is waiting on.

As @Rob is correctly mentioning in the comments, this is most likely not a good idea to do on the main thread; rather make use of the asynchronous model and not block the main thread for possibly minutes until the connection may time out under certain circumstances, freezing your UI.

Upvotes: 2

Related Questions