What is meant by Core Data in iPhone? Why we need it? What is the basic methods in it?
Thanks in Advance
It is essentially an ORM for the iPhone SDK, allowing you to define objects that act as a model which can be created, updated, and deleted through the use of OO and without writing SQL.
If you want more detail I would suggest accepting answers on your other posts like others have already suggested.
Related
I am asking what code to use to save user data in the app so that it is perpetual, even after the app is closed and reopened. I watched a few videos but my code isn't working.
I'm not interested in fixing code, I want to understand the process so I can reapply. Can anyone help me to understand how to do this and explain it in a way that makes sense for long term app development.
It will differ by application, depending on how much data and how it's organized.
If it's simple stuff, look at NSUserDefaults. If it's complicated and represented as objects, look at Core Data. If there's a lot of it and you see it as table rows rather than objects, you can use the sqlite3 database directly. If it has to be shared with other users or by other apps, start thinking about an external server or "the cloud".
There's no single right answer but those options should get you thinking about requirements.
Dear All,
Now am developing offline examination kind of application, here it has different kind of sections and parts of questions for example it has Objective type question and answer , fill in the blanks, voice listening and answering, Read the paragraph and answer etc...
Here how to store this enormous data inside the application and what is the best way to implement it.
if i am converting all the data into XML means how to structure the questions and answers in XML. ?
if SQLlite or core data means how to structure the DB. ?
using plist..?
Any suggestions and ideas would be greatly appreciated.
Thanks
Store the data in application with any way. But it depends on size of data.
If you store large data, then Sqlite is the best way.
For Sqlite,
http://technologyservants.com/index.php?option=com_content&view=article&id=46:shopping-list-an-iphone-sqlite-tutorial&catid=13:opinion&Itemid=21
http://mobileorchard.com/iphone-sqlite-tutorials-and-libraries/
http://www.icodeblog.com/2008/08/19/iphone-programming-tutorial-creating-a-todo-list-using-sqlite-part-1/
Where's the best SQLite 3 tutorial for iPhone-SDK?
You need to use Core Data with an SQLite persistent store. Core Data excels at handling both size and complexity in data models. See my answer to a similar question for details
There is a learning curve to Core Data but once you understand it, it makes writing complex apps very easy.
Finally i decide to use HTML to load questions into uiwebview and sqlite for storing answers.
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
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.
Coming from a non-SQL background, I've been having a hard time absorbing SQLite3 for the past few days. Has anyone had any good results using any of the SQLite3 wrapper APIs out there? Do they work reliably? Which is best? I am also hearing buzz about Core Data coming to the iPhone. Not sure whether that info is trustworthy or not but maybe some of you know: will there be a Core Data for the iPhone at some point?
FMDB is easy to use and abstracts some of the SQLite nastiness away from you, but still exposes the SQL.
I have used it in a project, but subclassed it to add my own partially-OO layer. The advantage of this approach is that if I need more speed or something I did not foresee (triggers for example), I can make it happen. With Core Data, there is no "bypassing" available and I have to rely on Core Data's optimizations, memory use, etc.
Another difference is the Core Data will allow your app to remain fully OO. With FMDB or other database solution, you're always tied closely to the organization of the database. It's a design decision, and not one you can change later.
If you're only just starting now, I would use Core Data.
I spent some time last year looking at the various wrappers at the time. I didn't use any of them in the end.
I think the NDA was still in place when I was looking so I may have missed the best ones, but I found that most were very thin wrappers. For my purposes this meant that it added an external dependency, didn't save much typing and I would probably still have had to dive down to using sqlite function calls sometimes anyway. Just didn't seem worth it.
Why not target CoreData using the 3.0 SDK?
If for some reason you need to support 2.x, you should look at SQLitePersistentObject. It's slow and has some bugs but it is VERY easy to use. Sadly it is no longer under active development by the author.
Additionally:
Some time ago, with a small sample project (2.x) I used fmdb. As far as I remember it was pretty easy to use. However, it required SQL knowledge.