3

Is it OK to use NSOperationQueue addOperationWithBlock to delay initialization code, so the app was not killed by an iOS watchdog?

As we know iOS kills the app if it spends too much time in application: didFinishLaunchingWithOptions or in applicationDidBecomeActive.

But I have a lot of things to do for initialization. Currently I am doing a bunch of synchronious HTTP requests (let it be synchronious :) ) whcih can take unpredicatble duration of time.

Could you suggest a nicer solution to this problem?

Thank you!

EDIT: Everyone, synced HTTP requests are not a subject of the question. I have a lot of third-party SDKs integrated. I have to initialize all of them but I have no idea what they are doing during initialization. I am just trying to minimize the risk of being killed by iOS.

Anton Petrov
  • 782
  • 1
  • 8
  • 19
  • 1
    I would definitely suggest to first make your http requests asynchronous. Putting this code (the http code) in a NSOperation is ok, but does not really make senses compared to making async http requests – rpechayr Jan 28 '12 at 09:42
  • @rpechayr one use case I would consider completely sensible for synchronous fetches that are issued (whether via an NSOperationQueue or GCD) so as not to block a named thread is as a four-line fallback for pre-iOS 5 devices where there's no `+ sendAsynchronousRequest:queue:completionHandler:` on NSURLConnection. So we're talking about adding compatibility for a (currently sizeable but ever shrinking) minority of users, while trying to write the minimum amount of code to aid future maintainability. – Tommy Jan 29 '12 at 23:16

1 Answers1

2

Perform your web requests asynchronously and if necessary show a loading UI while they progress. You should never run synchronous web requests in application:didFinishLaunchingWithOptions:, watchdog is there for a reason.

Ell Neal
  • 6,014
  • 2
  • 29
  • 54