问题
I have an app that reads JSON into in-memory objects. I have one object representing the User and then an array of custom objects. This array is ususally 20-50 objects but can be up to 7-800 in rare cases.
I've read some threads about this, but find it hard to pick, since all i want to do is cache this locally, nothing more, so that i can fetch less from the server.
I can see three solutions:
NSUserDefaults. Not sure how app performance is affected by large array
CoreData / MagicalRecord. Seems nice but a bit complicated
Plist with NSCoding/Decoding
Custom solution.
I am leaning towards NSUserDefaults or Plist since it seems easiest, and i only want to read to and from memory when the app starts/exists. However, is there any issue i should know about, like performance or app startup time when storing so many objects? Is there other reasons for using MagicalRecord?
Pointers much appreciated.
EDIT: Added the plist/NSCoding choice, had forgotten.
回答1:
Good day, my friend, U have a good question let's understand that it is better to use:
NSUserDefaults - usually use for example for definition of some Settings, Accounts, whether definitions the application, generally a global variable for easy storage and access to data was opened
Plist - Small amount of data that do not need complex query, editing not a large number of fields is suitable for storage also, The matter is that arrays and dictionaries at serialization in a plist are passed recursively, that is, only one more level of an enclosure on each massif or the dictionary in other container turns out. From here also restrictions on contents follow: only the types which are giving in to serialization.
Coredata/SQLite - Big amount of data which need Structured Query, I think, you have to ask the question "why I shouldn't use Coredata here" first of all. And having a little understood you will understand that the Coredata is ideally suited for storage of any types and volumes of data.
MagicalRecord - library for simplification of work with core data, its advantages(Clean up my Core Data related code, Allow for clear, simple, one-line fetches,Still allow the modification of the NSFetchRequest when request optimizations are needed) I don't recommend to use if you don't understand as the Coredata works
RESULT : If in fact you need to store some key value and you don't want to bother with knowledge of core data and you have no time for studying, use plist for your data. If you want to store something more difficult and more volume - only coredata. I personally recommend to use coredata, you are convinced that it is easy and convenient, it is necessary to spend time only.
use plist info
use core data info
Good luck, make a right choice, I don't understand why someone down vote your question, the question really good and on it is the concrete answer, +1 from me...
回答2:
You could write a small .sqlite database, this is permanent and still easy.
Core-Data is quite powerful, it's not that hard to setup, and it'll come in handy later. If you know you might need it later, might as well do it now. This is the solution I suggest as the best one. CoreData is much more than data persistence and won't be a waste of time.
You could also save this in a .plist file (or any kind of file really). I think this is the fastest and easiest solution right now for you. Not the cleanest in my opinion though.
I strongly suggest you don't use the NSUserDefaults though, they're not meant for that.
回答3:
Absolutely agree with @Zil - go for CoreData. Chances are, you're going to be using it at some stage, so it won't be a wasted learning curve.
Assuming you can identify each of the 800 custom objects with a unique key, then all you need is a single table with a key and a value, and you can retrieve your data. Depending on how long this takes, you probably want to do this in a background queue, and update the UI when you're done.
Here's the tutorial that got me started http://www.raywenderlich.com/934/core-data-tutorial-for-ios-getting-started
来源：https://stackoverflow.com/questions/35056899/nsuserdefaults-or-something-else-when-storing-large-arrays