Iphone store image (pitfalls ?) - iphone

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.

Related

Can I store a c++ binary file in iCloud?

I have an ios game mostly written in C++ which stores its game data in the standard c++ binary format. I would like to add iCloud support but I'm not sure if i can upload this kind of files to iCloud.
Is it possible? If so, how?
iCloud documents of your app or game can have any internal format you want - you don't have to use the NSDocument class.
Note that iCloud backups are not the same as iCloud Documents. Putting user data into the Documents folder will cause it to be backed up to iCloud as part of the device backup but will NOT cause it to be synced to other devices. For that you need to use the iCloud APIs to correctly coordinate the syncing process.
You can either save non-specific data that will be treated as a single item or "Documents" that users can delete one by one, when, for example, they are running out of space. You can see how this works by clicking "Manage" in the iCloud preferences.
If the data you need to store is not too big (a few kilobytes) I would suggest looking at the key-value store as well, which is MUCH simpler than the documents API. It is possible to store binary data there using NSData. The limit for the key-value storage has been recently raised to 1MB and 1024 keys.
Why not? Any file in the Documents folder of your application will be backed up on iCloud.
If this file cannot be recreated otherwise (for example it is a savegame, not a cache file), then I see no problem.
The documentation states:
Put user data in the /Documents/. User data is any
data that cannot be recreated by your app, such as user documents and
other user-generated content.
...
Every file or file package located in the Documents subdirectory (or
one of its subdirectories) is presented to the user (via the iCloud UI
in OS X and iOS) as a separate document that can be deleted
individually.
(http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html)

Document directory is good to store data or cache in objective c?

Friends i need to store more than 100 mb data which come in zip format and i get data after unzip this zip file and unzip data is more than 70 mb in size , so my question is that which storage location is good to keep this data, currently i am using cache but it gives memory warning on device when i writes data in cache and then after sometimes app gets crashed.
This zip file contain html pages and images.
i checked this link also but did't get answer to store thes html and images which comes in zip format from server.
Any small help will be highly appreciated.
Thanks in advance
Don't try to read this entire ZIP file into memory at once! It's not the permanent storage (Flash) on the device which goves you the memory warning, but you eat up the RAM. Yes, the Documents or Library directory is fine for storing your app data, just be careful with the memory management.
Like H2CO3 stated, the memory warning is indeed caused by reading it all into RAM in one chunk. Apart from that, be sure to follow Apple's guidelines regarding data storage. If the data being saved is temporary, be sure not to store it in your documents directory, otherwise your application might get rejected (Speaking from experience).

iPhone app got rejected due to data storage issue

My app was rejected due to data storage problems.
After googling, I got these ideas. Please confirm my assumptions are correct or not.
Store the SQLite db in the caches folder and set the "donotbackup" flag, which will stop the file being deleted by the cache clean system.
But what will happen to the db if I update the app to a newer version? Any chance to loss the db?
Keep the cache files like images etc. in the Caches folder.
Do we need to clear the cache with our code or the device will clear it automatically?
Then I am storing all the data(including images) in the application's Sqlite db file. So should I implement iCloud in my application?
You must use "do not backup" attribute to files that you would to keep, other files place to cache folder.
Cache folder will be automatically erased when application terminates.
Check this article
Developers forum
Apple documentation

Is there a limitation on the number of files in an iphone app?

Is there a limitation on the number of files in an iphone app?
My app will contain about 2000 or more text files.Would i be in trouble?
No, you should be fine, 2000 files isn't that many (more than usual but still not extreme)
The limit is probably the same limit as the directory structure can hold which is probably much much higher.
And even if you do hit that number, you can use subdirectories to hold your files.
NB If the files are all small they will be stored inefficiently - you might want to look into combining them into one file or using a simple database to store the data.
The Apple App Store Review Guidelines do not mention anything about a limit to the number of files an app can have.
The only section refering to size limits is section 2.15
Apps larger than 20MB in size will not
download over cellular networks (this
is automatically prohibited by the
App Store)
There is not a limit on the number of files you can include in your app, but including thousands of files does slow down app installation a lot.
Going with a database is one solution. Another option is putting your thousands of files into a .zip archive that you uncompress upon first run.

Managing iPhone app sandbox tmp directory size for caching images

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.