I want to make bigger application that stores multiple avatars for each registered user (different sizes of the same image).
Should I store original images and resized avatars in the same directory (small_avatar and big_avatar stored in the same directory) or should I keep different sized images in matching directories (small_avatar goes to small_avatar directory, big_avatar goes to big_avatar directory etc.)
I do not there will be any difference but if you try to check some of the world`s largest websites you will see that they are keeping all in the same directory just with different prefixes. My guess is that saves some load time but I seriously doubt it is significant for the user or server.
Related
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.
In our iOS app we have close to a hundred image files in resources bundle. Now we want to make them network based since the images may change (updated/no longer needed/additions) at any time. We are debating at what approach would be optimal. From what I have read, I understand that the resource bundle will not be editable on the device. So, when I start the app, I will check from the server if there are any image updates. If so, I will download the changed images and then save them to documents directory. Then in the app, for every image, I will basically have to check if it is in the resources bundle, then grab it from there. Else pick it from documents directory and display it.
Another approach is I don't have anything in the resources folder, I download all images on app launch from the server and store them to documents directory and then on, download the changed files at subsequent app launch. Here I am eliminating the check on resources folder if an image is present or not and my app bundle size would be reduced.
The third approach would be to copy the files from my resources directory to the documents directory on first launch and thereafter continue from documents directory.
Any suggestions on what would be a better approach or all of them would be similar from the performance point of view?
IMO, option three offers the best balance between eliminating needless code and preloading as much data as possible. You don't want to make the user wait for 100 image downloads when the app starts the first time, so pre-load as many as possible. The copy code is simple and will only be used once. So that eliminates the runtime checks you'd have to do with the other options.
No worries, performance will not be an issue, unless you use a particularly unwise image lookup algorithm.
Filesystem traversal should be pretty fast for such a small amount of files.
Before implementing something yourself, I would recommend looking at something off the shelf for Image Caching. Namely EGOImageView from EnormEgo.
I have used it in several applications which are dependent on grabbing images from URLs. It handles everything for you, you just set up a 'background' image for it to show while it goes about it's business of grabbing the URL based image in the background. The second time you use it, it's available immediately. Definitely gets my vote for ease of use...
p.s. it's free to use
I have a fairly image-intensive iPhone app, and I'm looking to store remotely downloaded images locally in the app's sandbox tmp directory to avoid unnecessary network requests. Is there a limit to the total size of the files stored in an app's directories, or does the app need to manage that? How would the app determine the size of the files in the tmp directory?
Also, if the app needs to manage the size of the cache, I'd like to implement some kind of cache policy to determine which files get invalidated. How would I go about doing this? If I want to implement a basic LRU caching policy - invalidating files that have been used least recently - it seems like I would need to store access counts for each image and store that on the disk as well, which seems kind of funky. I suppose an easy size management policy would be to simply completely wipe the cache each time the application terminates.
Also, what's the difference between using the directory from NSCachesDirectory versus NSTemporaryDirectory? The Apple docs mention both, but don't talk about which one to use for what type of files. I'm thinking the NSTemporaryDirectory is more like a Unix /var/tmp directory, and used for ephemeral data that can be wiped out at anytime. Seems to me the NSCachesDirectory is more appropriate for storing cached images, since the files could be needed across multiple app lifecycles.
All temporary directories are local to your application; any of them will work and there is no artificial limit to the size of their contents.
A persistent LRU cache policy should be both sufficient and relatively easy to implement.
I have an application
that loads images from the net and stores it on the app's documents directory
so when the users starts up the application and doesn't have internet they still can use the application.
but my question is .. does the iphone controls that document directory ? does it clears itself after a certain period or after a certain amount of memory is used .. does the documents directory have a limit ? and what if the limit is reached ?
anyone can clear that up ?
In "Commonly used directories" section in application programming guide you can see that date can be stored in several directories: Documents, Library/Caches and tmp. Files in Documents and Caches directory persist between launches so you can store your data in either of them.
One more thing to consider is backup process - Documents directory is backed up by iTunes and Caches is not so storing large files or files that change a lot in Documents directory may significantly increase device synchronizing time (see "Backup and restore" section for details).
As answered here your application disc space is limited by 2GB, not sure what will happen if you hit that limit though.
What should I do? I have more than 1600 Images. Should I store them directly in the application or store them in a database. Right now I'm storing in Application and my application gets hanged so please Help
Exact Duplicate: User Images: Database or filesystem storage?
Exact Duplicate: Storing images in database: Yea or nay?
Exact Duplicate: Should I store my images in the database or folders?
Exact Duplicate: Would you store binary data in database or folders?
Exact Duplicate: Store pictures as files or or the database for a web app?
Exact Duplicate: Storing a small number of images: blob or fs?
Exact Duplicate: [store image in filesystem or database?][7]
As with most issues, it's not as simple as it sounds. There are cases where it would make sense to store the images in the database.
You are storing images that are
changing dynamically, say invoices
and you wanted to get an invoice as
it was on 1 Jan 2007?
The government wants you to maintain
6 years of history Images stored in
the database do not require a
different backup strategy. Images
stored on filesystem do
It is easier to control access to the
images if they are in a database.
Idle admins can access any folder on
disk. It takes a really determined
admin to go snooping in a database to
extract the images
On the other hand there are problems associated
Require additional code to extract
and stream the images
Latency may be slower than direct
file access
Heavier load on the web server
This answer is quoted from "Conrad"
As pointed out previously, it depends.
One of the most common practices is to decide on the basis of the images' size.
For very small images, such as thumbnails, icons etc, you certainly store them in the DB, and you can store them as a field of an entity (say a contact).
For medium sized images, it still makes sense to store them in the DB. However, you have to decide by yourself what is a medium sized image (my threshold is 1 MByte), and you should store the image not as a field of an entity: you should create an image entity and a relation to the interested entity (say the contact).
Finally, very large images should not be stored in the DB. You store them on disk and store on the DB their pathnames. This is necessary owing to the different latency and access time of the hard disk versus the DB. Indeed, it is the DB fast access through indexes that allows you to store medium and small sized images in the DB, but huge images should be handled differently.