Now I save the cache in NSUserDefaults. As before, I used the small array, the NSUserDefaults for me. Now when you save large array in NSUserDefaults application freeze. What are the alternatives to the cache arrays in objective - c for iOS?
UPDATE:
I want to save 30-60 HTML file into an array. and then the array cache. Stores an array to NSUserDefaults long. that is better for me to use? the database? nscache? if a database, what?
You can write the HTML data as NSString into a NSDictionary and save it in a .plist file in the documents directory. You would be able to edit, append and delete your data as you want using this approach.
If you are looking for a caching pupose,you can use NSCache and iOS manages the memory.But its not guaranteed the availability of data always.iOS may remove data and free up the memory because of memory warning.
If your data is higher in size,you should save the data to document directory instead of directly saving to RAM (Saving to Objects use RAM memory).Write data to a file or use plist.
Related
I want to save photos from photo gallery in my app and after show them in collection View. Is there some way to store this image in array in UserDefaults?
In NSUserDefaults you just must save Dictionary Objects, you must not save big amount of data.
To save big amount of data like images you should take a look to the Sandbox.
Take a look to the tutorial How to save in Sandbox
I would use Core Data and/or store them locally.
see the responses in:
Saving Picked Image to CoreData
NSUserDefaults should only be used for the applications default values.
I have a simple NSArray of Jsons in my app. It is an internal cache for my backend searches. That is if a user searches for objects, that gets thrown into my NSArray and should be saved. That array can thus get large, several thousand entries.
I think Core Data, Sqlite etc. all seems overkill to just save that NSArray so it doesn't get lost when the user closes the App. Meanwhile, I understand it is a misuse to just dump this NSArray into NSUserDefaults each time it is updated. Or is it better to write it to a file each time the NSArray gets updated and load it when the in my appdelegate when the app starts?
What is the recommended approach?
As discussed in the comments, I recommend Core Data as a solution for this situation.
The easiest way is to use NSJSONSerialization to read from and write to a file.
There are three ways to write persistently to the device in iOS that I'm aware of:
NSUserDefaults
Custom Objects - Archived and Written to a PATH in NSDocuments
SQLite
Apple provide a mechanism to prevent iCloud backups with #2 i.e.
- (BOOL)addSkipBackupAttributeToItemAtURL:(NSURL *)URL
I use NSUserDefaults to store three images but to adhere to iOS Data Storage Guidelines -
How do I prevent Backups with iCloud with NSUserDefaults?
This question has been asked several times on SO but there is no clear comprehensive answer yet.
Is there a such a function or do I have to change storing images using method #2. I was hoping something convenient like:
- (BOOL)addSkipBackAttributeForStandardUserDefaultsKey:(NSString *)
exists.
There's no mechanism for this. NSUserDefaults is not intended to be used for saving app data. It's there to hold user preferences and other settings the app needs, but isn't intended as a full data persistence system.
It's not accurate to say that this "...[Apple's] mechanism for storing data can't adhere to it's own guidelines" because that's not the purpose of this API. In this case specifically, if those images should not be backed up, then that's absolute evidence that user defaults is the wrong place to store them.
You should save the images to files. If you have UIImage, this is simple. UIImage conforms to NSCoding, so it's easy to convert to/from an NSData. And NSData includes convenience methods to read/write objects to files. If the file names might change, you could reasonably put the file names in user defaults. If the file names are known in advance and can't change, then there's no reason to store them.
I'm looking for a faster way to save user preferences than the NSUserDefaults. I've found that if the app is killed within around 10 seconds of writing to NSUserDefaults, it will not be saved permanently. I use the defaults to save paths to custom ring tones, paths to custom images, map coordinates, and basically just user defined preferences. Is using core data the better option? SQLite? What's accepted as the fastest and most lightweight?
You need to be sure to call synchronize to save the data immediately.
[[NSUserDefaults standardUserDefaults] synchronize];
From Apple's class reference:
Because this method is automatically invoked at periodic intervals,
use this method only if you cannot wait for the automatic
synchronization (for example, if your application is about to exit) or
if you want to update the user defaults to what is on disk even though
you have not made any changes.
And to answer your second question, it really depends on how much data you want to store. NSUserDefaults is designed to store very small amounts of data (for preferences) like the state of a toggle switch, etc. You can get away with storing the paths to images and ring tones here but it isn't exactly advisable. By that I mean you can, but probably shouldn't.
Core Data is a much better approach if you plan on storing many of these paths as it is very scalable and performs very well. So overall, if you need to store a lot of data, user Core Data, or as another alternative store the paths in a plist in the documents directory.
I saw in other posts that it is O.K to store small image files (less then 50 kb) as a binary data inside core data. is it true for sound files that are less then 20 kb?
Thanks
Shani
There's no difference between sound files, image files or any other binary data as far as Core Data is concerned. Under 20kB I would store in Core Data unless you have a good reason not to (such as caching as mentioned), but I would store them as a separate entity if you are not accessing them every time you access an object.
The general rule of thumb I've seen mentioned is <10kB store on the entity, >10kB but <100kB store in a separate entity and >100kB store in the file system.
I store data like this in the file system and I keep the path to the file in my core data object. This lets me optionally use a class that caches lookup of the images that can be emptied if the program receives memory warnings.
You should read the apple's "Core Data Performance" document, specifically the section on Large Data Objects.