Информация о разделе NSFetchedResultsController, кажется, сохраняется, даже если FRC установлен на ноль?

У меня есть вид головы (вид A) с сегментированным элементом управления. Сегмент 0 загружает FRC, задает путь к секции имя и ключ из непереходного свойства и выполняет сортировку по нему.

Сегмент 1 загружает FRC, устанавливает sectionNameKeyPath из переходного свойства (месяц и год, как в примере Apple) и сортирует по тому же непереходному свойству, что и сегмент 0.

Когда щелкают ячейку FRC сегмента 0, она переходит к представлению B, здесь новый FRC загружает объекты, специфичные для выбора, с использованием предиката. Он устанавливает свой sectionNameKeyPath из второго переходного свойства и сортирует по тому же непереходному свойству, что и два других.

Вот что происходит:

  1. Вид А:

    Переключение между сегментами 0 и 1 несколько раз. FRC загружают то, что должны.

    Выберите ячейку в сегменте 0 --> это правильно подтолкнет View B

  2. Вид Б:

    FRC загружается по назначению.

    Нажмите кнопку «Назад» --> вид правильно закрыт, чтобы вернуться к виду A.

  3. Вид А:

    Сегмент 0 и его FRC правильно загружены и показаны

    Select segment 1: Error:

"has an out of order section name **segment name from View B's section**"

Я нахожу очень странным, что ошибка, которую он выдает, содержит имя раздела из FRC в предыдущем представлении. Я устанавливаю FRC и его делегата на ноль, когда представление WillDisAppear.

Когда я делаю точку останова переходных свойств, я вижу, что он запрашивает только FRC сегмента 1, поэтому не имеет смысла, что он все еще может видеть разделы View B?


ios objective-c uitableview core-data nsfetchedresultscontroller
person BossBols    schedule 05.06.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Проблема может быть связана с тем, что вы используете один и тот же кеш для обоих экземпляров NSFetchedResultsController. Передайте разные имена кеша при создании экземпляра,

_fetchController = [[KREFetchedResultController alloc] initWithFetchRequest:request
                                                       managedObjectContext:context
                                                         sectionNameKeyPath:@"sectionKey"
                                                                  cacheName:@"mycache"];

Вы также можете удалить кеш, когда это не требуется, вызвав метод класса NSFetchedResultsController deleteCacheWithName: для удаления определенного кеша, содержащего информацию о кешированном разделе,

/* Deletes the cached section information with the given name.
    If name is nil, then all caches are deleted.
*/
+ (void)deleteCacheWithName:(NSString *)name;

Или передайте nil, чтобы удалить все кеши.

Если вы не хотите кешировать, укажите имя кеша как nil при создании контроллера извлеченных результатов.

Надеюсь, это поможет!

person Amar    schedule 05.06.2014
comment
Спасибо, Амар, но у меня уже были все три FRC с нулевым кешем, потому что иногда он капризничает. Странно то, что я попытался настроить кеш View B, и он только один раз разбился, после чего он снова работает. (Кроме кешированного, конечно, не обновляющегося). Возможно, мне следует дать им всем кеш и удалять его каждый раз, когда загружается новое представление? Или каким-то образом поддерживать этот FRC только в этом представлении. - person BossBols; 05.06.2014
comment
Если я изменю sectionNameKeyPath FRC 1 на то же переходное свойство, что и FRC View B, этого сбоя не произойдет. Значит, что-то пошло не так с разделами, потому что эти FRC получают данные от одного и того же объекта, но с разными разделами? Я установил все на ноль при переходе к представлениям, поэтому я не понимаю, почему одно все еще может мешать другому:/ - person BossBols; 06.06.2014

arrow_upward
0
arrow_downward

  • Пункт списка

Я думаю, что решил это.. Точки останова почти на каждой строке кода, но это ни к чему не привело. Кэширование отдельно не решило эту проблему.

Я установил для своих контроллеров и их делегатов значение nil в последних строках метода prepareforsegue. Я переместил этот код в метод if конкретного перехода.

if ([[segue identifier] isEqualToString:@"segueID"]) {

//set destination VC's properties first since they might come from the FRC.

 _fetchedResultsController.delegate = nil;
 _fetchedResultsController = nil;
}

и это вдруг работает.. Очень странно, я думал, что это будет выполнено в любом случае, либо в viewDidUnload, либо в конце prepareForSegue. По какой-то причине эти делегаты FRC очень постоянны между контроллерами представления.

Обновлять:

Я также сделал опечатку в своем переходном свойстве. Почти уверен, что это было. PrimitiveProperty1 устанавливался с переходными свойствами 1 и 2 ... Думаю, автозаполнение заполнило его :)

person BossBols    schedule 06.06.2014