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).
Related
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.
I am working an app which stores some large amount of data (hundreds of mbs) in application's own library.
can anyone tell me if there is any size limit for an app to store data?
I also want to know the good method to store my data.Currently i am using pList to store name of my data files and the actual files are stored under "Document/"..
Should i use Blob or any other suggestion ..?
Not so sure but you can have a look on it - Memory Management.
For saving large amounts of data you should probably look at Core Data or SQLite (a good source is Mobile Tuts, plist wouldn't be a good choice. And so far I don't really know if there is a limit but if the total amount of data saved in your app is over 500MB it would be very unresponsive, so maybe you should save it to a server or something.
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.
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.
My problem is that my application size is very high,
is there any idea to reduce size of application?
if i make application without content and content is uploaded my server then how i sync the application with content put on my server?
i want to know that once user download application after that when he use application then we stream the content and save his document folder.
once user stream then never required for streaming.
is it possible????
Thanks,
Reducing the size of your application depends on the TYPE of contents of your application. I highly doubt that the application code is the cause, and since you did not mention what they are I am assuming they are some kind of resource.
If your resources are images, try to use image compression programs. Or convert them to smaller sized images or optimize the images.
If your resources are documents / text files / files that have a high compression ratio when zipped. Then you can try to zip your resources and access them inside the compressed file (this will mean additional coding, and probably slower in performance).
These are just examples.
It is not advisable to stream large contents because it uses the network bandwidth which, depending on the user's plan, can cause a big spike in phone bills.
Yes it is possible that you can download your content and can save to application's document folder, when user runs your application for the first time. Thought it may affect the first impression to your user as it will take time to download.