NSManagedObject as MKAnnotation and Core Data Concurrency - ios

Question

I am using what I think is a fairly typical implementation of a NSManagedObject subclass which conforms to MKAnnotation protocol so as to display in a MKMapView. See setters and getters:
-(CLLocationCoordinate2D)coordinate {
CLLocationCoordinate2D coord = EMPTY_LOCATION_COORDINATE;
BOOL validLong = (self.longitude != nil) && ([self.longitude doubleValue] != 0);
BOOL validLat = (self.latitude != nil) && ([self.latitude doubleValue] != 0);
if (validLong && validLat) {
coord.longitude = [self.longitude doubleValue];
coord.latitude = [self.latitude doubleValue];
}
return coord;
}
-(void)setCoordinate:(CLLocationCoordinate2D)coordinate {
if (coordinate.latitude != EMPTY_LOCATION && coordinate.longitude != EMPTY_LOCATION) {
self.latitude = [NSNumber numberWithDouble:coordinate.latitude];
self.longitude = [NSNumber numberWithDouble:coordinate.longitude];
} else {
self.latitude = nil;
self.longitude = nil;
}
}
-(NSString *)title {
NSString *str = [self.projectName copy];
return str;
}
This is working and not causing problems in production at all.
I was debugging some Core Data concurrency issues using Core Data multi-threading assertions and I find that it is flagging the gutter as a concurrency violation. My guess is that the MKMapview that calls for the coordinate is using a background thread and technically that is not allowed. That it works in production is, conceivably, not guaranteed.
I tried to wrap the getter in a [self.managedObjectContext performBlockAndWait^(void){ //set here }]; block but that causes thread locking fail.
Should I ignore the error and move on or is there some better practice for this purpose?

Answer 1

I could not find the reason for this. I verified that the NSManagedObject is on the main queue context. It is being asked for the coordinate on a queue that is not the main queue. What I did to fix is use a proxy object as annotation passed to the MKMapview instead of passing it directly. NSObject class conforming to the MKAnnotation protocol. Initialize with the coordinate and title from my NSManagedObject, pass that instead of the real deal.

Answer 2

First, the coordinate should be implemented as a transient including a magic keyPathsForValuesAffectingCoordinate method. You can start with an uncached transient for simplicity and then perhaps add the additional code to cache it if necessary.
Second, validation should be done using Core Data.
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/ObjectValidation.html#//apple_ref/doc/uid/TP40001075-CH20-SW1

Answer 3

I am not sure that there are not problems with my solution but it was way too complicated for me to make a proxy object. I have tested it and it does not seem to give a thread violation with the -com.apple.CoreData.ConcurrencyDebug option enabled. Since I know my NSManagedObjectContext is on the main queue I did:
- (NSString *) title {
if( [NSThread isMainThread] ) {
return [self.projectName copy];
} else {
__block NSString *title;
NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType: NSPrivateQueueConcurrencyType];
context.persistentStoreCoordinator = self.managedObjectContext.persistentStoreCoordinator;
[context performBlockAndWait: ^{
ActivityLocation *tmp = [context objectWithID: self.objectID];
title = [tmp.projectName copy];
}];
return title;
}
}
I did the same thing for coordinate and subtitle and any other method that was causing problems.
Apparently there is some "wait" operations related to the main queue because if I set the newly created context's parent to 'self's context, it deadlocks.
Interestingly, even though the newly created context is on the thread that is needed, it does not work without the performBlockAndWait: even though if I print the current thread with or without the performBlockAndWait: it prints the same thing.
If there are unsaved changes in the object's projectName property, the old values will be displayed since the persistentStoreCoordinator is used for the newly created context, but I have control over that, unlike my lack of control for which thread Apple calls my MKAnnotation methods on.
I hope this is useful to someone, even though I am responding to a question asked over six years ago!