I've used Core Data a ton in apps since it was introduced on iOS. I've also used NSFetchedResultsController quite a bit and I've helped others with their Core Data code.
One thing to keep in mind is that Core Data uses exceptions internally as part of its normal operation. If you break on exceptions, you'll end up in the debugger quite a bit but it's not because anything is broken, just the way Core Data is built. Annoying but important to remember. Your customers should not be impacted by this at all. Regarding crashes, by far the most common cause is improper use of Core Data and threads/queues. You mentioned using thread confinement - by that I assume you mean NSConfinementConcurrencyType and not something like NSPrivateQueueConcurrencyType? Have you considered using the newer NSPrivateQueueConcurrencyType and the performBlock methods? These enforce the threading rules even more explicitly and make it harder to make a mistake. For instance, if you init a MOC with thread confinement on the main thread even if you only use it on another thread, you're likely breaking the rules (MOCs created on the main thread hook into the run loop in special ways - make sure you are creating your MOCs on the thread/queue they are going to be used on). I've done several apps with what sounds like similar use cases and not had crashes or other problems so my guess is something may be slightly off… if you can use the new stuff, consider it. It's very helpful. Hope that helps somewhat. On Feb 13, 2013, at 11:34 PM, Laurent Daudelin <laur...@nemesys-soft.com> wrote: > I just added CoreData to an app I'm working on. I've been working with > CoreData for about a year, not exclusively but pretty regularly so I think > I'm experienced enough to set it up properly. > > However, our testers are experiencing what I feel is more than normal crashes > in the main part of the app that depends on CoreData. I'm using an > NSFetchedResultsController to drive my main table view and that part seems > very weak and will break or raise an exception at any time for any reason. I > collecting those crashes that can be detected by TestFlight and there is no > relation between them but they all resolve around CoreData or the main > tableview. > > The heaviest load is when I get a bunch of data from a server that is turned > into JSON objects and then saved to the database. There can be 200 pretty > large dictionaries coming at once and they are all saved to the database in a > serial queue, while at the same time, the fetched results controller sends > the usual delegate messages to adds those rows to the table view. I would say > that 80% of the time, it works just fine, but for about 20% of the loads, > some involved object will raise an exception. Since I'm using multiple > threads, and as recommended in the doc, I'm using the thread confinement > method to perform the needed operations that involve the database and managed > objects. I have one managed object context per thread, but there is really > only one, in that serial queue, plus the one in the main thread. I implement > the didReceiveManagedObjectContextSaveNotification: methods to merge the > changes on the main thread, as recommended. I pass object IDs when I need to > access a managed object context from one thread to another. > > Still, I feel there are way too many crashes. > > I have read from older messages that the fetched results controller could get > confused when issuing updates, moves and inserts back in iOS 3 and 4. But I > haven't found anything that would lead me to believe that these bugs are > still present. But, are they? Is it safe to use this technology for some > serious database work? > > Any advice, pointer or info would be greatly appreciated. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
