I will make a simple game app which will store some data as user progresses in levels. For example: each level has a number of sub-levels, sub-level stores 3-4 properties (strings and arrays) depending on user's progress.
The app is simple and it is not a lot to store (about 150 levels and sub-levels maximum with small amount of data in each) and I do not want to make it complicated with multiple classes representing levels and sub-levels plus SQLLite database. I thought of a simpler approach but good enough to manage data through my GameManager singleton.
Recommend what approaches to look at for my needs to store and manage data for this type of an app. Perhaps one of these or something else:
NSUserDefaults + NSDictionary
CoreData + SQLLite
etc...
Just want to make sure I am not missing anything
It's much better and less painful for you to use core data. Why do you say sqlite?? Core Data is just saving your objects in a sqlite file on an iOs device and in xml in Cocoa app.
To use plist files is kind of strange, as I think. You can put into it only a simple array, and what if you want to display photos besides your simple array? The preferred way is core data - 50% less code, as apple says. Use NSFetchedResultsController and you'll be good!
Another widely used practice would be to store your information in a property list (.plist). NSDictionary and NSArray come equipped with the capability to load from as well as write to a property list.
Here's a resource which may be helpful to you: Property List Programming Guide
Take a look into core data. It seems very difficult once you get started. But once you get into it, it gets pretty straightforward from there. Check out this tutorial he helped me get going. Hth
Related
I know little about Core Data. Read: I've read a few tutorials, kinda understood how it works, but never tried to use it in any of my apps. That said, I'd like to know if it's worth the effort to use it in the app I'm developing. Note that I'm not asking if I should learn Core Data, but if it's worthwhile to invest time learning it for this specific app I'm making, or if I should use archiving instead, ship the app, and only then learn Core Data in my spare time.
Basically my app reads a list of items from a web service, and needs to save the last N items. The user should also be able to bookmark items, so that's another thing I should store somewhere. So, right now I'm just archiving a subarray with range 0-N of the latest items. Does it work? Yes. Is it efficient, and the best way to achieve this? That's my question for you actually.
My doubt comes from the fact that whenever I see someone asking 'Is Core Data overkill for my project?' everyone suggests to use it anyway.
If the amount of data you need to persist can easily fit into memory without degrading the apps performance then you should just archive the array and ship the app.
Core Data gives a lot of advantages when handling large and complex data sets. It gives a lot of advantages in maintaining and upgrading a shipped app. However, those advantages should not get in the way of shipping an otherwise completed app. Later, you can always write code to migrate a shipped version to a Core Data version. It's more work, but hey, at least you've got a shipped app to work on.
I've seen a lot of small startups/developers come and go and the major factor that separates the successful from non-succesful is that the successful actually ship/release product. You can spend forever polishing an app but the key thing is knowing when to say, "It's good enough" and get the thing into the user's hands.
If it's a small list and you have the data in NSDictionary or NSArray collections, use writeToFile:atomically: instead for flat file XML Plist storage.
I still think you should learn Core Data eventually, but.
I'm making a game and I need to be able to ship some data about the game's various ships and details about them that the app will use. I'm looking for what the ideal way to do this would be. Now I've narrowed it down to using either SQLite, Core Data, or Property Lists. Now the thing I want to keep in mind as well is memory. Because it's a game I need to be careful about this and because of the fact Property Lists need to be loaded all into memory I'm afraid they might not be ideal. I know SQLite is supposed to have better performance than that and I've heard that Core Data performs even better than that. So my question is what do you think the best way to ship static data with an iPhone app is?
I would say it depends on the amount of data that you need to provide. If it is a lot of a data, I would definitely go for sqlite. If it is just a couple of ships, sqlite might be a little over the top.
For a such a small amount of data why dont you consider writing your own file format, or using something easy to parse such as csv, will be easy to edit in any spreadsheet program, and to cut down filesize / load times convert it into a binary format.
Assuming that not all ship-data is needed at the same time (and as such, having them all in one file would be a waste): Maybe you should use a separate data file for each ship or each class of ships?
Since this would solve the storage-efficiency at a different level, plists might be a viable option.
I have a rather simple iPhone app consisting of numerous views containing a single, grouped table view. These views are held together in navigation controllers which are grouped in a tab bar. Simple stuff.
My table views do little more than list text (like "Dog", "Cat" and "Weasel") and this data is being served from a collection of plists. It's perhaps worth mentioning too that these tables are 'static' in the sense that their data is pre-determined and will only ever be amended—and if so, very rarely indeed—by the developer (in this case, moi).
This rudimentary approach has reached its limits though, and I think I'm going to need something a bit more relational. I have worked a tad with Core Data in the past, but only with apps whose data is determined by user input.
I have four closely related questions:
Is Core Data overkill for an app consisting mainly of a selection of simple table views?
Do you recommend using Core Data to manage data which is predetermine and extremely unlikely to ever change?
Can one lock Core Data down so that its data can't change, thereby relinquishing my responsibility as the developer to handle the editing and saving of the managed object context?
How do I go about giving Core Data my predetermined data, and in a format I know that it can work with?
Thanks a bunch guys.
The answer is simple. If you do not need to persistent to an out of date format (like MSWord, etc.) then you should be using Core Data. Raw SQLite is a headache that is not worth the effort 99.999% of the time.
Core Data is more efficient than plists and allows greater flexibility if the project ever evolves.
It is also very easy to pre-populate a Core Data sqlite file using a OS X machine; you know, the machine you are using to develop your application in the first place :)
NNW's use case is a singular exception to this rule that, if I were a betting man, I would bet has the Core Data team's attention and will be corrected in a future update. An update, by the way, that you will get for free if you use Core Data.
You might consider using the SQLite API directly, rather than Core Data, as it may be easier to pre-populate a database that way. You can create and modify a SQLite database on any platform (Mac, Windows, Linux), and just copy it to your application's bundle as a resource.
You can find tutorials/examples that will create a user's database by copying a SQLite database out of the application bundle. In your case, you can just use the one in the bundle. Just be sure to open it read-only.
I would recommend sticking with plists since your data will rarely change and when it does it will be developer-driven.
Core Data is very powerful, but there will be a moderate amount of plumbing and infrastructure you'll need to set up to make it work.
Core Data places its store outside of your app bundle (as it must to run on the iPhone), so all new installations will need to load data into the store on the first run. This data will probably have to be stored as resource plists anyway, so you aren't saving yourself the trouble of generating those plists. Turns out that wasn't true and you can store read-only parts of the persistent store in the App bundle.
Since I don't know exactly what kinds of limitations you're running in too, Core Data may be the solution, but I'm guessing it won't be. If object relationships are the biggest difficulty you're dealing with, you should read up on object archiving as a way to store your entire object tree in a form that can easily be saved as a resource in your bundle and recreated when necessary.
You should read why NetNewsWire switched
The two main takeaways from that post:
I bet Core Data is the right way to go 95% of the time. Or more. It’s easy to work with. It’s fast (in most cases).
And:
(Rule: always work at the highest level possible.)
I recommend using plain SQLite. It is simpler, easier to maintain and you can build the database on non-mac systems, using many popular GUI editors. For me, using Core data is still a pain. Code to populate your tableviews from a static SQlite database is simple, straightforward, and transparent, while Core Data needs more boilerplate code which you don't even understand completely at first and overall has a lot of hidden complexity which you don't really need.
In the development of my first serious iPhone application (Meaning I'd like to actually get it out on the AppStore), I needed a good way to represent my data. Instead of going with core data, I (stupidly, I think) decided to use classes to represent my data.
I created three classes, MMDot, MMShowMovement, and MMShow. The MMShowMovement holds instances of the MMDot class in an array, as the MMShow holds instances of MMShowMovement. Sounded like a nice way to do it, each class has a lot of logic that has to go with it, so I thought that classes seemed like a good way to go about representing all this data.
My question is, is there an easy way to save the instances of these classes so I can restore the data after the application is reopened? I have made applications on OS X using a NSKeyedArchiver, would it be similar on the iPhone? Would it be easier to start again using Core Data instead (These objects are very complex, especially MMDot with about 15 instance variables, now that I look at it, maybe not THAT complex)?
I'm really at a loss here.
You can absolutely use NSKeyedArchiver to persist your objects. I'm a fan of either method, the decision mostly lies with your application needs. I don't think it will be much work to re-model your objects in CoreData. Without knowing anything about your application I'd say if you are doing simple persistence with a simple model you may not need Core Data, if you have complex relationships and will be reading/persisting data frequently during an application session Core Data is probably the way to go.
If you have a lot of object instances, you are probably better off using Core Data - it will help cache things, help you with queries to get specific sets of objects, and so on. KeyArchiving is really a lot more useful if you are saving off a handful of instances, but have some downsides - in particular it's harder to track down memory leaks from Unarchived objects.
Core Data can also do paging of results for you too, so that you aren't fetching in the entre contents of a large array if you do not need it.
I was looking into serializing my classes the other day and went with using NSUserDefaults. I just give all the internals of my objects a unique key based on the object. Seemed to work fast for me.
Wrote a blog about it here: http://technolojiadev.blogspot.com/2009/12/serialize-this.html
Is there any "Best Practice" approach to storing persistent static data for iPhone apps?
I have an app that reads a dictionary of approximately 1000 items many of which are arrays. I started out using a single plist for this and it has become somewhat unwieldy especially since much of the values are HTML strings.
Is there a better way for me to approach this? I plan on scaling this app significantly and I obviously don't want to change my approach midstream.
I've googled for iphone data storage and variants but have come up short for anything even touching on a best practice.
It sounds like you intend to distribute some data with your application. A property list is probably the easiest to maintain, but it will be loaded into memory all at once. This could eat up a lot of the device's memory.
An sqlite database, on the other hand, will load only the data you request. I'm not sure how your data is structured, but you could quite easily create key-value pairs with a single database table. (A single table with a key column and a value column) Then, if it were me, I'd write an Objective-C class to wrap the database queries so I can write easy statements like:
NSString *welcomeText = [[MyData sharedData] dataWithKey:#"WelcomeText"];
Getting the data into the database in the first place doesn't have to be difficult. You can use the command line sqlite3 utility to bulk load your data. There's a command called .import that will import your data from a text file.
Hope this gets you moving in the right direction!
I'd go with a sqlite solution. The apps I am working on now, which are just apps to help me learn iPhone development, mostly all use sqlite. I use the sqlite plugin for firefox to help with maintaining the database, which works surprisingly well. https://addons.mozilla.org/en-US/firefox/addon/5817
As Alex suggested using a wrapper class would also be the best way to go.
Don't forget with 3.0 you can use a CoreData layer around SQLlite which may make it more appealing to you.
If you don't need to store any relational information about your data, why not just use files? There will be some wasted filesystem space, but plain files might be the most memory and CPU efficient solution, depending on the size and number of your items.
I've never developed an iPhone app but I have played around in the filesystem. I have seen sqlite databases floating around various places of the phone. I'm pretty sure it uses a sqlite database to store your calendar entries.
I would use sqlite. It is already there, easy to use, and will provide the most flexible path for expansion in the future.
I use sqlite for static data in my iPhone apps all the time.
All I did was save state when the app is shut down. I used a file for that.
sqlite sounds perfect for your app. sqlite is pretty easy. I've used it in Adobe AIR apps.