On Sep 8, 2011, at 7:12 AM, Mike Abdullah wrote: >> since we are downloading large data from server so NSURLConnection delegate >> mentioned below is getting called continuously and meanwhile also need to >> update UI, so calling the web service function itself in a saperate thread. > > A Mac is plenty capable of running large downloads on the main thread > asynchronously. What made you decide you shouldn't?
Is the problem that the -makeRequest method is synchronous, and will block the main thread’s UI and download delegates unless you run it on a background thread? (I am assuming that’s a method defined in your app, as there’s no standard Obj-C API for web services, nor any standard -makeRequest method.) It would be better to refactor this so it runs asynchronously, IMHO. Multi-threaded programming is notoriously hard and prone to nasty bugs. As for the original question, I’m not aware of any significant changes in behavior of NSURLConnection in 10.7. I’m sure they’ve changed things some down in the implementation, but that shouldn’t affect the behavior of clients. Since you’re using multiple threads, you should double-check that you don’t have thread-safety problems, like calling the same request/connection/response objects from different threads, or scheduling the connection on the wrong runloop. (Or thread problems with your own logic, since that -detachNewThreadSelector: call indicates you’re now calling methods of your object on multiple threads.) —Jens_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
