• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Scheme for efficiently archiving images.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Scheme for efficiently archiving images.
      • From: Graham Cox <email@hidden>
References: 
 >Scheme for efficiently archiving images. (From: Graham Cox <email@hidden>)

  • Prev by Date: Memory management puzzle
  • Next by Date: how to set up nextKeyView, full keyboard access etc, for custom subviews set up in code (rather than nib)
  • Previous by thread: Re: Scheme for efficiently archiving images.
  • Next by thread: Re: Scheme for efficiently archiving images.
  • Index(es):
    • Date
    • Thread