Objective-C callback handler [closed]

by

I’m not entirely sure what you’re trying to do there – your callback is a block… is that intentional? I would expect your method to look something like this:

- (void)signInAccountWithUserName:(NSString *)userName password:(NSString *)password;

If the intention of your callback is to execute some additional code (specified when you call the method) on completion, then a block would be useful. For example, your method would look like this:

- (void)signInAccountWithUserName:(NSString *)userName
                         password:(NSString *)password
                       completion:(void (^)(void))completionBlock
{
    // ...
    // Log into the account with `userName` and `password`...
    //

    if (successful) {
        completionBlock();
    }
}

And then call the method like so:

[self signInAccountWithUserName:@"Bob"
                       password:@"BobsPassword"
                     completion:^{
                         [self displayBalance];  // For example...
                     }];

This method call would log the user into the account and then as soon as that is complete, show the balance. This is clearly a contrived example, but hopefully you get the idea.

If this is not the kind of thing you intended, then simply use a method signature like the one above.

EDIT (A better example using the successful variable):

A better design would be to pass a Boolean back in the completion block that describes how well the login went:

- (void)signInAccountWithUserName:(NSString *)userName
                         password:(NSString *)password
                       completion:(void (^)(BOOL success))completionBlock
{
    // Log into the account with `userName` and `password`...
    // BOOL loginSuccessful = [LoginManager contrivedLoginMethod];

    // Notice that we are passing a BOOL back to the completion block.
    if (completionBlock != nil) completionBlock(loginSuccessful);
}

You’ll also see that this time around we’re checking that the completionBlock parameter is not nil before calling it – this is important if you want to allow the method to be used without a completion block. You might use this method like so:

[self signInAccountWithUserName:@"Bob"
                       password:@"BobsPassword"
                     completion:^(BOOL success) {
                         if (success) {
                             [self displayBalance];
                         } else {
                             // Could not log in. Display alert to user.
                         }
                     }];

Better still (if you can excuse the swaths of examples!), if it would be useful for the user to know the reason for the failure, return an NSError object:

- (void)signInAccountWithUserName:(NSString *)userName
                         password:(NSString *)password
                       completion:(void (^)(NSError *error))completionBlock
{
    // Attempt to log into the account with `userName` and `password`...

    if (loginSuccessful) {
        // Login went ok. Call the completion block with no error object.
        if (completionBlock != nil) completionBlock(nil);
    } else {
        // Create an error object. (N.B. `userInfo` can contain lots of handy 
        // things! Check out the NSError Class Reference for details...)
        NSInteger errorCode;
        if (passwordIncorrect) {
            errorCode = kPasswordIncorrectErrorCode;
        } else {
            errorCode = kUnknownErrorCode;
        }
        NSError *error = [NSError errorWithDomain:MyLoginErrorDomain code:errorCode userInfo:nil];
        if (completionBlock != nil) completionBlock(error);
    }
}

The caller can then make use of the NSError in the completion block to decide how to proceed (most likely, to describe to the user what went wrong). This kind of pattern is slightly less common (though perfectly valid); mostly NSErrors are returned by pointer indirection, for example in the NSFileWrappers -initWithURL:options:error: method:

NSError *error;
NSFileWrapper *fw = [[NSFileWrapper alloc] initWithURL:url options:0 error:&error];
// After the above method has been called, `error` is either `nil` (if all went well),
// or non-`nil` (if something went wrong).

In the login example, however, we are probably expecting the login attempt to take some amount of time to complete (for example logging into an online account), so it is perfectly reasonable to make use of a completion handler that passes an error back.

Leave a Comment

tech