Question

I’ve been struggling with this problem for over a week. And I really need some help.

I am using ASIHTTPRequest to handle three different download requests. The first download request will download from an online .txt file a timestamp. According to that timestamp, it must process how the application will launch.

It will check if a timestamp has been previously saved in NSUserDefaults, if not then this is the first time the app is launched and it will download a JSON feed (using ASIHTTPRequest) and then parse it into Core Data.

If the stored timestamp matches the online one, then nothing happens since the data is up to date.

If the stored timestmap is older than the online timestamp, then the database will be cleared and redownloaded.

My problem is that in ASIHTTPRequest, before requestFinished gets executed, application:didFinishLaunchingWithOptions gets executed to the end. Now in the beginning of application:didFinishLaunchingWithOptions, I ask ASIHTTPRequest to download the online timestamp. Before application:didFinishLaunchingWithOptions is over, I need to have the online timestamp downloaded and ready to be use. How would I do that? Problem with ASIHTTPRequest is that it starts executing after application:DidFinishLaunchingWithOptions is over.

Answer 1

Without some code to look at, our answers have to be fairly general. But it sounds to me like you need to change your startup flow completely.

If it’s important that your http requests happen in order, you need to call them in order–nested in each other’s completion delegate methods. You can use ASIHTTPRequest’s .userInfo field to identify the different types of request you’re firing.

Your didFinishLaunching method should just do enough to get your first request started (and maybe bring up a “loading” view), then the rest of the app launching work needs to be done in the various requestDidFinish methods.

If you’re in control of the website side of things too, you might see how much of this work you can offload to the server code. I prefer to do my work on the biggest iron I can find, which means I usually do my data manipulation in my web app, and just send the results out to the phone.

EDIT: Here’s some code to describe what I mean by “nested in each other’s completion methods”. Note that I just typed this right here, so don’t just copy and paste this and expect anything like sensible behavior.

// inside didFinishLaunching
ASIHTTPRequest *myInitialRequest = [ASIHTTPRequest requestWithURL:myNSURL];
myInitialRequest.userInfo = [NSDictionary dictionaryWithObject:@"initial" forKey:@"type"];
myInitialRequest.delegate = self;
[myInitialRequest startAsynchronous];
// and then NOT other setup stuff that depends on this data.


-requestDidFinish:(ASIHTTPRequest *)request
{
    if ([[request.userInfo objectForKey:@"type"] isEqualToString:@"initial"]) {
        //you just used the userinfo field to differentiate this from other requests
        //do whatever here, and then make your next request HERE.

        ASIHTTPRequest *nextRequest = [ASIHTTPRequest requestWithURL:myNextURL];
        nextRequest.delegate = self;
        nextRequest.userInfo = [NSDictionary dictionaryWithObject:@"next" forKey:@"type"];
        [nextRequest startAsynchronous];
    }
    if ([[request.userInfo objectForKey:@"type"] isEqualToString:@"next"]) {
        // so now you know this is your "next" type request coming back to you.

        // ... so do whatever you do with this, and then HERE do the rest of your
        // app setup and launch business.
    }
}

So you set up a request with a userInfo field that identifies it, and then differentiate the handling of its response based on that field. That’s basic to using more than one ASIHTTPRequest in a view controller anyway.

And then your next request is based on the response of the first one–you’re launching a second request after learning what you needed to learn from the first one’s response content.

By the way, you can also specify the completion handler method, or use the block interface to specify what ASIHTTPRequest does on completion. But I think loading your requests up with identifying userInfo fields and then handling your responses all in one place is the cleanest approach.