Re: Scheme for efficiently archiving images.
Re: Scheme for efficiently archiving images.
- Subject: Re: Scheme for efficiently archiving images.
- From: Ken Thomases <email@hidden>
- Date: Wed, 26 Nov 2008 21:00:00 -0600
On Nov 26, 2008, at 7:26 PM, Graham Cox wrote:
In my app I have a class that "has a" NSImage which it displays.
Currently, when I archive the whole kit-n-kaboodle when saving to a
file, the image simply gets archived as an object. [...]
There are a few issues though. When my image-owning objects gets its
-encodeWithCoder: message, the package it's going to create may not
exist yet, and I'm not sure how I can find out at that point what it
will be. So I wondered if I could archive a file wrapper at that
point with the original file data. Would that achieve anything? (I'm
guessing not - a file wrapper embedded in the archive stream will
not be visible to the high-level file archiving done by NSDocument
so it's no advantage over archiving NSData - but correct me if I'm
wrong).
First, it seems to me like you don't want an NSImage in your model.
You want the original source of the image. Either a file path or a
blob of data with some meta-data (e.g. UTI) describing it and what it
is. You'd use NSImage as a view-enabling technology.
If you get a file from the user, you might want to copy it to a
temporary file of your own, to protect against the original file being
deleted.
Some possibilities of where to go from there:
Approach 1: This is a bit of a kludge. Don't have your model archive
its image. Instead, have your NSDocument-subclass writing method
directly query your model for the image information, so it can store
it separately from the archived model object. This supports putting
it in a file in a package-style document.
Approach 2: This is a refinement of approach 1 which makes it less
kludgy. Create a custom archiver class, subclassing NSKeyedArchiver.
Your NSDocument subclass would use that to archive your model. It
would be initialized with information about where to store image data
out-of-band -- that is, not in the data object it creates as part of
the archiving step. In your image-holding model class,
encodeWithCoder: would check for that special type of coder. If it's
the special type, use methods of your own design to pass the image
data to the archiver for out-of-band storage. If it's a normal coder,
just store the image data in the naive way.
With either approach, you'd do the complement for reading the
document, of course.
Good luck,
Ken
_______________________________________________
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