I am making a fitness app that will save your weight, reps, and sets performed for each exercise you perform. I will also use this to track the progress made using this data. Does anyone have any clue how to do so? I've made apps before, but never required the saving of persistent data. Any info would be much appreciated.
You should investigate Core Data and User Defaults.
In your case it sounds like you will need a database so Core Data is the way to go
This seems like a perfect job for Core Data
The Core Data framework provides generalized and automated solutions to common tasks associated with object life-cycle and object graph management, including persistence.
https://developer.apple.com/library/mac/#documentation/cocoa/conceptual/coredata/cdprogrammingguide.html
Depending on how much data you're considering generating and how complex the data itself is, if the amount of data is "small", a simple dictionary might work. They can be saved and read pretty easily. However, there are limitations on what data types you can have in a dictionary (or an array) that you then write out. And, from a performance perspective, if you get too much data, writing and reading it can be slow...
I'll re-iterate the recommendation for Core Data, but wanted to mention the other options for completeness. :-)
Related
i'd like to make some application that store data in device.
so i want to use some storage. but there are two ways i can store my data.
first one is saving them to file system by XML structure, and the other one is by using sqlLite library. but i have no idea. because i don't know the strength and weakness each of them. for example location of stored data, and which one is faster to get the data i want. i just store text data. so please recommand which one is better.
sorry for my english skill. thank you!
SQLite !!! No doubt about that.
For easy maintenance, querying capability and lot more.
SQLite has the basic features of a database engine, it's lightweight. Specially designed for mobile platform. So some features like regex in database etc is not included.
File and Database. Always preference goes to database.
DATABASE ALWAYS...
As you said SQLite is one option, and you can use SQLite directly with iOS. But I hope you have heard about Core data, which is a higher level wrapper to make Database easier.
But there is no comparison between Database and files
This would be Perfect answer for your question and for iOS I would suggest SQLite will be the best one as it has everything in one file,
performance loss is lower than XML as cache gets bigger.
It depends on the amount of data (and its structure and complexity) that you are going to store. For rather small amounts, not more than a handfull of records or two, I would use an NSDictionary and the load and save methods that come with it. Those persistant storage will be in XML, btw.
For more data or rather complex data, especially when you do not need to load all the data at the same time, then you should go for a database solution. That chould be sqlite. Or you may opt for core data which (per default) is based on sqlite.
I would suggest core data (unless you aim for portability such as android). You will have to invest in learning core data. Which may appear to be confusing from start. But once you have started with that you will certainly find core data quite convenient. It takes a lot of work from you that you have to care for manually when using native sqlite.
Hi thank you for the help in advance,
I have looked at some of the posts and I am a bit confused about the multi threading. It seems that it may be pretty easy, however I am very new to programming so I am still trying to grasp this.
These are two calls to pull data from a database, and they take forever as it is... So I'm thinking about multithreading these until I can learn how to build a core data for this. Right now i am using sqllite and the database involves 10,000 + recipes... So not lightning fast like I would like...
Please let me know what you think, and how I can make these happen maybe simultaneously? (If thats even possible)
Thank you in advance.
requestCount++;
[[DataPuller sharedDataPuller] getAllDeletedRecipeList];
[DataPuller sharedDataPuller].target = self;
requestCount++;
[[DataPuller sharedDataPuller] getAllRecipesList];
[DataPuller sharedDataPuller].target = self;
If you're doing SQLite, you might want to contemplate using FMDB which (a) gets you out of the weeds of sqlite3 calls; and (b) offers a FMDatabaseQueue which allows you to coordinate queries from multiple queues, so that the data operations don't stumble across each other.
Having said that, you suggest that you're having significant performance issues which you're hoping to solve with a shift to Core Data or going multi-threaded with SQLite. That's unlikely. Poor performance of local database operations is generally more of a matter of your application design (e.g. it's unlikely to be wise to try to retrieve the entire details for all 10,000 recipes ... you probably want to retrieve just the unique identifiers, perhaps only those required for the given screen, and then only retrieve the particulars for a given recipe at a later point as you need that). For local database interaction, you rarely have to contemplate a multithreaded implementation, but rather just design the system to retrieve the least possible information at any given point that you need for the presentation. I personally find that my database-driven apps generally only need to go multithreaded when I'm doing extensive interaction with some remote web service (in which case, it's the retrieval of server data and the parsing of that which goes on the separate thread, not necessarily the database operations themselves).
If you're having performance issues with your recipe app, I'd suggest you submit a far more detailed question, with code samples, that articulates your particular performance problem. And I wouldn't be surprised if multi-threading was not part of the solution. Likely, appropriate use of indexes and a more judicious retrieval of information at any given point might be more critical.
Get records from database in the form of pages; i.e. 20 or 50 recipes per page. Have a look on YouTube app. on iPhone or have a look on my app. HCCHelper
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