Re: Progress for archiving/dearchiving
Re: Progress for archiving/dearchiving
- Subject: Re: Progress for archiving/dearchiving
- From: Chris Devereux <email@hidden>
- Date: Mon, 16 Sep 2013 18:32:39 +0100
Another angle worth looking at: Depending on the output format you're using
with NSKeyedArchiver, your file might already contain an object count, even
if the API doesn't expose it.
According to the Cocotron source[1], the binary plist format actually does
this. It won't correspond exactly to the number of objects encoded using
NSCoding since it represents the number of plist objects, but may be close
enough to give an indication of progress.
[1]:
http://cocotron.googlecode.com/svn/trunk/Foundation/NSPropertyList/NSPropertyListReader_binary1.m
On 16 September 2013 18:25, Graham Cox <email@hidden> wrote:
>
> On 16/09/2013, at 6:51 PM, Jeffrey Oleander <email@hidden> wrote:
>
> > I'll bite. If you want to know the total number of objects to be
> archived, then you need to count them, at some time or another. To count
> them, you need to walk the object tree before you start actually
> archiving... which may take a significant fraction of the time it takes to
> archive.
>
> I can count them as I archive, using the delegate.
>
>
> > Then, you could make sure it's the first thing that is archived, and
> hence the first thing unarchived... after which you can display/update the
> progress bar.
>
>
> It can actually be the last thing archived, but the first thing unarchived
> (you can do that with keyed archiving). But it might also be something that
> can be stored in my info file rather than the archive itself.
>
> What I was sort of hoping was that there was a way to figure out from the
> archive how many objects there were without having to archive the number
> explicitly. For example, the root level of an archive is a dictionary,
> which has a count, but that's only the top level. Going more into the way
> archives are actually stored, maybe the $top array might be a more accurate
> count? Dunno, I guess I'll have to experiment.
>
> --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
>
_______________________________________________
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