In my iOS app, I need to keep track of which sequence numbers have already been received from the server and which sequence numbers need to be retrieved. I want to be able to store this in case the app terminates or crashes.
I am trying to decide which storage method I should use: core data, plist etc.
The list of sequence numbers is dynamic and can change a lot. Any pointers on how to decide on storage will be greatly appreciated.
Without more exact details in your question it is hard to give you an accurate answer. However, what can be provided is some insights on the benefits / downfalls of using the storage systems listed above.
I would stay away from using a plist since your data is dynamic and can change a lot. Every time you save to a plist you will need to overwrite the entire file. This means to change a single value you must retrieve all values, make a single change, and save all values back to the plist. This isn't a modular way of doing such saves and can become problematic if you have a lot of information that is changing and needs to be saved all the time. On the up side - setting up a plist save / read write structure is very easy and fast.
NSUserDefaults should be used for just that. Saving user settings and preferences. It is really easy to use NSUserDefaults, but may become very problematic in the long run if you data is very large. Values returned from NSUserDefaults are immutable too. This may or may not be a problem for your needs.
CoreData may be overkill for what you're doing, unless your sequence numbers are very large. Personally, I would go with CoreData knowing how it can handle dynamic values and how fast it is to save objects compared to the plist and NSUserDefaults. The down side is CoreData is a bit of a learning curve. Unless you have used it before, it is easy to go down the wrong path using it.
As far as pointers on which storage option to use, do some research. Make a list of pros and cons of each storage option. Ask yourself how big your data may get, and what is the best solution. You already know the data is dynamic and may change a lot. Look at the performance of each storage solution.
Here are some helpful reading material links straight from Apple:
Plist
NSUserDefaults
CoreData
Related
Background:
I have an app that retrieves a list of restaurants from a database, each have an individual array of basic information about them (hours, name, address, etc). I would like to retrieve that information from the server on the apps first load, but then have it stored within the app itself, with either NSUserDefaults or Core Data, since the information is unlikely to change. The max number of restaurants I would be storing is about 25, is that a small enough data collection to use NSUserDefaults?
I have looked at similar questions with storing data with over 1,000 records, but I am only storing a small array.
Question:
NSUserDefaults is much easier to use than Core Data, so if possible I would like to avoid using Core Data. In my case, will there be a performance problem if I am storing my list of restaurants in NSUserDefaults instead of Core Data?
Depends on the
size
structure of data
requirements re integrity of the data
Just an Array of 10 or 20 "restaruants" I would certainly store in NSUserDefaults. But only when I am sure that this will never become more complex. Because when you later extend your model but started off with NSUserData then you may remain with NSUserDefaults just because you avoid migrating it to Core Data during the upgrade of an installed app.
So for more complex structures including references and when you have further plans with your app towards more functionality that may require more entities, then you should go for Core Data from start.
BTW, it is not that complicated as you may think.
However, instead of abusing NSUserDefaults, you could simply write an NSArray to file using -writeToFile:atomically: and -initWithContentsOfFile: to read them in.
NSUserDefaults is not intended for data, it's for storing simple key-value pairs like user settings and flags. Core Data is a bit hard to learn at first, but definitely worth it, even for simple applications.
If it really is a small, simple data set that won't change very often, you can also store some data in a local plist (i.e. save NSArray or NSDictionary to plist using writeToFile method). This isn't very different from using NSUserDefaults in terms of performance, although I think it's cleaner and easier to manage. If it never changes you can also include the plist with your app resources in XCode by creating a plist file and filling it in with your data.
Considering the amount of the data, user default or a specific plist/json file are all good. CoreData is definitely overkilling.
I have a simple problem to solve but want to know which is better pattern to use and understand the reason for the choice.
Problem :
I want to create a utility which developers can use to check whether the feature should be enabled/disabled depending on the server package version.
eg : server package versions like 10.234, 11.1 etc and client versions 9.3,10.2 etc
Validation on client to see min version on server package for feature to be enabled/disabled.
example data would be like "search lookup feature >= 10.234". And sometimes complex situation need to even check client version whether the feature should be supported.
edit:
Note: Application is very huge and memory is full for most of the time. (thousands of records of organisation data.) So memory is bottle neck.
Just it even flashed to mind to used macro as to do all comparisons and returning value.
I think Plist would be heavy as all the objects would be in NSDictionary and even to access one object, I'll be holding all data.
I want to reduce memory overhead and comparisons too.
For Light data, Use NSUserDefaults or PList. SQLite and Core Data is overkilled.
Updated Answer for Updated Question:-
For server package versions/your app version or other light weight data, you can always use NSUserDefaults or PList.
For records of organisation data, you might want to consider Core Data.
Yes, you can use 2 different types of persistent storage inside your app.
If your data is never going to change, or grow you better use NSUserDefaults, plist or csv file. If you think that user should have the ability to change or add new entries to this data file you better go ahead with CoreData
Plists, csv, and flat files have low overhead for small to medimum amounts of data (and for data where you use all or nearly all) of it.
Systems that only use some of the data on any given run AND have large amounts of data AND have the data structured so SELECT can use an index can be faster (lots and lots faster) with a database (SQLite, or CoreData with the SQL Persistant store).
As a gut feel I expect your problem could be handled well by SQL, but only if you are talking about 1000s of configurations not 10s or even 100s...but you would be better served by benchmarks then my guesses. Go code :-)
Im working on a multiplayer turn based game in xcode for iphone/ipad im considering my options when it comes to where to save users details such as name / points ect. I was considering creating a plist and storing data in this also i have considered nsuserdefaults and also core data.
Basically majority of the time the user will be adding new details on every launch however this will not be the case 100% of the time.
What would you guys consider the best approach?
This really depends on multiple factors:
How much data is it going to be saved?
How fast the data needs to be loaded?
I suggest you create a serializable object, that conforms to NSCoding protocol. There is also an option to save this as JSON or like you noted, plist.
I think Core Data is too much boiler plate, if this is all you are storing. NSUserDefaults is fast enough and already prepared for you to use.
I don't think someone can give you the correct answer, I suggest you experiment with all the options and see which one is the best for you.
I am making meeting app and I need to store users data. I am not need to use sql for now because it hard to setting it, so I need place to store data, I not want store users in RAM, so where can I do it? It not necessary to cache images for now, by if I can add it in this place in future it will be great.
Here is what I believe you are asking:
I am developing a meeting app and I need to store some user data.
I dont want to use sql for because its complex to do, so I need
a place to store my data. I not want use up unnecessary RAM,
so where can I store the data? I currently dont have any need
for cacheing images but perhaps in the future.
Not using CoreData/SQL because its hard to understand is not really a good reason. It was the native built in way of data access within iOS and it is the recommended way.
This is a very broad question since we dont know what your data looks like and if there are relationships between them, how large your dataset is, etc.
If its a small enough data list maybe you can look into using a PLIST. It will be a list of values with a key to each one. If its really small you can use NSUserDefaults If its static data, perhaps storing them in a NSArray or NSDictionary
I am making a few apps that all require pre-set data to be loaded into the app. This data does not need to be changed or altered in any way as the app progresses - it is simply the data that the app runs on (to give more detail, it is questions for a quiz app). I have elected to use .txt files to store this data, but I wanted to know if this is the best way to do this? Text files allow me to easily change the data without coding. I can also copy and paste from normal documents. Is storing data in this way a good practice, or should I try to hard-code the data/ use a p-list?
The answer to this question depends a lot on how you want to implement your code.
.TXT files might work well, but what happens to the memory requirements when you pass a certain number of questions (e.g. more than 100, or even 10?). Also, what kind of structure are you using in memory to hold the question? If it's a NSDictionary or NSArray, perhaps a .plist file might work better for you.
Raw NSData, or some proprietary format, might work best if you have a lot of non-modifiable questions and you want to try to compress the data down as much as possible (which is a consideration on the low memory / low disk space iPhones).
CoreData might come in handy if you want to store a lot of questions and answers, especially those that users are manually entering in or managing.
For something like this, I will typically use JSON files, and then use Apple's JSON parsing framework.