Re: UIDocument with NSFileWrapper
I don't claim this is the one right way, but I think it makes sense based on the little bit of documentation there is for NSFIleWrapper and it seems to work. My situation is complicated because my document consists of multiple files. UIDocument is pretty simple if you only need a single data file to store all your data. I'll post an update if I find anything else out, but I may start prototyping some other parts of that app before coming back to this again in a month or so. Dave Reed > On Mar 21, 2016, at 9:02 PM, Luther Baker wrote: > > 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 wrote: > > > On Mar 21, 2016, at 2:08 AM, Quincey Morris > > wrote: > > > > On Mar 19, 2016, at 18:54 , davel...@mac.com 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
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 wrote: > > > On Mar 21, 2016, at 2:08 AM, Quincey Morris < > quinceymor...@rivergatesoftware.com> wrote: > > > > On Mar 19, 2016, at 18:54 , davel...@mac.com 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 (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com > > This email sent to lutherba...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
> On Mar 21, 2016, at 2:08 AM, Quincey Morris > wrote: > > On Mar 19, 2016, at 18:54 , davel...@mac.com 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
On Mar 19, 2016, at 18:54 , davel...@mac.com 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.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
> On Mar 19, 2016, at 8:01 PM, Quincey Morris > wrote: > > On Mar 19, 2016, at 14:23 , davel...@mac.com wrote: >> >> My thought is to have a dictionary mapping each image filename to a >> NSFileWrapper > > You already have one, basically. The top level wrapper for a package is a > directory wrapper, which lists the wrappers of contained files, indexed by > file name. Yes, right now I have that wrapper saving a JSON file that I read/write back into my model. The documentation I found for NSFileWrapper handles the case where there are a fixed number of files with names known at compile time so I’m struggling to understand what to do when the number of files can vary and the names aren’t known at compile time. 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). Thanks for all your input. Dave Reed ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
On Mar 19, 2016, at 14:23 , davel...@mac.com wrote: > > My thought is to have a dictionary mapping each image filename to a > NSFileWrapper You already have one, basically. The top level wrapper for a package is a directory wrapper, which lists the wrappers of contained files, indexed by file name. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
> On Mar 19, 2016, at 1:48 PM, Quincey Morris > wrote: > > On Mar 19, 2016, at 10:18 , davel...@mac.com wrote: >> >> The downside I see for my app is that UIDocument writes out the data to a >> temporary location and then moves it to the new location so I think my app >> will constantly be writing out these image/PDF files that never change. Is >> there a better way to do this so that the image/PDF files only get written >> out when they’re first added (or changed if they do get changed). > > a. It’s not obvious that the unchanged files *are* written to a temporary > location and then moved. The trick is to keep the original directory wrapper > that you got when opening the file, and to preserve the individual file > wrappers for unchanged components. (You can, for example, just delete the > file wrappers for things that *are* changed, when they’re changed, then add > the missing wrappers at save time.) The save mechanism then knows what has > and has not been changed, and can optimize the save appropriately. > > b. Even if the files are copied, it’s not obvious that you need “a better > way”. It may be fine to copy the files at every save. > > I’d recommend you don’t try to solve this problem until it forces itself on > you as an actual problem. > Ok, I'll give it a try and see if it slows down too much or seems to be constantly overwriting these files before worrying any more about it. I just wondered if there was a "better way" to do it so I figured I'd ask before I delved to far into it. I'm not certain I fully understand what to do with NSFileWrapper in this case but I'll give it a try. My thought is to have a dictionary mapping each image filename to a NSFileWrapper. I may also need a plist of all image filenames so I can read that first and then read each of those image and store them in the dictionary of NSFileWrapper objects. I need to re-read the documentation again although it seemed the documentation for NSFileWrapper was pretty limited and didn't apply to this case where there's not a fixed number of files each with specific names. If anyone has links to better documentation for my other question about exporting the document type using Xcode 7, I'm still in need of help there. Thanks, Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
On Mar 19, 2016, at 10:18 , davel...@mac.com wrote: > > The downside I see for my app is that UIDocument writes out the data to a > temporary location and then moves it to the new location so I think my app > will constantly be writing out these image/PDF files that never change. Is > there a better way to do this so that the image/PDF files only get written > out when they’re first added (or changed if they do get changed). a. It’s not obvious that the unchanged files *are* written to a temporary location and then moved. The trick is to keep the original directory wrapper that you got when opening the file, and to preserve the individual file wrappers for unchanged components. (You can, for example, just delete the file wrappers for things that *are* changed, when they’re changed, then add the missing wrappers at save time.) The save mechanism then knows what has and has not been changed, and can optimize the save appropriately. b. Even if the files are copied, it’s not obvious that you need “a better way”. It may be fine to copy the files at every save. I’d recommend you don’t try to solve this problem until it forces itself on you as an actual problem. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com