I need some understanding about using Core Data.
Can it be used to save and retrieve all of my objects used in my program?
Is there any simple example demonstrating this ?
I am having hard time finding one online.
Thanks for any replies.
They have to be managed objects, but you can convert them all to be - it's just that you still have to define the data model for them.
This might not be the answer you ultimately vote up or mark as accepted, but it may prove useful if you haven't seen it already:
Apple: Core Data
I found it endlessly useful personally.
Related
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. :-)
I've been looking around for a way to store an NSArray containing lots of NSDictionaries. So far I've come across a few different ways of doing it, the most popular of these seems to be the NSUserDefaults approach. That said, it just doesn't seem right to me. In my mind the NSUserDefaults should only really be used for storing the settings a user has selected.
Please can someone help me out with the best way to approach this problem? I'm certain that there must be some standard approach, however I can't seem to pin it down!
Apple does has a framework that provides generalized and automated solutions to common tasks associated with object life-cycle and object graph management, including persistence. ;-)
Seriously though, Core Data should be your first port of call, since it is optimised for the platform, and will scale too. Once you get your head around how it works, it's really fairly straightforward. Also, it's likely to perform better than any roll-your-own solution you come up with.
Please read Archives and Serializations Programming Guide. The top two choices will be to save the array as a property list, or to create an archive using NSKeyedArchiver.
I am writing my own custom persistence instance store for WF4, based on the XmlWorkflowInstanceStore found in the .NET 4 WF and WCF samples. This sample is quite simplistic and the xml is produces is quite verbose. I have issues with how some of the objects are serialized.
I have tried using Red Gate Reflector to understand the Sql implementation used, but it is quite complex and difficult to learn from. The MS documentation for this is rather limited - often giving one sentence descriptions for complex methods.
Please could you point me at other examples of WF4 persistence (or proper documentation) around on the web that are not copy and paste versions of XmlWorkflowInstanceStore? Maybe someone else on StackOverflow has written their own?
You are completely correct that the docs are very much lacking here and the sample is of very limited use. I have started work on a custom instance store using the entity framework but, much like you discovered, found it slow going and am nowhere near anything I could use myself, let alone release onto CodePlex.
I am not aware of any blog posts or other information that help solve this.
You've probably seen this already, but I've found the code quite easy to understand: http://xhinker.com/post/WF4Xml-persistence-store.aspx
Ron Jacobs wrote an in memory persistence store for WF unit testing. Check out http://wf.codeplex.com/releases/view/73842
A few people have wrapped the SQLite library or provided alternatives. What are their relative merits?
Core Data
Yes, a bit of snarky answer.
There are three primary reasons to use SQLite directly or via a wrapper.
You are sharing databases across platforms and can't use Core Data's schema
You really do need raw SQLite performance and have the 17th level SQLite API Mastery required to actually achieve said performance advantage over SQLite.
You know SQLite inside and out, don't like learning new things, and want to re-invent the bits necessary to get between database and screen. (Slightly snarky again).
Core Data buys you a tremendous amount of functionality that is subtly very hard to do. That is, object graph management with full integrity and undo support.
bbum gave the most succinct answer and you should ponder carefully not using Core Data.
But I thought you also deserved an answer to your actual question.
There are basically two wrapper approaches I know of:
FMDB uses an approach that simply makes a much easier to use Cocoa API overlay for SQLLite. This can be great if you know SQL and database design well and just want a simple database.
Other approaches are generally more object-relational mapping systems, that attempt to give you an object view of an underlying datastore, and hide some queries from you.
In both cases if you have a really simple data store they can make sense to use if you have a specific reason... but using Core Data gives you an awful lot for free (though I'll admit the learning curve can be steep).
There is a third approach. This third approach allows you to build SQLite statements via a set of Objective-C classes. They will handle how your data is converted and sanitized. They will also ensure that your statements are correctly constructed. You can try https://github.com/ziminji/objective-c-sql-query-builder This particular library also offers Object Relational Mapping (ORM) that follows the Active Record design pattern.
I'm creating an iPhone app and I'm trying to choose between 2 solutions for a persistent store.
Core Data, or SQLitePersistentObjects. Basically, all my app needs is a way to store an array of model objects and then load them again to display in a UITableView. Its nothing too complicated. Core Data seems to have a much higher learning curve than the simple to use SQLitePersistentObjects. Are there any obvious benefits of using Core Data over SQLitePersistentObjects in my case?
As the author of SQLite Persistent Objects, I say: use Core Data.
I wrote SQLPO when Core Data didn't exist on the phone. Although I'm proud of what I did with SQLPO and even though I do like some things about its approach better than Core Data's (specifically not having to maintain separate class files and data model), the engine underlying Core Data is much more mature and has many more engineering hours invested in it. That's why I abandoned SQLPO development when Core Data came to the iPhone SDK.
I haven't done benchmarks, but I would guess that used correctly, Core Data is going to perform better in nearly all high-volume situations.
SQLPO is faster to develop with since all you do is create the header files, but unless your data needs are relatively light, I say you'd be better off using Core Data.
See this question. My answer to that question also applies to yours.
Core Data VS SQL Statement, which one is gd for iphone development?
Some infromation on my experience with SQLitePersistentObjects.
An app initially developed for iOS 3.x utilizing SQLPO works just fine. Easy to use etc.
Now I am in the process of bringing this app to iOS 4 and things started to get strange.
I now see DB corruptions at unpredictable rates.
Looking into the SQLPO code shows that there is only one sqlite3_close statement and this is called when the DB can not be opened.
I am planning to add a method to close the DB explicitely and call this from my app delegates terminate and for iOS4 didMovetoBackground methods.
Might help to avoid DB corruption issues with SQLPO.
I recently had to make the same decision. I was storing instances of a simple object with a couple of properties. From my research I understand that using Core Data will help you better manage more complex objects with multiple relationships. I ended up using Core Data only because I wanted to learn more about it (but for simple objects there wasn't much of a learning curve).
SQLitePersistentObjects aka SQLLite Persistent Objects is not the same as doing straight SQLite at all. It's an ORM in its own right. I haven't used it yet, but I wanted to correct the completely wrong answer that the previous poster gave.
And I'm seriously considering using because Core Data is a pain.
See: http://iphonedevelopment.blogspot.com/2008/08/sqlite-persistent-objects.html