Reputation: 2332
I used RestKit integrated with CoreData in my project. To perform the network requests and map its JSON response the following service is widely used in the project:
- (RKManagedObjectRequestOperation *)managedObjectRequestOperationWithRequest:(NSURLRequest *)request
managedObjectContext:(NSManagedObjectContext *)managedObjectContext
success:(void (^)(RKObjectRequestOperation *operation, RKMappingResult *mappingResult))success
failure:(void (^)(RKObjectRequestOperation *operation, NSError *error))failure
The documentation of this function has this statement for the managedObjectContext
attribute:
The managed object context with which to associate the operation. This context will be used as the parent context of a new operation local
NSManagedObjectContext
with theNSPrivateQueueConcurrencyType
concurrency type. Upon success, the private context will be saved and changes resulting from the object mapping will be 'pushed' to the given context.
Is it any reason to use another MOC instead of the main MOC for this request? I can only imagine one case, when a new private context should be used: If at some point the user is able to drop the mapped objects by the given network call. At this case it could be reasonable to keep the newly mapped objects on a separated context, and the changes will be propagated to the main context only if the user make the corresponding action, otherwise the context will be dropped with all its changes.
In my case, the RestKit is used for cache. After a request was performed and the response has mapped, than a fetchedRestultsController's delegate will be called by CD to update the UI. As a result I always specify the mainContext as the managedObjectContext
attribute.
In an example project somewhere I found, that this attribute is specified to the MOC of the called thread. If it was the main thread, than the main context will be the input, if it was started from a background thread, than a new child MOC was created for the request. But I think, it is not reasonable, right?
Upvotes: 0
Views: 178
Reputation: 119031
Your question isn't really about RestKit or this method as such, it's about Core Data thread confinement. You have a responsibility to only use a managed object context from the designated thread, and if you ask an API to do something on a context it is again your responsibility to pass the correct one for the thread. So, if you're making a main thread request you should pass the main thread context. RestKit will always create a child context because it creates a background thread to do the heavy lifting.
It is possible, though uncommon, that you would start from a background thread and then you need to be careful about run loops, callback queues and notifications. It can get complicated quickly so this is usually best avoided...
It's generally easier to use the object manager instead of the operations directly as it deals with these choices for you. You're also almost always starting on the main thread and allowing RestKit to handle the background download and mapping for you, then pushing the result back to main.
Upvotes: 1