tags:

views:

31

answers:

2

NSOperation thread running in background, causes a UITableView or UIScrollView or UIWebView scrolling rough(Not smooth as it would be usually.)

How can i solve this problem ??

There is no connection between UITableView datasource and delegates and thread which is running in background. Both uses independent resources.

How to solve this problem ??

+1  A: 

The iPhone has only a single processor core, so the execution of any background threads (such as those used by NSOperation) is interleaved with UI rendering and other operations. The work being done by your operation is sufficiently demanding that the CPU hasn't enough time left over to run the scrolling/rendering logic fast enough to give a smooth result. Basically, you need to do less. However, you might get some milage out of changing the thread priority of your NSOperation instance; something like...

[myOperation setThreadPriority:0.1];

This should push the scheduler to prioritise other threads (such as the rest of your code and the UI rendering operations) over your background operation.

The other alternative is to make your scrolled rendering workloads (i.e. UITableView cells) more efficient. For the table case, if you're using cells with many sub UIViews you can try and replace them with cells that use i.e. just images.

Adam Wright
I have tried your approach, but its not working.
Matrix
Then, bluntly, you're just doing more than the iPhone's resources can handle. What's happening in your `NSOperation`?
Adam Wright
just finding current location lat, long value and when it finds it just Notifies ViewControllerObject(which also holds UITableView).
Matrix
What's your test iPhone/iPod version?
Adam Wright
3.1....................
Matrix
Sorry, I meant the hardware version. GPS usage on an iPhone 3G is, for no reason I can think of, a cause of *huge* system wide lag.
Adam Wright
+1  A: 

I had recently given up on finding a solution to the same problem. But it just occurred to me that you might be able to use KVO to watch the decelerating and tracking properties of the table view, and if either is true then suspend the operation queue. That won't stop any operations that have already started, but at least it won't start any new ones. Then you can resume the queue when the tableview is no longer tracking or decelerating.

This is all completely speculation though. I would try it myself if I had the time...

Brian
once operation suspended when tableview declerating and tracking then how to start that suspended operation ??? and when to start ??
Matrix
Wait, are you just using an NSOperation as a lone thread? If so, my answer may not be relevant
Brian