Advise Where to Store Data for iOS App

Advise where to store data for iOS app

As the first comment says, your question is quite large.
When you say 'one form on several view', I consider it as 'one form per view'.
Keep It Simple S... ;)
(Except if you use page control for your form.)

Basically, you have three ways to store data :

• NSUserDefaults :
  Store data in Dictionary for later use
• File :
  Save data to a File (why not .csv like ?)
• CoreData :
  You can persist arrays as binary data in Core Data

There are numerous tutorials on these topics.
www.raywenderlich.com site is a good one to begin...

Best method to store data for an iOS app?

If the data you want to store is very little and not sensitive, you can use UserDefaults
For example, user's name, their age etc.

For Large amounts of data you should use Core Data, its a good and an easy way to manage your objects. For example, you have 1000 items, each with a property, you can basically use core data for that. It is pretty straightforward as how to create Managed Objects, store them and how to later retrieve them using queries.

Basically when you configure your project with core data, project creates an sqlite file attached to your project.

There are many tutorials on how to get started with Core Data, if you have an average experience with iOS, it will be a piece of cake for ya.

Here's a nice tutorial that will help you setup core data in your project:

https://www.raywenderlich.com/173972/getting-started-with-core-data-tutorial-2

Best Way to save data locally on the device in iOS app

It sounds as though the text field (with the 1000-2000 words) is static text that is bundled with the app and can not be changed by the user of the app. If that's the case, then you can store that data in the app bundle with plist files, or JSON files and load it on demand (assuming you don't need to search though it).

Then, if each of those records has only a single boolean value that is changeable by the user, those could be stored in NSUserDefaults very easily (since you've stated you're only dealing with 35-40 records). You'd use the id to link the boolean to the data file.

You could use Core Data or Realm to store the data, but it may be overkill if you don't need a search feature and the user can't change the text. But if you do go with a database option, be aware that you can not store static data (the text), in a location that is backed up by iCloud, or Apple will reject your app. Regardless of whether you use iCloud in the app or not. So if you were to create a Core Data persistent store and save it to the users Documents folder, then load in all the static data, you will be rejected. You would want to save that data store in the users Cache folder so that iCloud doesn't back it up. The issue you'll hit after that though is that you want the user's choices that are your boolean values backed up. This means they need to be stored in a different place. Core Data does have a feature that lets you create Configurations where it will separate the user changeable data from the non-changeable data, but again, that's overkill for your case.

I'd recommend starting with Realm over 'Core Data` for such a small dataset. It's much easier to get up and running.

storing data locally on the iphone

For simple data you should use NSUserDefaults. CoreData is very cool but mainly to store DB structures, and introduces complexity (but i love it:)). If you just need to store String, Array and so on (basically prefs), you can go with NSUserDefaults:

For example:

NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];  //load NSUserDefaults
NSArray *fakeFavs = [[ NSArray alloc] initWithObjects:@"2",@"4", @"100", nil];  //declare array to be stored in NSUserDefaults
[prefs setObject:fakeFavs forKey:@"favourites"];  //set the prev Array for key value "favourites"

What is the best way to store application data on the iPhone?

You can store small data in NSUserDefaults but when you have large database then you need sqlite or coredata for storing the database. use of coredatabase is good for big database this is provided by apple and it is to efficient in accessing database.

NSUserDefaults or document directory is used for small database(suppose need to store user name for single user or some other info).

Are there any weak points to store all data in App Groups' container area on iOS8?

Naturally it depends on your app but here's my two cents:

Storing all of your information in a shared directory is complete overkill and doesn't sound like its coming from any sound reasoning. If you feel that your widget needs all the information that your app needs then perhaps you need to reconsider the complexity of your widget.

What you are achieving by this is convenience (future you headaches) rather than simplicity (hiding complexity through singular responsibility). The caveat is that as your application grows and becomes more complex you will end up spending a lot more time facilitating information inside of the App Container (a la massive view controller). What you want to strive for is singular responsibility. Instead you now need an object to facilitate the information of two apps into one container.

Shared containers are also different to the App Sandbox as you need to worry about coordinating reads and writes. Thats why typically its best to go ahead with either Core Data or NSUserDefaults (instantiated with the suite name). If your app stores images and other content then you are in for a world of pain. Even Apple recommend User Defaults (since its the only example they give) or CoreData:

After you enable app groups, an app extension and its containing app can both use the NSUserDefaults API to share access to user preferences [...]
To avoid data corruption, you must synchronize data accesses. Use Core Data,
SQLite, or Posix locks to help coordinate data access in a shared
container.

The purpose of a widget is to provide the at-a-minute overview of your app. By minimizing the amount of data the widget has access to you will reduce many headaches as well as make your widget better contained. Remember, with great power comes great responsibility and if you think storing all of your information in one shared container then you have a lot to be accountable for...

Example

I have recently finished building a widget for a news app that displays the top news stories as well as the ability to personalize the content the widget displays. Heres a basic breakdown of the data persistence to give you an idea:

Storage Breakdown

Widget

• Images its currently displaying
• Last Modified Date of the JSON Feed (So we know when to tell the widget that new content has been added)

App

• All Stories, Images and User content etc

Shared Container

• Users chosen topics
• List of top stories

When the widget is asked to fetch content it downloads a JSON file containing the top stories for all topics. This JSON is persisted to the shared container. The reason we store all the stories is in case the user changes their favorite topics, the widget can then simply update its selection as all the topics are stored. This also allows the app to update the top stories and the widget to reflect that immediately.

The widget will then extract 3 of the top stories that match the users specified topic tags. These top topics are persisted in a shared user defaults item. Naturally its possible that the widget is opened before the user chooses topics, in this case the widget will automatically choose the first three or so topics.

TL;DR

A metaphor - If a Widget and an App are colleagues in the workplace, the Shared Container is like a computer. How productive would you be working with someone all day, every day, on the same computer?

---

Related Topics