IOS Development Series: A way to coredata Object into Fault

@quote:

has been dealing with CoreData recently, this is a huge architecture, learning curve of the more steep iOS components, each encounter problems will have a new understanding.

This time, just a little bit about the Fault problem caused by the error cognition Object (Nsmanagedobject) and the Context (nsmanagedcontext) reference relationship.

The use of CoreData should have a basic use of the most direct understanding, that is: object is placed in the Context, and the object will have a "managedobjectcontext" method, you can get it where the Context.

At first, I naturally thought that context strongly quoted Object,object, which in turn was quoted in the context. In fact, the "managedobjectcontext" of Object is a method, not a property, and there is no strong referential relationship.

If you create a new context from CoreData Stack, then take an object from the context and assign the object to a Viewcontroller, and finally in this viewcontroller some Task, you will soon find that Object becomes fault and unusable.

This is because if the context is not similarly strongly referenced, after it is released, Object will cause "fault cannot be fulfilled" to be unusable because it does not have this context.

About "fault cannot be fulfilled", there is another example of "troubleshooting Core data" in Apple's official document, unlike the one I've encountered. It describes the situation is: After the deletion of object from the Context, the substance has been deleted, but Object because in the memory management cycle has not been released, just become a Fault, then if you revisit this object, you will get "fault cannot Be fulfilled"error.

Back to the problem that I encountered, usually in a not particularly complex based on the CoreData program, we do not use a lot of context, and everyone's CoreData Stack is a strong reference to the context at the appdelegate level, This problem is too uncommon, especially when you don't use a temporary new Context and forget to quote it strongly.

In short, when looking at the document must be careful to distinguish between the method and the property, even if the same syntax + return is the same thing, also can not feel that they are the same. From this point of view, it is still necessary to strictly use the syntax of [object method] and Object.property.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PS: I consulted the API documentation, which has not been understood in the following words:

-(BOOL) IsFault
description	Returns a Boolean value indicates whether the receiver is a fault.
	Knowing whether an object is a fault was useful in many situations when computations was optional. It can also is used to avoid growing the object graph unnecessarily (which may improve performance as it can avoid Time-co Nsuming fetches from data stores). If This method is returns NO, then the receiver ' s data must is in memory. However, if this method returnsYES, it does isn't imply that the data was not in memory. The data may is in memory, or it may not, depending on many factors influencing caching If the receiver is a fault, calling this method does does not cause it to fire. Do you really not understand this statement? Also please enlighten the prawn @@

IOS Development Series: A way to coredata Object into Fault