Re: showing load progress for autosaved documents
Re: showing load progress for autosaved documents
- Subject: Re: showing load progress for autosaved documents
- From: edward taffel <email@hidden>
- Date: Wed, 23 Apr 2014 20:06:20 -0400
thank you for this graham!
at present, i’m finding it difficult to find a point, prior to NSDocument initializing autosaved documents, to show a progress window. everything above readFromURL is off the main thread & there is nothing in the application delegate protocol that precedes—so far as i’m aware. any thoughts here?
best,
edward
On Apr 23, 2014, at 7:36 PM, Graham Cox <email@hidden> wrote:
>
> On 23 Apr 2014, at 10:31 pm, edward m taffel <email@hidden> 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@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