views:

590

answers:

2

Hello,

I am writing a simple application to copy a set of images to the user's photo library so that the user may use them as backgrounds. The problem is that if the user runs the application more than once, duplicate images will be copied to the photo library. Given the restrictions Apple places on accessing the contents of the photo library, what is the simplest way, if any, to avoid writing a duplicate file to the library?

Ben

A: 

You can store the images data that have been saved in your application by writing them to a file or using Core Data, that way you know which have been saved and which have not. Y

Daniel
Actually, that was first solution that occurred to me. The problem with this approach is that if a user deletes an image, merely consulting a list of previously saved images will not reflect the fact that the file no longer exists, and the application will refuse to restore the file.
Ben
The basic problem is: if I know the name of a file, how do I tell whether or not there exists a file with the same name in the photo library?
Ben
Take this case, user chooses a photo from the library, you save it, then take its convert it to jpeg or png (which gets u the data) and you store that. Then when the user picks it again and you get the data the same way then you should be able to look if the bytes on the image data already matches the bytes of a previously stored image data, if it is then you know its a dup
Daniel
All the app does is copy all of the jpg files in a subdir of my app bundle to the photo library (PL). The user may cancel the operation, but does not have any way of viewing the files. Once the files are in the PL, the user may use them as backgrounds without the help of my app, which keeps my app simple. If the iPhone permits backgrounds that are not in the PL (does it?), then I could instead work only with an app subdir (which has fewer restrictions on file access), but that would require writing a custom interface (as assumed by your question) to view/select files.
Ben
how are you having the user export the pictures?
Daniel
Because there are only twelve images, which can be deleted more rapidly than they could be selected from an image picker, the user does not export the images. Instead, the images are copied programmatically from the application bundle into the photo library. This minimizes the size and complexity of the application by reducing it from a two-page, navigation to a one-page view based design. At the same time, it saves the end-user from the tedium of having to select each image individually.
Ben
A: 

This answer is somewhat belated, but a late answer is better than no answer at all. The answer is that there is no way to check the photo library for a duplicate image (at least within the constraints of the public API). The only way to write to the photo library is via the UIKit global function:

void UIImageWriteToSavedPhotosAlbum ( UIImage *image, id completionTarget, SEL completionSelector, void *contextInfo );

which simply writes the instance of UIImage to the photo library. None of its four parameters represent an additional, potentially identifying, object that might be saved with the image. Nor does the UIImage or the CGImage it wraps provide a slot for "metadata" of this sort. Of course, one can always subclass, but unfortunately there is no way to inspect the contents of the PL. The PL is a write-only persistent store whose contents, at least as far as the API programmer is concerned, are essentially anonymous. Like a black hole, the photo library has a "one-way surface."

Ben