small medium large xlarge

Back to: All Forums  Core Data
Mel176220_pragsmall
21 Sep 2009, 02:10
Mel Malinowski (10 posts)

I’m considering buying Core Data, but am concerned that it focuses on more complex desktop use of Core Data, and appears to have just one chapter for iPhoners.

There are very specific issues on the iPhone, such as importing SQLite data and using it to feed table views.

Any thoughts on how much in Core Data is relevant to iPhone?

Generic-user-small
21 Sep 2009, 21:56
Brian Doig (1 post)

I have been using the book programming for the iPhone. While several chapters don’t apply to what I am doing, I’ve found that chapter 4, Under The Hood of Core Data, has been very useful. Overall the book has not been super helpful in giving examples of how to do things on the iPhone, but it has been useful in helping me understand the core data stack in general.

Mel176220_pragsmall
22 Sep 2009, 14:38
Mel Malinowski (10 posts)

I decided to buy iPhone SDK Development (another Prag title). It seems more focused on what I need, and a little more suitable for entry-level iPhone programmers. Great explanations of what is happening with each line of code.

Avatarsmall_pragsmall
22 Sep 2009, 14:45
Marcus S. Zarra (284 posts)

While this book is certainly targeted at those already familiar with Cocoa and Objective-C programming, most of the book applies to both the Desktop and the iPhone. Core Data is nearly identical on both platforms and the iPhone chapter outlines where it differs.

Generic-user-small
01 Oct 2009, 04:04
Lars Sorensen (3 posts)

I’ve bought both books mentioned above and found both very helpful when starting iPhone development. When I first bought the CoreData book I was a little disappointed by the the lack iPhone specifics, but this was quickly fixed once the Apple NDA for this was lifted when 3.0 was released. I’d highly recommend both books fram Marcus S. and Bill D. if you’re new at iPhone development.

Mel176220_pragsmall
12 Nov 2009, 16:44
Mel Malinowski (10 posts)

I’ve been having trouble getting NSFetchedResultsController working in my app. I bought Core Data recently, and attempted to make the simplest possible Nav/tableview example, following Recipe, but find Recipe is a rather complex example, and I cannot get it to run. I keep getting ‘persistent store not created’ errors. Even starting from scratch, and using the exact code from the code sample, altered for the simpler example, I keep getting various errors. I’m about to throw up my hands and do a workaround with arrays. A bit awkward, but I do understand how to make that work.

I wish that someone did a simple tutorial on NSFRC that reduced it to basics, with a simple flat SQLite database, no add or edit, so you could get it running and see the essence of how it works clearly, and then go from there. This book is very nice, but does not clearly explain some of the essentials (such as how to handle selecting a subset of the SQLite data, sorting it, how exactly it arranges the data into sections, etc., in the way Bill Dudney does in iPhone SDK Development) Unfortunately, Bill doesn’t do a simple NSFRC example, either. The SQLite database in Recipes is rather elaborate, with confusing entity/attribute naming (Zxxx) that obscures (for me) what’s going on.

If anyone knows of such a code example or tutorial, please email me at mel@malinowski.com

Generic-user-small
13 Nov 2009, 02:12
Nevan (10 posts)

The SQLite database that Core Data creates is not really meant to be human readable, I generally try to avoid thinking about it. You could try changing the data store to XML, then you can get more of an idea about the internals.

I’m still learning the basics, but the simplest example I found was in Beginning iPhone Development. It’s just a set and retrieve example, no relationships, no navigation controller. After that I tried the example in iPhone SDK Development to learn about using a table controller with Core Data.

Avatarsmall_pragsmall
17 Nov 2009, 17:02
Marcus S. Zarra (284 posts)

Nevan is correct in that you do not touch the sqlite file. Core Data handles that file entirely and you will have massive issues if you access the file directly. Core Data creates the file and maintains the file. It is best if you treat it as a black box.

As for a simple example of NSFetchedResultsController, please take a look at MDN (Mac Developer Network) as I have another write-up over there that may be easier to consume.

Mel176220_pragsmall
21 Nov 2009, 15:38
Mel Malinowski (10 posts)

I looked at MDN, searched for NSFetchedResultsController, and found nothing. I saw a passing reference to NSFRC in ‘Passing around an NSObject…’.

How do you get to what you are referring to?

Avatarsmall_pragsmall
22 Nov 2009, 17:07
Marcus S. Zarra (284 posts)

The article on “Passing around a NSManagedObjectContext on the iPhone” utilizes a NSFetchedResultsController in a simple way. I have it on my list to go over the NSFetchedResultsController in greater detail in the near future but that is still on my todo list :)

Generic-user-small
14 Dec 2009, 21:00
Jennifer Rosamond (3 posts)

So, from what I’ve read here it sounds like using Core Data to retrieve results from a pre-populated sqlite database is not the way to go. Is this correct?? For example, I have a database of tv characters. I don’t want the user to edit the database in any way. Is it better to use the sqlite framework in this case?

Avatarsmall_pragsmall
19 Dec 2009, 17:39
Marcus S. Zarra (284 posts)

Depends. If you are going to be creating the database for the app then I would use Core Data. If the database is pre-existing then you are better off using SQLite directly.

Avatar_pragsmall
29 Oct 2010, 02:34
Doug Penny (1 post)

Marcus, the article you mentioned above, “Passing around a NSManagedObjectContext on the iPhone”, doesn’t seem to be online any longer. Googling the title brings up several references to the article on MDN, but Scotty seems to have taken everything MDN related offline. Would you be willing to post the article to CIMGF?

I’m in a situation where I have an intermediate view between my root view controller and my the point I want to create a new core data entry. For some reason, I have been under the impression that passing the MOC around is not the best option, so I have been trying to figure out how to avoid doing that. It sounds like though you are saying it it perfectly acceptable to pass the MOC from one view controller to another. Is this correct?

I had originally thought I would use the delegate method [controller: didChangeObject:… etc] to handle when new objects are entered, but it seems that it gets called as soon as an object is inserted, long before I call save.

Thanks for any insight, Doug

Avatarsmall_pragsmall
29 Oct 2010, 14:24
Marcus S. Zarra (284 posts)

Yes, all of the articles from MDN will be reposted on CIMGF in the next couple of months.

As for your CD question; yes passing the MOC around is the recommended approach.

You must be logged in to comment