I need to store data that the user can add, they can add an unlimited amount. They can either be NSStrings or UIImages. I have looked into NSUserDefaults but it seems that it is used for small amounts of data such as settings or preferences.
What would be the best/most secure way to store the users information so that when they close the app it is still in the app. The data populates a UITableView and is a NSMutableArray.
Whats the best way to do this?
There must be a dozen ways to store user data in iOS. Here are several:
Property lists: An easy way to store a graph of common data storage objects and containers. This is a good place to start if you're just learning the iOS ropes.
NSKeyedArchiver and NSKeyedUnarchiver: Provides an easy way to serialize and deserialize your objects to/from a chunk of data, which you can then write/read using NSData's methods.
NSFileHandle: Read and write data in whatever format you like using a nice Objective-C API. More generally, you should read up on the iOS file system.
UIDocument: A full-featured starting point for managing user data, including syncing with iCloud.
Keychain: Not a general purpose data storage mechanism, but if you're storing sensitive items like passwords, credit card numbers, etc., you should use the keychain API.
POSIX file API: Good old C file handles with the read and write functions you learned in college, if you went to college before Java was a thing.
SQLite: According to the web site: "SQLite is the most widely deployed SQL database engine in the world."
Core Data: A powerful (but also somewhat complex object graph manager. This is a good choice if you have many different pieces of related data to store.
What would be the best/most secure way to store the users information
so that when they close the app it is still in the app. The data
populates a UITableView and is a NSMutableArray.
Best is subjective -- you'll need to consider your needs and look at the various options. For many people, though, best means least painful or easiest to learn. As mentioned above, property lists may be the way to go in that case. If your array contains simple data (strings, data, dates, numbers) in standard containers (arrays or dictionaries), your file I/O can be as simple as something like this:
// writing
[myArray writeToFile:somePath atomically:YES];
// reading
myArray = [[NSArray arrayWithContentsOfFile:somePath] mutableCopy];
You should use Core Data. There is a very good, free beginners course online avaibable called cs193p, see here http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/287, it is also available through iTunes U. It's really worth the time to watch and easy understandable.
If you have only some array you can check plist. is verry simple and powerful.
https://developer.apple.com/library/iOs/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html
This is a great resources: Should I use NSUserDefaults or a plist to store data?
Related
I am new in ios programming.
I want to implement a dictionary. I have csv table with words and definitions. What is the best way to store my data in app? Is it better to use some frameworks as Realm?
To store data you can use either UserDefaults or Core Data. UserDefaults is used for storing small pieces of data such as settings, preferences, and individual values. While Core Data to used to store a large list of elements.
In you case I think you can use UserDefaults.
If you would to create a DataBase, you can use a local JSON (see this tutorial) or you can use .plist
(1) xx.plist : suit save basic data eg:NSArray NSDictionary ect.
(2)NSUserDefaults : suit some active signal information.
(3) xx.geojson : suit json string data in local
(4)NSKeyedArchiver: suit custom data .
(5)coredata : suit the table list data . you could use sql .
Realm really is the fastest database, but 99% happened Core Data with excellent documentation from Apple is a better solution, and even more so if you are a beginner it is better to study the native solutions offered by Apple and then the experience goes to third-party solutions. In this particular case, I expect that it will be better to use Core Data because if you have a large vocabulary UserDefaults it will be a long process the request
when I develop an iPhone App (Time Tracker, ToDoList etc) I never know whats the best way to deal with the data. Once I used a plist, next time sqlite or CoreData.
How do you decide whats the best for your project?
(Only talking about data management)
For Example if you want to develop:
Time Tracker App > Is PList your choice?
RSS Reader App > CoreData?
Photo App > sqlite?
EMail Client > ?
For a beginner can you point me roughly to proper directions?
(I know it depends a lot on the App and what you like to do with
it but any thought will help)
I'm far away from developing complicated apps, they are still pretty simple.
Thanks for help,
Marc
You can use these rules of thumb to decide what storage model will work for your app.
If the data fits in memory entirely and is relatively unstructured, use plist
If the data fits in memory entirely and has tree-like structure, use XML
If the data does not fit in memory and has a structure of a graph, and the app does not need extraordinary query capabilities, use Core Data
If the data does not fit in memory, has a complex structure, or the app benefits from powerful query capabilities provided by relational databases, use sqlite
If the data must be secret (e.g. a password), use keychain.
Note that these choices often overlap, because multiple storage models will fit the same app. Your final decision depends on your personal preferences - you pick a technology that you understand better.
There was a very good question about sqlite vs. Core Data on Stack Overflow, you may want to read through the answers to that question.
My rule of thumb for each of those would be:
Time Tracker App > Core Data
RSS Reader App > Core Data
Photo App > Core Data
EMail Client > Core Data
Though in each case there would be things you would store on the file system. For instance, the photo app would obviously put the actual photos on the file system. The text of the emails would be on the file system etc. The actual RSS messages might be text files too, but with meta data in Core Data objects.
At some point, you might find that the data you are storing is outgrowing the scalability of Core Data. At that point you would consider moving to SQLite.
The point is that Core Data is so easy to use and so superior to the alleged lighter weight alternatives, why wouldn't you use it?
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.
What is a good way to store many key/value pair entries in a mobile (iOS) application, such that they can be easily exported/imported?
I have considered a single large JSON file - would this be too slow/large with 200,000+ entries?
I have also considered CoreData - but could the data be moved easily via, for example, email?
Think of an address book. Contacts can be easily imported/exported, what data storage model would be comparable?
Thank you.
EDIT: Examples
Notes - be able to select and view short notes in a table. Each note is < 100 characters.
Saved bookmarks - each bookmark is stored in a table.
I have considered a single large JSON file - would this be too
slow/large with 200,000+ entries?
I don't know. I can make a guess. The guess would be yes, it's both too large and too slow. However, you can always test it to find out.
I have also considered CoreData - but could the data be moved easily
via, for example, email?
That depends on how you want to share the data. You call email easy?
Core Data is a framework. You can use any type of backend you want (you can even write your own). The most common is probably SQLite.
If you use Core Data, you can keep the data files in a separate subdirectory and copy them just like any other file.
However, if you want to share data via an online service, you may want the ability to import/export JSON files.
If you are talking about synchronization, then that's a different beast entirely.
Basically, there is no single right answer. You have to assess your requirements, and then determine which solution meets your needs.
On the surface, it seems like using Core Data would be a good fit, but it depends on how you want to use the data in your application. Only you know that answer.
I'm a new developer. Recently, I'm developing a note app on iPhone with Evernote API. I have read many pdf, such as Document-based application.pdf, evernote-api.pdf and so on. But all these do is teach me how to sync with Evernote and how to design the document class. No one talks about local store mechanism.
I have designed a local store mechanism by myself; here it is:
Store all notebook/tag info in a plist file, such as which note in which notebook, which note has which tag, all of notebook/tag/note is represented by unique guid in plist.
Store each note content in their own file, with the note guid as their file name. That means however many notes the user creates, there will be the same number file on disk.
How about this local store mechanism? Is it good or bad? Any suggestion is welcome.
What's more, should I use Core Data (database) in my project?
And how can I sync with Evernote?
The most popular way to do it is to use CoreData framework. It makes easy way to store different values of your Data Model in sqlite file in local storage of device. Look at this tutorial from apple.
You have a valid approach. I think it's especially good, if you expect big document lengths. If you only expect short notes, you can use any of these: coredata, nsuserdefaults, basic nscoded arrays, textfiles, etc.