Re: UIDocument with NSFileWrapper
Re: UIDocument with NSFileWrapper
- Subject: Re: UIDocument with NSFileWrapper
- From: Luther Baker <email@hidden>
- Date: Tue, 22 Mar 2016 01:02:53 +0000
Thanks for posting this. Exploring UIDocument and caching/parsing JSON
instead of CoreData for a service based mobile app that must support
offline mode ... and looking forward to considering where you landed.
On Mon, Mar 21, 2016 at 5:11 PM <email@hidden> wrote:
>
> > On Mar 21, 2016, at 2:08 AM, Quincey Morris <
> email@hidden> wrote:
> >
> > On Mar 19, 2016, at 18:54 , email@hidden wrote:
> >>
> >> What I’m having trouble understanding is how I store the images (whose
> filenames will vary from document to document) with NSFileWrapper. In my
> top level directory do I have my main model file as a JSON file along with
> a file (JSON or plist) that lists all the images and then have an Image
> directory that another NSFileWrapper is used to read/write the images (that
> are stored in the Image subdirectory)?
> >>
> >> Or can I simply store all the files without a subdirectory? I still
> suspect I need to have a file with a fixed name (such as image.plist) that
> tells me what all the other filenames are to put in the NSFileWrapper (vs.
> using NSFileManager to ask for the name of all the files).
> >
> > There’s no correct answer to these questions. It’s a design problem
> whose answer is whatever works best in your use case. I’d recommend you
> start by choosing what looks to you like the most straightforward approach,
> then be prepared to revise your strategy later if it doesn’t work out well.
> (The amount of code relating to file wrappers is likely to be small
> relative to the code that generally maintains your data model, so rewriting
> it shouldn’t be onerous. However, that suggests it would be prudent not to
> let the wrappers propagate too deeply into the model. Keep them as an
> artifact of the save mechanism in particular, rather than the data model in
> general.)
> >
>
> Ok, thanks again for all your feedback. I took a stab at implementing it
> yesterday. Everything is in my subclass of UIDocument. The rest of the
> model is a layer below the UIDocument subclass (i.e., the subclass has a
> couple instance variables which are the main model) although I did put a
> few methods in the UIDocument class to add the images since that needs to
> change the NSFileWrapper.
>
> I think I've got it working. Here is how I did it (in case this helps
> anyone else and in case anyone else sees a problem with this).
>
> UIDocument subclass has a NSFIleWrapper instances for each of these:
>
> 1. Top level NSFileWrapper directory wrapper.
> 2. It contains a directory wrapper for a subdirectory named Images where
> all the image files (that won't be updated often go). I put the method to
> add an image here so that it could update the NSFileWrapper
> 3. a NSFileWrapper that contains a single file that is a list of all the
> image filenames that is added to the top level NSFileWrapper
> 4. a NSFileWrapper for the rest of the model that will change often and is
> added to the top level NSFileWrapper
>
> Whenever an image is added, I remove the NSFileWrapper in #3 from the top
> level file wrapper, created a new NSFileWrapper with the new list of
> images, and then add that to the top level NSFileWrapper. And add the image
> file to the NSFileWrapper in #2. It appears you must call removeFileWrapper
> on the top level NSFileWrapper and then add the new NSFileWrapper with
> addFileWrapper rather than just calling addFileWrapper with the same
> preferred filename and replacement NSFileWrapper. Similarly with my #4 main
> data model file, I call removeFileWrapper and addFileWrapper each time a
> save occurs since this data changes frequently.
>
> Since images won't be added as often as the rest of the model is updated,
> I'm hoping this won't cause these images to be re-written every time a save
> is performed but I'm not certain how to verify this is the case.
>
> Thanks,
> Dave Reed
> _______________________________________________
>
> 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