UIImagePickerController - how to save image to core data?

Question

I have an app, which uses the UIImagePicker to let the use take a photo or choose a photo from the gallery. The picking and displaying works so far, but I need some guidance what to do and how next. Here's my delegate method:

- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info {

    UIImage *chosenImage = info[UIImagePickerControllerEditedImage];
    self.userImageView.image = chosenImage;

    [picker dismissViewControllerAnimated:YES completion:NULL];    
}

So, the captured/selected image is displayed nicely in an UIImageView .

What is the best way to save it? Save the image itself to Core Data, or just the URL in the filesystem? How can I obtain the URL in the filesystem? Does it matter, if the user took the photo, or select it from the gallery? Any hints, ideas appreciated, thanks.

Answer 1

You can save image in core data by converting it to NSData object. And when you want to show it back to UIImageView you have to convert it back to UIImage Object. You can do this easily by this way.

NSData* data = UIImageJPEGRepresentation(myImage, COMPRESSION_QUALITY);

And by this way you can convert data back to image

UIImage *image = [UIImage imageWithData:data];

This was the way to convert image to data and vice versa. Where you should save this image will depend on size and requriement.

You can save image to core data but that will make your core data object to consume more memory. If you still want to save image in core data create seprate entity for image and and create a reference for the image in othere entity, in this way by faulting will save some memory.

You can also save image in file-system and save there urls to core data as strings.

Answer 2

According to Apple docs : ( https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/Articles/cdPerformance.html )

Large Data Objects (BLOBs)

If your application uses large BLOBs ("Binary Large OBjects" such as image and sound data), you need to take care to minimize overheads. The exact definition of “small”, “modest”, and “large” is fluid and depends on an application's usage. A loose rule of thumb is that objects in the order of kilobytes in size are of a “modest” sized and those in the order of megabytes in size are “large” sized. Some developers have achieved good performance with 10MB BLOBs in a database. On the other hand, if an application has millions of rows in a table, even 128 bytes might be a "modest" sized CLOB (Character Large OBject) that needs to be normalized into a separate table.

In general, if you need to store BLOBs in a persistent store, you should use an SQLite store. The XML and binary stores require that the whole object graph reside in memory, and store writes are atomic (see “Persistent Store Features”) which means that they do not efficiently deal with large data objects. SQLite can scale to handle extremely large databases. Properly used, SQLite provides good performance for databases up to 100GB, and a single row can hold up to 1GB (although of course reading 1GB of data into memory is an expensive operation no matter how efficient the repository).

A BLOB often represents an attribute of an entity—for example, a photograph might be an attribute of an Employee entity. For small to modest sized BLOBs (and CLOBs), you should create a separate entity for the data and create a to-one relationship in place of the attribute. For example, you might create Employee and Photograph entities with a one-to-one relationship between them, where the relationship from Employee to Photograph replaces the Employee's photograph attribute. This pattern maximizes the benefits of object faulting (see “Faulting and Uniquing”). Any given photograph is only retrieved if it is actually needed (if the relationship is traversed).

It is better, however, if you are able to store BLOBs as resources on the filesystem, and to maintain links (such as URLs or paths) to those resources. You can then load a BLOB as and when necessary.

So, depending on the size of the image, you can either save the path or the image in CoreData.

To save your UIImage, you have to transform it in NSData :

NSData imageData = UIImagePNGRepresentation(myImage); NSData imageData = UIImageJPEGRepresentation(myImage, QUALITY);

Then you can save it at a path you choose :

[imageData writeToFile:fullPath atomically:YES];

I tend to always use path, even for small image, to keep continuity on how my data model works.