Thanks, Hunter. I'll consider the newer option. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com
On Feb 14, 2013, at 09:03, Hunter Hillegas <li...@lastonepicked.com> wrote: > 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/laurent%40nemesys-soft.com > > This email sent to laur...@nemesys-soft.com _______________________________________________ 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
