{"id":10744,"date":"2015-02-28T11:37:19","date_gmt":"2015-02-28T16:37:19","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=10744"},"modified":"2015-02-28T11:40:30","modified_gmt":"2015-02-28T16:40:30","slug":"core-data-vs-arc","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2015\/02\/28\/core-data-vs-arc\/","title":{"rendered":"Core Data vs. ARC"},"content":{"rendered":"

Matt Drance<\/a>:<\/p>\n

1) Create NSManagedObjectContext<\/p>\n

2) Fetch<\/p>\n

2) Pass results to a method<\/p>\n

I’ve seen ARC kill the MOC before line 3.<\/p><\/blockquote>\n

With at-autoreleasepool, you could optimize given advanced knowledge. Now you need advanced knowledge to not die.<\/p><\/blockquote>\n

The problem here is that Core Data expects that you will keep the managed object context alive as long as you are using any of its objects, but the objects do not retain<\/a> their context:<\/p>\n

Managed objects know what managed object context they’re associated with, and managed object contexts know what managed objects they contain. By default<\/em>, though, the references between a managed object and its context are weak. This means that in general you cannot rely on a context to ensure the longevity of a managed object instance, and you cannot rely on the existence of a managed object to ensure the longevity of a context.<\/p><\/blockquote>\n

ARC will try to release the context after the last line of code that references it, even if this is before the end of the scope. (This is different from other automated reference counting systems, such as Python’s.) It doesn’t know that later code in that scope may use managed objects that assume their context is still alive. This was also a problem with Objective-C garbage collection; Core Data used weak references even though the collector could have cleaned up cyclic strong ones.<\/p>\n

Some potential solutions:<\/p>\n