problem with asynchronous programming while calling 2 methods in Objective-C

Question

Hello,

Inside ClassA:

-(void)authenticateUser
{
   authenticate_Obj = [classB_Obj authenticateMobileUser];
}

Inside ClassB:

-(AuthenticateObj*)authenticateMobileUser
{
   [mobile_Obj AuthenticateMobileServer:self action:@selector(Handler:)];
   return authenticate_G_Obj;
}

-(void)Handler:(id)value
{
   authenticate_G_Obj = (AuthenticateObj*)value;
}

Now once the authenticateMobileUser method of classB returns the controll back to ClassA, we will get the Object authenticate_Obj initiated.

My problem is , when i run the project the authenticate_Obj is NULL... actually when it enters the handler method , the Object is initiallized. but the controlled is returned back to ClassA, without entering into Handler method. I guess this is the problem of Asynchronous execution. How to make it enter into handler method and then only return the controll to ClassA??

Plz help me..

Thank You.

Answer 1

I think you are saying that AuthenticateMobileServer:action: is asynchronous and you want to block until it's finished so you can get the return value. Unfortunately, we can't really tell you without knowing how it works. The main question is does it run the Handler action on the main thread or a secondary thread.

If it runs the action on the main thread, the best strategy is to return immediately from authenticateMobileUser without waiting for the authentication object and disable the UI elements that depend on being authenticated. Then later when you get the authentication object, you should re-enable the UI elements.

If it runs the action on a background thread, the easiest thing is to set up another method similar to Handler (by the way, the naming convention for methods and variables is to start with lower case), which you then invoke from Handler with performSelectorOnMainThread:waitUntilDone:. You can then use the same strategy as outlined above.

Answer 2

It sounds like what you think you want to do is to block execution until authentication completes. This might be possible if AuthenticateMobileServer spawns a background thread to work in -- you'd use a synchronisation object such as NSLock -- but it's really a Bad Idea. Why have a background thread at all if you're going to block anyway? And thread synchronisation is notoriously tricky and prone to errors if you don't know what you're doing, which (let's face it) you don't.

Instead, you probably should accept that there will be a period of uncertainty while the authentication takes place, during which your app should keep processing in some intermediate state, and then use a callback to notify you when the authentication is complete and you can then go on with whatever it is you need to do with the authenticated user.

There are a bunch of ways you could do this, and there's not enough detail in the question to say exactly which would be best. But you already seem to be using something very similar within ClassB, so I'd say do the same from ClassA:

Inside ClassA:

-(void)authenticateUser
{
   authenticate_Obj = nil;
   [classB_Obj authenticateMobileUserAndNotify:self action:@selector(authenticatedObject:)];
   // returns more or less immediately, not yet authenticated
}

-(void)authenticatedObject:(YourAuthObjectClass*) authObj
{
    authenticate_Obj = authObj;
    // do post-authentication stuff here
}

Inside ClassB:

-(void)authenticateMobileUserAndNotify:(id)target action:(SEL)sel
{
   // I'm making these ivars for simplicity, there might be other considerations though
   callbackTarget = target;
   callbackSelector = sel;

   [mobile_Obj AuthenticateMobileServer:self action:@selector(Handler:)];
}

-(void)Handler:(id)value
{
   authenticate_G_Obj = (AuthenticateObj*)value;
   [callbackTarget performSelectorOnMainThread:callbackSelector withObject:authenticate_G_Obj waitUntilDone:NO];
}

Obviously this is just a sketch and not intended to be used as is. And you'll need to consider what goes on in your app while in the waiting state, with authentication in progress but authenticate_Obj still nil. But hopefully you get the idea.

Answer 3

Both answers of JeremyP and walkytalky are correct and go at the heart of creating a respondsive UI. The rule of thumb:

If you doing potentially blocking operations such as networking on the main thread, you will get in trouble.

There are at least two reasons:

1. you are blocking the run loop so it cannot process user events anymore. This will result in a spinning beachball on the mac and a unresponsive UI on both mac and iOS.
2. If you are on iOS, there is a watchdog going around and checking if your UI is still responding to user events. If you are blocking the UI longer than I think 20s you will be terminated with the error code 0x8badf00d.

So to get this things done which maybe take some time you have to do it on the background thread. As the two answers of JeremyP and walkytalky point out often you get a callback. That is fine but there are in total three ways of messaging:

• Delegation
• Notifications
• Kev-value-observing

All three can be and are used. There are subtle differences between them. One of the most important is that delegation is a 1:1 messaging whereas the other to are a 1:n messaging.

Now that said do not think that you have to use NSThread. Have a look at NSOperation and NSOperationQueue instead. They allow to encapsulate pieces of work in an operation and let them run on a queue in the background. Also if you are using these callbacks with the @selector(methodname:) syntax there is something new: blocks. Often there are equivalent methods which take a block instead of a selector to be executed as a callback.

To finish here is the golden rule:

You may update your model on the background thread, but NEVER update your UI on a background thread.

Check out the WWDC10 videos about these topics. There is a great 2-part talk about networking which explains the concepts in detail.