Ресткит и тупик - PullRequest
Новая
       35

Ресткит и тупик

2 голосов
/ 22 марта 2012

В настоящее время я использую Restkit для управления всеми моими (Core-) данными в моем приложении.Я использую его для синхронизации с сервером с помощью RKManagedObjectMapping и использую [myMyNSManagedObject createEntitity] вместе с [[RKObjectManager §sharedManager] .objectStore save] для ручного редактирования элементов в Grand Central Dispatch.

Есть лиЛюбая рекомендация сделать это так или иначе?Потому что иногда приложение зависает в тупике, выполняя этот код Restkit 

+ (NSArray*)objectsWithFetchRequest:(NSFetchRequest*)fetchRequest {
    NSError* error = nil;
    NSArray* objects = [[self managedObjectContext] executeFetchRequest:fetchRequest error:&error];
    if (objects == nil) {
        RKLogError(@"Error: %@", [error localizedDescription]);
    }
    return objects;
}

с этим 

- (NSError*)save {
    NSManagedObjectContext* moc = [self managedObjectContext];
    NSError *error;
    @try {
        if (![moc save:&error]) {
            if (self.delegate != nil && [self.delegate respondsToSelector:@selector(managedObjectStore:didFailToSaveContext:error:exception:)]) {
…

параллельно.Прежде чем я переключился на Restkit, я поместил «context executeBlockAndWait» вокруг каждого кода редактирования сущности и был в безопасности, без блокировок.У меня нет другого NSManagedObjectContext или чего-то созданного мной, все происходит из Restkit.

Ответы [ 2 ]

0 голосов
/ 08 мая 2013

Мы столкнулись с этой точной проблемой в нашем приложении. По сути, вложенные контексты CoreData очень ошибочны в iOS5 и поэтому не работают так, как рекламируется. У этого есть много проявлений, но одним из них является проблема, описанная выше, блокировка запроса на выборку вместо фоновой операции. Это хорошо документировано , поучительная цитата:

NSFetchedResultsДейтрации контроллеров

Вы никогда не хотите, чтобы ваше приложение зашло в тупик. С NSFetchedResultsController и вложенными контекстами это сделать довольно легко. Используя ту же настройку UIManagedDocument, которая описана выше, выполнение запросов на выборку в контексте частной очереди при использовании NSFetchedResultsController с контекстом основной очереди, скорее всего, приведет к взаимоблокировке. Если вы начинаете оба одновременно, это происходит с почти 100% согласованностью. NSFetchedResultsController, вероятно, получает блокировку, которой не должно быть. Это было исправлено в следующем выпуске iOS.

Этот SO-ответ содержит возможное исправление, которое сохраняет вложенные контексты. Я видел других, как это, в основном либерально применяя -performAndWait: звонки. Мы еще не пробовали это (iOS5 имеет однозначный процент в нашей базе пользователей). Иначе, единственное другое «исправление», которое мы знаем прямо сейчас, - это отказ от вложенных контекстов для iOS5 (см. этот ответ SO ).

То, что CoreData по-прежнему в корне нарушает многопоточность (в iOS 5), непростительно со стороны Apple. Вы можете сделать хороший пример сейчас, когда доверие Apple к CoreData (многопоточность, iCloud), кажется, открывает мешок с болью.

0 голосов
/ 21 ноября 2012

В моем случае проблема заключалась в том, что я передавал NSManagedObjects через границы потоков и использовал их в потоках, отличных от тех, в которых они были извлечены из соответствующих NSManagedObjectContext.Это было очень тонко в моем случае, так как я знал, что не должен был этого делать, но все равно сделал это случайно.Вместо того, чтобы передавать управляемые объекты, я начал передавать NSManagedObjectIDs (а затем извлекать их из MOC локального потока) и с тех пор не обнаруживал тупиковых ситуаций.Я бы порекомендовал вам выполнить глубокое сканирование кода, чтобы убедиться, что вы используете только управляемые объекты в потоках, которые их породили.

...