On 23 Apr 2014, at 10:31 pm, edward m taffel <[email protected]> wrote:

> i’m attempting to show load progress for complex documents. my document class 
> defines readFromURL & this seems the natural place to do this; however, for 
> autosaved documents the progress window does not show until the document 
> window shows (in the same instant, after the load is complete). i expect this 
> is something to do w/ readFromURL being sent from a background thread; but, 
> there must certainly be some way to flush the progress window. 
> 
> all/any suggestions greatly appreciated.

I recently (re)implemented a comprehensive progress-reporting interface in my 
app, and it is able to hook into document read/writes.

The important thing I learned was NOT to attempt to "drive" the progress 
indication from the worker code (i.e. the code that's doing the actual work - 
file I/O for example, or archiving/dearchiving). Instead, get the progress UI 
to poll for progress on the work that it's interested in from the main thread. 
This flips the situation on its head, but it works out beautifully (the idea 
came from Jens Alfke). The progress UI just sits on the main thread, updating 
naturally, and it periodically asks the work how far it has got, using a simple 
timer. You need a protocol or other API that the worker code can adopt so that 
it is pollable by progress, and a way to set up and tear down the progress at 
the start and end of the work itself. In my case I can show any number of 
simultaneous progress views within a stack, since multiple work units can be 
done on different threads, so I also need a way to associate the work with the 
given progress controller. In my case this is trivially a reference to the 
object that implements the progress-pollable protocol.

Note that in 10.9 there is also a 'NSProgress' object that defines an API for 
progress-monitorable work, though don't be misled into thinking this provides 
any sort of UI - it doesn't. But adopting it rather than rolling your own might 
be an idea, though in my case I didn't because I need to support back to 10.6.

So for the case of saving a document, which in my case involves using 
NSKeyedArchiver to archive an object graph, I assign a delegate to the archiver 
which keeps track of how many objects it has archived out of the total number 
it will archive (figuring that out in advance was the hardest part, but it 
doesn't need to be more precise than a rough estimate for reasonable progress 
accuracy). The delegate starts a progress on the first call and stops it on the 
last, and then the progress polls it at intervals displaying the result. A 
simple 'atomic' property is all I need to read the amount of work value in a 
thread-safe manner.

--Graham



_______________________________________________

Cocoa-dev mailing list ([email protected])

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to