I'm just getting started on making a board game using Cocoa/Objective-C. My plan is to first get it functional as a Mac OS X app, and then port it to iOS.
I saw something in the documentation for the Core Data API that made it sound like it was the recommended way to store data persistently, and made reference to the fact that iOS apps should be able to quit and be restored in exactly the same state. I got the initial impression that I should plan to use Core Data for any variable that has to do with the game's state to support this.
But as I'm learning more it seems like my initial impression isn't correct. Core Data seems more like something intended to provide similar features as embedded SQL, and is more complicated than is required just for storing the game state persistently on disk. Is there a simpler way to support fast app restoring in iOS apps, or is Core Data the way to go?
Core Data is fantastic for storing lots of data of different types, including custom objects.
However, if you're talking about storing things like high scores for a game or other simple int, float, BOOL, NSString, NSArray data, then for iOS NSUserDefaults is a quick and easy way to go.
Core Data lets you store data as objects, so if your game state can be described with native data types, Core Data just might work for you. You'd essentially be manipulating object states.
If you're looking for something a little more lightweight, look into the NSUserDefaults API (which is the same thing that the Settings App on iOS uses).
Alternatively, you could come up with your own format and use that, serializing your own data to disk.
I'd start with NSUserDefaults.
Related
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?
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?
I am building an application that recovers JSON data (1000-2000 lines) from a website. It's basically just a bunch of arrays and values, nothing fancy. What would be the best way to store this information and use it between the views? Should I create a local sqlite database, write to file or just send the information from view to view using prepareforsegue?
I would think the latter is faster and easier to implement, but I'm not sure if it's easier to use after (I'm new to IOS).
Thank you !
I'm using Core Data with Magical Record. It easily maps your JSON objects into NSObjects which are then persisted into Core Data. It is thread safe and very powerful.
Or you can map it yourself into NSObjects of your choice without actually persisting them or saving them anywhere which is much easier in some cases. It is a good way to go as well.
Both methods looks OK . Now it depends whether your JSON data is big enough to slow down the app.
Sqlite Database is easy to implement to store large information in your app.but if you want to increase performance of app to access data locally you can use core data to store data because it providing object relationship to store data in app that is easy to access and store data.but now it is depends on you
I'm creating an iOS application that has a Twitter-like feed of data. I'm currently planning on storing the data on Parse. However, what is the most efficient way to store retrieved objects locally for use when there does not exist a network connection? It sounds like using Core Data is overkill since I'm storing the data on Parse anyway. Can the Parse caching system do this for me or is there something else more appropriate? On a similar note, is there a simple way to check if this locally saved data is up-to-date?
I recommend you have a look at SQLite, especially with the FMDB Objective-C wrapper classes.
Parse has the capability to cache objects locally. If your app can tolerate the characteristics of caching, then just use that.
My own app will not, so I am using CoreData as my local store. My app has to be able to operate fully when disconnected from Parse, so I have to have something more than cached data. I looked at FTASync and found the concept very useful. When I got into the code though I realized I needed something much more robust, so I have ended up doing a completely new utility to sync Parse with CoreData. This is a huge job, so don't take it on unless your need is commensurate.
-Bob
I am developing a relatively simple new free iOS app. As it's free I decided to go straight for iOS 5 as a target to allow me to try out some new features, particularly story boards.
Once I've got my head around them storyboards are wonderful, I've written hardly any boilerplate code at all up the point of a working prototype.
My model at the moment is is non persistent, after all it's just a prototype, but I've started to wonder about the best way to make it persistent. The model consists of essentially a list of custom objects which contain text, images and locations.
And so to the questions.
If I have a fully working model in memory is there a relatively simple to convert that into a persistent core data representation ?
If I want to have synchronisation to a backend web service at some point will this help ?
Should I start again with a core data application and throw away the prototype ?
All depends on your data set. If you have a large graph with relationships, Core Data might be a good idea. For simpler data sets, you could write it out to a .plist in the user's documents directory. For very small amounts of data, you could persist them into NSUserDefaults.