Re: Background processing and progress updates
Re: Background processing and progress updates
- Subject: Re: Background processing and progress updates
- From: Alastair Houghton <email@hidden>
- Date: Wed, 1 Aug 2007 12:53:25 +0100
On 1 Aug 2007, at 11:52, Michael Dautermann wrote:
On Aug 1, 2007, at 3:43 AM, Christian Moen wrote:
I'm thinking about starting the processing as a separate thread,
which keeps
track of progress and status, and makes this information available
through
some accessors. Additionally, I'm thinking setting up a timer
that polls
the accessors every 1/10th of second or so to update the sheet.
If an error
occurs, I'll call a method in the main thread.
Hi Christian,
The way I do stuff like this in my apps is to have my separate
processing thread send a message (for example, percent completed)
to the progress dialog running off the main thread via:
[ NSObject performSelectorOnMainThread:withObject:waitUntilDone:]
That'd be much nicer than polling.
Actually it depends on how often you're sending the message. If your
app is busy working, nobody is going to complain about its main
thread polling on a slow timer (like 1/10th of a second), and it
means that you're only going to be updating the progress on screen at
that rate (rather than trying to update it a thousand times a second
or something equally unnecessary).
I've used both approaches in applications I've written. Lately I
think I prefer the timer approach.
Also, if you're using a "sheet" (which is modal), that implies that
your whole app is going to freeze while processing is going on
(which negates the need to run this on a separate thread).
That's not true. If you do processing on the main thread, you will
either end up with your application being unresponsive (and
beachballing), or you will have to poll manually for events as you do
whatever task you're doing. The latter causes all sorts of problems
(for instance, the potential for nested invocations of event
handlers, the fact that polling this way sometimes doesn't behave
exactly the same way as returning to the run loop would, the fact
that it's hard to control how often you poll, because it depends on
the performance of your user's machine and the size of task you're
undertaking, etcetera etcetera).
Unless you can work asynchronously somehow (for instance using
NSFileHandle or NSStream), you should be doing your work on a thread
other than your UI thread.
Additionally, the sheet does not imply that the whole app will
freeze. It simply means that the window displaying the sheet is busy
and that normal interaction with that document (e.g. in a
wordprocessor, text editing) is suspended until the sheet is closed.
But you can still e.g. use other documents in the same application.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden