I have a lengthy operation O that is called through a NSInvocationOperation, itself scheduled by adding it to a NSOperationQueue so that it runs asynchronously. That lengthy operation O is invoked in two different cases in my app.
In case A, operation O is invoked as a result of tapping some widget in some view. As soon as the widget is tapped, operation O runs for a while (I can see that thanks to a UIActivityIndicator), but it does not slow down or block the UI, thus I am able to tap on other widgets and perform other UI operations while operation O is running.
In case B, operation O is invoked as a result of receiving a local notification, in the app delegate's didReceiveLocalNotification method. In this case, UI operations performed right after invoking operation O, while still in the didReceiveLocalNotification method, are considerably slowed down, basically to a crawl, almost as if operation O had taken over the CPU.
Why is that, and what would be the right way to invoke operation O in case B, so that it indeed runs concurrently in the background with a lower priority, leaving the rest of the code in didReceiveLocalNotification method to run at a normal speed?
NOTE: Operation O mucks around with local notifications (removing existing ones or scheduling new ones) and calendars (querying the event store to better schedule local notifications).