I want to store some photos that I take from a web service to my phone for the case when I don't have internet connectivity. I am storing data to a database but i have a question: should I store in the database the URL of the photo and the photo in a folder, or store the image in the database? The volume of photos shouldn't be great; something like 200-300 small pics, at approx 30-40kB each.
If you already have a database, i would organize my photos in database with only the path to the photo. And the photos can be stored on memorycard or on local disk.
The basic rule of thumb is to put big data objects like images right onto the disk and only reference the URLs. This might come in handy for loading/processing the images anyway.
30-40 kB per image is not that much, but then I'd consider 6-12 MB for the database quite extensive, especially it's probably the majority of your database volume.
I'm not real familiar with iOS. But my understanding is that it supports XML files. If the database is just being used to store the paths (instead of images), why not use an xml file to store the paths?
If you need the db, with small images, I don't see it being a problem if the phone is just using it. Either way, I don't think it'll be an issue. Someone else can probably give you a better answer as far as efficiency. That's outside my jurisdiction.
Store all the pics in document folder, and when there is no internet connection get them from document folder of your iPhone.
Related
I am wondering why storing user profile images as Data to user defaults is ill advised. The reason being: I have already created an app that has some people using it. The app requires that users create a profile, on which they can upload up to 6 profile pictures. The images get pushed to my back end and also are stored as Data to the app's user defaults.
I've read that it is better to save these images to the document directory and save the file path as a string to user defaults. Why is this exactly? Is it such a big deal that I should take the time to write code that will convert images saved as Data to user defaults on already existing devices to images saved to the document directory?
The "why" is easy. The UserDefaults is not a database. It's just a plist file. Either the whole thing is loaded into memory at once or it isn't. If it is, there are all your UIImage data objects sitting in memory. Memory is limited and images are big. Plus you waste time during loading and saving.
The "is it such a big deal" part is a matter of opinion. In my own opinion, yes, it is. That's because I've gone through this process, and I was glad I did. Yes, it's a pain writing migration code, but once you've done it you just leave it in place and your app is now handling data saving correctly forever after.
I must provide a solution where user can upload files and they must be stored together with some metadata, and this may grow really big.
Access to these files must be controlled, so they want me to just store them in DB BLOBs, but I fear PostgreSQL won't handle it properly over time.
My first idea was use some NoSQL DB solution, but I couldn't find any that would replace a good RDBMS and elegantly store files together. Then I thought on just saving these files in HD somewhere WebServer won't serve them, name them their table ID, and just load them on RAM and print them with proper content-type.
Could anyone suggest me any better solution for this?
I had the requirement to store many images (with some meta data) and allow controlled access to them, here is what I did.
To the cloud™
I save the image files in Amazon S3. My local database holds the metadata with the S3 location of the file as one column. When an authenticated and authorized user needs to see the file they hit a URL in my system (where the authentication and authorization checks occur) which then generates a pre-signed, expiring URL for the image and sends a redirect back to the browser. The browser is then able to load the image for a given amount of time (as specified in the signature within the URL.)
With this solution I have user level access to the resources and I don't have to store them as BLOBs or anything like that which may grow unwieldy over time. I also don't use MY bandwidth to stream the files to the client and get cheap, redundant storage for them. Obviously the suitability of this solution will depend on the nature of the binary files you are looking to store and your level of trust in Amazon. The world doesn't end if there is a slip and someone sees an image from my system they shouldn't. YMMV.
Some discussions in Stackoverflow say that storing the picture in DB is a bad idea (a because overtime, the number of images get large & may lead to app crash). So, either
a. the image can be stored in the iPhone itself & only its location can be stored in the DB
Potential Issue: The image might get removed (outside of the app) & the app might not be able to load them the next time
b. the image can be shrunk to a small size (say, 100*100 pixels) and stored in the DB
Potential Issue: will size be an issue if the image is shrunk to just 100x100pixels?
c. Doing both (a) & (b). So, small versions of the images will be stored in the DB and then, retrieved & displayed in the App, whereas, if the user chooses to see the original version of the image (whose probability is low), then that'll be fetched from the local directory & shown.
Your suggestions please? In my opinion, (c) seems a good option to go in for, in case (a) has the potential issue mentioned.
It really depends on where the images are coming from. Are they being downloaded from the Internet (or imported from the user's library / camera) after the user installs the app, or are they bundled with the app from the App Store?
If the images are being downloaded / imported, the best solution is to store images in the filesystem following the recommendations in http://developer.apple.com/library/ios/#qa/qa1719/_index.html
Basically, if the images cannot be replaced or recreated, store them in the <Application_Home>/Documents directory and do not set the Do Not Backup attribute. These items will be backed up to iCloud, and this data does persist for at least some amount of time even if the app is deleted from the device. (Remember that your users do not have unlimited iCloud space. Be responsible.)
-However-
If the images are bundled with the app, the best solution is to import them directly into your Xcode project and reference them from there. This way you know they are always available even if the user deletes and reinstalls the app.
I would definitely stay away from storing image data in the databased whenever possible. There are simply better, more efficient ways in most any scenario.
I don't know which is the most efficient way of organizing images downloaded from server. I will be downloading around 200 images on to my iPhone on request for download. Which is the most efficient way of organizing ? just dropping it as a file on the phone's memory or having it in sqlite (via coredata) after download ? which one is most efficient and easy to handle ? which access is faster ?
The rule of thumb is to put them (or any bigger binary data) onto disk directly, and if the whole app organizes its data with a database / CoreData, then put the paths of the images in there.
AFAIK , Iphone has minimum 8GB of memory. That will be enough for images. Also It depends upon the frequency of image downloads. If you download 200images daily then u need some application that will push it in your sqlite db. Advantage of this will be your all image files will be inside a single db. No scattered images. But if you want to store only 200 images then i would recommend it store on your phone memory with some image managing tool like ACDSEE in windows, that will help you viewing images in slide show or what ever manner you want.
I'm developing an app that needs to cache some images from the web the images are likely to be 100x100
I just need to know which is better:
Store the images as files in the iPhone file system
Store them as blob in a sqlite Db along with other data already saved on the database.
Appreciate your help.
Storing images in the database is definitely not recommended by Apple, the filesystem is actually really good at locating files (images in this case) on the disk, which makes it the best solution for saving images. These were the exact same words an Apple technology evangelist used in the iPhone Tech Talk World Tour in Paris. If it are only a few images, you might get away with it, but when the number can potentially become quite large, files is the way to go.
Besides, you can use the lazy loading methods to grab the images of the disk, this will delay loading the image from disk to when it really is needed.
[UIImage imageWithContentsOfFile:[[NSBundle mainBundle] pathForResource:#"image.png"]]
Edit: imageWithContentsOfFile does not load the image at once, thus not locking the thread, neither does it cache the image. The other method imageNamed: does lock the thread and loads the image at once, on the bright side, it does cache the image.
From past experience, storing (and retrieving) images from the file system should be a bit faster than from the DB. As for ease of handling and maintenance it only depends on what you're more familiar with: SQL scripts or iphoneOS file system functions.