I'm using MagicalRecord with its saveWithBlock: method:
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext) {
// some work
// ...
// -> ups! I changed my mind, I don't want to save!
}];
If I'd like to cancel the saving operation inside that block, how can I achieve that?
E.g. I have a long running download/sync operation when the user logs in - if the user logs out during this operation I'd like to cancel the saving inside the saveWithBlock:
If you want to perform cancellation then don't wrap your changes into a MagicalRecord saveWithBlock. You could simply use the Context's performBlock API and discard the changes if you are not happy.
[context performBlock:^{
// some work
// ...
if(timeToCancel) {
[context reset];
} else {
[context MR_saveToPersistentStoreWithCompletion:nil];
}
}];
Related
I'm using the [MagicalRecord saveWithBlock: completion:] method but I'm not sure how to access the saved object on the completion block. My code is the following
NSLog(#"saving player");
__block PSPlayer *player;
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext) {
// parse json
player = [self parsePlayer:playerInfoJson inContext:localContext];
NSLog(#"player.md5Id %#", player.md5Id);
} completion:^(BOOL success, NSError *error) {
NSLog(#"player.md5Id in success %# error %#", player.md5Id, error);
...
}];
The player.md5Id is correctly set at the end of the save block but is nil in the completion one. Is this a correct usage?
cheers,
Jan
The completion block captures the player reference before it's set so it will be nil when that block gets executed.
If you want to use the new managed object later you should store it in a property and then call a method from the completion block, (possibly switching to the main thread, not sure if MR does that for you) to find that object in the main context.
Alternatively I think you could define the completion block earlier and then pass a copy to the method, then the copy would have access to the updated player reference (I don't do that very often really but IIRC it should work).
I'm trying to separate my application work when there is a bigger work to do to optimize performance. My problem is about a NSManagedObjectContext used in another thread than the main one.
I'm calling:
[NSThread detachNewThreadSelector:#selector(test:) toTarget:self withObject:myObject];
On the test method there are some stuff to do and I have a problem here:
NSArray *fetchResults = [moc
executeFetchRequest:request
error:&error];
Here is my test method:
-(void) test:(MyObject *)myObject{
#autoreleasepool {
//Mycode
}
}
The second time I call the test method, my new thread is blocked when the executeFetchRequest is called.
This problem arrived when my test method is called more than one time in succession. I think the problem comes from the moc but I can't really understand why.
Edit:
With #Charlie's method it's almost working. Here is my code to save my NSManagedObjectContext (object created on my new thread).
- (void) saveContext:(NSManagedObjectContext *) moc{
NSError *error = nil;
if ([moc hasChanges] && ![moc save:&error]) {
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
}
}
This method is called on the new thread. My problem now is that with this save, I have a deadlock and I don't really understand why. Without it's perfectly working.
Edit2
I'm working on this issue but I still can't fix it. I changed my code about the detachNewThreadSelector. Here is my new code:
NSManagedObjectContext* context = [[NSManagedObjectContext alloc]
initWithConcurrencyType:NSPrivateQueueConcurrencyType];
context.persistentStoreCoordinator = self.persistentStoreCoordinator;
context.undoManager = nil;
[context performBlock:^
{
CCImages* cachedImage;
NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
childContext.parentContext = context;
cachedImage=[CCImages getCCImageForKey:path inManagedObjectContext:childContext];
UIImage *image = [self getImageFromCacheWithPath:path andCachedImage:cachedImage atDate:now];
if (image != nil){
if(![weakSelf.delegate respondsToSelector:#selector(CacheCacheDidLoadImageFromCache:)])
[weakSelf setDelegate:appDelegate.callbacksCollector];
//[weakSelf useCallbackCollectorForDelegate:weakSelf inMethod:#"initPaginatorForListMoments"];
[weakSelf.delegate CacheCacheDidLoadImageFromCache:image];
}
}
- (UIImage*) getImageFromCacheWithPath:(NSString*) path andCachedImage:(CCImages *) cachedImage atDate: (NSDate *) now{
NSURL* localURL=[NSURL URLWithString:cachedImage.path relativeToURL:[self imageCacheDirectory]];
UIImage * image;
//restore uiimage from local file system
if (localURL) {
image=[UIImage imageWithContentsOfFile:[localURL path]];
//update cache
[cachedImage setLastAccessedAt:now];
[self saveContext];
if(image)
return image;
}
return nil;
}
Just after that, I'm saving my contexts (manually for now)
[childContext performBlock:^{
NSError *error = nil;
if (![childContext save:&error]) {
DDLogError(#"Error during context saving when getting image from cache : %#",[error description]);
}
else{
[context performBlock:^{
NSError *error = nil;
if (![context save:&error]) {
DDLogError(#"Error during context saving when getting image from cache : %#",[error description]);
}
}];
}
}];
There is a strange problem. My call back method is called without any problem on my controller (which implements the CacheCacheDidLoadImageFromCache: method). On this method I attest the reception of the image (DDLogInfo) and say that I want my spinner to stop. It does not directly but only 15secondes after the callback method was called.
My main problem is that my context (I guess) is still loading my image from the cache while it was already found. I said 'already' because the callback method has been called and the image was present. There is no suspicious activity of the CPU or of the memory. Instruments didn't find any leak.
I'm pretty sure that I'm using wrongly the NSManagedObjectContext but I can't find where.
You are using the old concurrency model of thread confinement, and violating it's rules (as described in the Core Data Concurrency Guide, which has not been updated yet for queue confinement). Specifically, you are trying to use an NSManagedObjectContext or NSManagedObject between multiple threads.
This is bad.
Thread confinement should not be used for new code, only to maintain the compatibility of old code while it's being migrated to queue confinement. This does not seem to apply to you.
To use queue confinement to solve your problem, first you should create a context attached to your persistent store coordinator. This will serve as the parent for all other contexts:
+ (NSManagedObjectContent *) parentContextWithPersistentStoreCoordinator:(NSPersistentStoreCoordinator *)coordinator {
NSManagedObjectContext *result = nil;
result = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[result setPersistentStoreCoordinator:coordinator];
return result;
}
Next, you want the ability to create child managed object contexts. You will use these to perform work on the data, wether reading or writing. An NSManagedObjectContext is a scratchpad of the work you are doing. You can think of it as a transaction. For example, if you're updating the store from a detail view controller you would create a new child context. Or if you were performing a multi-step import of a large data set, you would create a child for each step.
This will create a new child context from a parent:
+ (NSManagedObjectContext *) childContextWithParent:(NSManagedObjectContext *)parent {
NSManagedObjectContext *result = nil;
result = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[result setParent:parent];
return result;
}
Now you have a parent context, and you can create child contexts to perform work. To perform work on a context, you must wrap that work in performBlock: to execute it on the context's queue. I do not recommend using performBlockAndWait:. That is intended only for re-rentrant methods, and does not provide an autorelease pool or processing of user events (user events are what drives nearly all of Core Data, so they're important. performBlockAndWait: is an easy way to introduce bugs).
Instead of performBlockAndWait: for your example above, create a method that takes a block to process the results of your fetch. The fetch, and the block, will run from the context's queue - the threading is done for you by Core Data:
- (void) doThingWithFetchResults:(void (^)(NSArray *results, NSError *error))resultsHandler{
if (resultsHandler != nil){
[[self context] performBlock:^{
NSArray *fetchResults = [[self context] executeFetchRequest:request error:&error];
resultsHandler(fetchResults, error);
}];
}
}
Which you would call like this:
[self doThingsWithFetchResults:^(NSArray *something, NSError *error){
if ([something count] > 0){
// Do stuff with your array of managed objects
} else {
// Handle the error
}
}];
That said, always prefer using an NSFetchedResultsController over using executeFetch:. There seems to be a belief that NSFetchedResultsController is for powering table views or that it can only be used from the main thread or queue. This is not true. A fetched results controller can be used with a private queue context as shown above, it does not require a main queue context. The delegate callbacks the fetched results controller emits will come from whatever queue it's context is using, so UIKit calls need to be made on the main queue inside your delegate method implementations. The one issue with using a fetched results controller this way is that caching does not work due to a bug.
Again, always prefer the higher level NSFetchedResultsController to executeFetch:.
When you save a context using queue confinement you are only saving that context, and the save will push the changes in that context to it's parent. To save to the store you must recursively save all the way. This is easy to do. Save the current context, then call save on the parent as well. Doing this recursively will save all the way to the store - the context that has no parent context.
Example:
- (void) saveContextAllTheWayBaby:(NSManagedObjectContext *)context {
[context performBlock:^{
NSError *error = nil;
if (![context save:&error]){
// Handle the error appropriately.
} else {
[self saveContextAllTheWayBaby:[context parentContext]];
}
}];
}
You do not, and should not, use merge notifications and mergeChangesFromContextDidSaveNotification: with queue confinement. mergeChangesFromContextDidSaveNotification: is a mechanism for the thread confinement model that is replaced by the parent-child context model. Using it can cause a whole slew of problems.
Following the examples above you should be able to abandon thread confinement and all of the issues that come with it. The problems you are seeing with your current implementation are only the tip of the iceberg.
There are a number of Core Data sessions from the past several years of WWDC that may also be of help. The 2012 WWDC Session "Core Data Best Practices" should be of particular interest.
if you want to use managed object context in background thread, there are two approaches,
1 Create a new context set concurrency type to NSPrivateQueueConcurrencyType and set the parentContext to main thread context
2 Create a new context set concurrency type to NSPrivateQueueConcurrencyType and set persistentStoreCoordinator to main thread persistentStoreCoordinator
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
NSManagedObjectContext *privateContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
privateContext.persistentStoreCoordinator = mainManagedObjectContext.persistentStoreCoordinator;
[[NSNotificationCenter defaultCenter] addObserverForName:NSManagedObjectContextDidSaveNotification object:nil queue:nil usingBlock:^(NSNotification* note) {
NSManagedObjectContext *moc = mainManagedObjectContext;
if (note.object != moc) {
[moc mergeChangesFromContextDidSaveNotification:note];
}
}];
// do work here
// remember managed object is not thread save, so you need to reload the object in private context
});
before exist the thread, make sure remove the observer, bad thing can happen if you don't
for more details read http://www.objc.io/issue-2/common-background-practices.html
I have been using Core Data with a single NSManagedObjectContext for a long time, all fetching, saving, background update operations will be done on single context through helper classes, I was planning to implement a multiple NSManagedObjectContext approach (which is the recommended solution in most of my searching).
My question is: is performBlock the only was to execute code for that context? Can't we do something like below:
- (void) checkSyncServer {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
//do something here, check and fetch data
// create NSManagedObject's
[_tempContext save:&error];
//masterContext will merge changes through notification observers
});
}
(i.e) execute code apart from -performBlock method. How can I execute multiple asynchronous methods and perform a save?
However, I find a single context (which is managed by one singleton NSObject class) simpler to use.
This multiple context with ContextConcurrencyType looks more complicated (in terms of execution flow). Is there a better solution?
You can access contexts in one of two ways:
On its Thread/Queue. This applies to confined contexts and main queue contexts. You can access them freely from their own thread.
With -performBlock: if it is a private queue context or if you are touching the context from a thread other than the one it belongs on.
You cannot use dispatch_async to access a context. If you want the action to be asynchronous then you need to use -performBlock:.
If you were using a single context before and you were touching it with a dispatch_async you were violating the thread confinement rule.
Update
When you call [[NSManagedObjectContext alloc] init] that is functionally equivalent to [[NSManagedObjectContext alloc] initWithConcurrencyType:NSConfinementConcurrencyType].
The NSManagedObjectContext has always been thread confined.
As for executing multiple methods you can just call them all in the same block:
NSManagedObjectContext *moc = ...;
[moc performBlock:^{
//Fetch something
//Process data
//Save
}];
Or you could nest them if you wanted them to be all async of each other:
NSManagedObjectContext *moc = ...;
[moc performBlock:^{
//Fetch Something
[moc performBlock:^{
//Process Data
}];
[moc performBlock:^{
//Save
}];
}];
Since -performBlock: is re-entrant safe you can nest them all you want.
Update Async save
To do an async save you should have two contexts (or more):
Main Queue context that the UI talks to
Private Queue context that saves
Private context has a NSPersistentStoreCoordinator and the main queue context has the private as its parent.
All work is done in the main queue context and you can save it safely, normally on the main thread. That save will be instantaneous. Afterwards, you do an async save:
NSManagedObjectContext *privateMOC = ...;
NSManagedObjectContext *mainMOC = ...;
//Do something on the mainMOC
NSError *error = nil;
if (![mainMOC save:&error]) {
NSLog(#"Main MOC save failed: %#\n%#", [error localizedDescription], [error userInfo]);
abort();
}
[privateMOC performBlock:^{
NSError *error = nil;
if (![privateMOC save:&error]) {
NSLog(#"Private moc failed to write to disk: %#\n%#", [error localizedDescription], [error userInfo]);
abort();
}
}];
If you already have an app, all you need to do is:
Create your private moc
Set it as the parent of your main
Change your main's init
Add the private block save method whenever you call save on your main
You can refactor from there but that is all you really need to change.
I have a NSOperation that I put in a queue. The NSOperation does some long running photo processing then I save the information/meta data in core data for that photo. In the main method of my custom NSOperation class is where I execute the below block of code
-(void)main
{
//CODE ABOVE HANDLES PHOTO PROCESSING...
//........
//THEN I SAVE ALL DATA BELOW LIKE SO
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext) {
Post *post = [Post createInContext:localContext];
//set about 15 pieces of data, all strings and floats
post.XXXX = XXXXX;
post.DDDD = DDDDD;
etc...
} completion:^(BOOL success, NSError *error) {
NSLog(#"Done saving");
}];
}
My issue is that even with only 3 photos when it saves it really freezes my UI. I would have thought executing this in the NSOperation I would be fine.
I should add that each NSOperation processes one photo, so at times the queue could have 5-10 photos, but I would not think this would make any difference, even with just three like I said its freezing the UI.
Thank you for the help.
UPDATE:------------*--------------
I switched to version 2.2 but that seems to be blocking the UI even more...also now I'm using
-(void)main
{
NSManagedObjectContext *localContext = [NSManagedObjectContext contextForCurrentThread];
//CODE BELOW HANDLES PHOTO PROCESSING...
//........
//THEN I SAVE ALL DATA BELOW LIKE SO
Post *post = [Post createInContext:localContext];
//set about 15 pieces of data, all strings and floats
post.XXXX = XXXXX;
post.DDDD = DDDDD;
[localContext saveToPersistentStoreWithCompletion:^(BOOL success, NSError *error) {
}];
}
This is all done in my NSOperation class, am I doing something wrong?
Don't put the saveWithBlock calls in a background thread. You're effectively creating a background thread from a background thread, which, in this case, is just slowing you down. You should just be able to call saveWithBlock and it should put all your saving code in the background. However, I'm also noticed that you make all your changes in the main UI page of the code, and only call save afterward. This is the wrong usage of this method. You want to do something more like this:
[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext) {
Post *post = [Post createInContext:localContext];
//photo processing
//update post from photo processing
} completion:^(BOOL success, NSError *error) {
//This is called when data is in the store, and is called on the main thread
}];
If you do need an NSOperation, I suggest a different pattern:
- (void) main {
NSManagedObjectContext *localContext = [NSManagedObjectContext confinementContext];
// Do your photo stuff here
Post *post = [Post createInContext:localContext];
//more stuff to update post object
[localContext saveToPersistentStoreAndWait];
}
Be careful in how you start the operation.
[operation start]
will start the operation on the current thread, so if you call it from the main thread (which is the UI one) it will block the interface.
You should add the operation to a queue, so that it runs in background without hogging the main thread
[[NSOperationQueue new] addOperation:operation];
I have an iOS app which is accessing a core data sql database from two threads. Thread A (the main UI thread) updates a core data record, and Thread B then attempts to read from the Entity collection that Thread A has just updated. Trouble is, Thread B is not 'seeing' the change that Thread A persisted.
Thread B is created by adding an NSOperation subclass object to an NSOperationQueue. The main method of the NSOperation subclass looks like this:
-(void) main {
// NEED to create the MOC here and pass to the methods.
NSManagedObjectContext* moc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSConfinementConcurrencyType];
[moc setUndoManager:nil];
[moc setMergePolicy:NSMergeByPropertyStoreTrumpMergePolicy]; // Had been working for months
[moc setPersistentStoreCoordinator:getApp().persistentStoreCoordinator];
[self doTheWorkWithMOC:moc]; // Actually performs updates, using moc
moc = nil;
}
Later, Thread B saves its changes as follows:
#try {
// register for the moc save notification - this is so that other MOCs can be told to merge the changes
[[NSNotificationCenter defaultCenter]
addObserver:getApp()
selector:#selector(handleDidSaveNotification:)
name:NSManagedObjectContextDidSaveNotification
object:moc];
NSError* error = nil;
if ([moc save:&error] == YES)
{
NSLog(#"%s SAVED FINE",__FUNCTION__);
}else {
NSLog(#"%s NOT saved, error=%# %#",__FUNCTION__,error,[error localizedDescription]);
}
// unregister from notification
[[NSNotificationCenter defaultCenter]
removeObserver:getApp()
name:NSManagedObjectContextDidSaveNotification
object:moc];
}
#catch (NSException * e) {
NSLog(#"%s Exception: %#",__FUNCTION__, e);
}
The main UI appdelegate contains the following code to handle the save notification:
- (void)handleDidSaveNotification:(NSNotification*) note
{
#try {
// Notifications run on the same thread as the notification caller.
// However, we need to ensure that any db merges run on the main ui thread.
// Hence:
[self performSelectorOnMainThread:#selector(mergeContexts:) withObject:note waitUntilDone:NO];
}
#catch (NSException * e) {
NSLog(#"appDelegate handleDidSaveNotification Exception: %#", e);
}
}
-(void)mergeContexts:(NSNotification*) note
{
if ([__managedObjectContext tryLock]==YES)
{
[__managedObjectContext mergeChangesFromContextDidSaveNotification:note];
[__managedObjectContext unlock];
}
}
It all works fine most of the time.
However, I have one iPad where the changes written by Thread B are not detected when Thread A reads the database.
Can anyone see anything in my code which would cause this?
Many thanks
Journeyman,
First, you should move to using the queue based MOCs introduced in iOS v5 and Lion. This will make it much easier to keep your two MOCs in sync. You will no longer need to use the locking system.
Second, once you've moved to the queued MOCs, then it is quite straightforward to keep them in sync in response to the "did save" notifications.
Third, why are you always adding and removing the observer for the did save notifications? Doesn't that look suspicious to you? Clearly, you are missing some update between the MOCs.
Andrew