iphone - objectAtIndex :0] numberOfObjects] > fetchLimit

Question

我目前遇到一个问题，当 FRC 的 fetchRequest 上的 fetchLimit 为 4 时，使用 NSFetchedResultsController 的 UITableViewController/UITableView 显示大约 86 个项目。我知道 86 个项目满足提取本身，我知道原因它们出现是因为 didChangeObject: atIndexPath... 被 86 中的每一个调用，我按默认实现的方式插入。

我的问题是为什么 fetchLimit 不限制 NSFetchedResultsController 尝试“更改”(在本例中插入)的对象数量？

我的应用程序用例是第一个选项卡显示我在应用程序启动时(在副线程上)获得的典型提要项目。我将它们保存到单独上下文中的 CoreData，最终合并到主线程的上下文中，并针对更改的内容启动 FRC 回调。我的问题专门针对不存在任何项目的初始情况。

---

这是我的 fetchRequest:

    NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init] autorelease];
fetchRequest.entity = [NSEntityDescription entityForName:ENTITY_CONTENT_ITEM inManagedObjectContext:managedObjectContext];

// Set a limit on the number of items returned
[fetchRequest setFetchLimit:4];

// Set a Predicate to limit the fetch to featured items only
[fetchRequest setPredicate:[NSPredicate predicateWithFormat:@"featured == YES AND contentType == %d", contentType]];

// Set the sort descriptors
NSSortDescriptor *sortDateDescriptor = [[[NSSortDescriptor alloc] initWithKey:@"sortDate" ascending:NO] autorelease];
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sortDateDescriptor]];

上面的 contentType 只是一种区分应该在此选项卡和其他选项卡中显示的内容的方法。 Featured 是项目的 bool 属性，更像是用于显示目的的开关。

这是我的 didChangeObject:

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath { 
  switch(type) {
    case NSFetchedResultsChangeInsert:
      [tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:newIndexPath] withRowAnimation:UITableViewRowAnimationFade];
      break;
    case NSFetchedResultsChangeDelete:
      [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
      break;
    case NSFetchedResultsChangeUpdate:
      [tableView cellForRowAtIndexPath:indexPath];
      break;
    case NSFetchedResultsChangeMove:
      [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
       // Reloading the section inserts a new row and ensures that titles are updated appropriately.
       [tableView reloadSections:[NSIndexSet indexSetWithIndex:newIndexPath.section] withRowAnimation:UITableViewRowAnimationFade];
       break;
  }
}

我知道这个问题很难回答，但即使解释 FRC 如何决定调用 didChangeObject 的次数也会很有帮助。

Answer 1

https://devforums.apple.com/thread/60319?tstart=0

对于那些可以访问它的人，请检查一下。 Apple 开发人员对 iOS4.0 中 CoreData/NSFetchedResultsController/UITableViewController 堆栈的更改进行了很好、快速的总结。

There were changes made in 3.2 and 4.0 to improve the caching and performance as well as fix known issues. The persistent caching is much more aggressive, and so people misusing the cacheName have run into trouble. Setting the cacheName to nil instead, or cleaning up usage and calling +deleteCacheWithName when appropriate are solutions to that. The section recalculation was improved to perform more computation via the database instead of in-memory whenever possible. Sectioning triggers whenever the cache is rebuilt (or if not using a cache, when performFetch is called). The .description workaround makes the keypath refer to an unmodeled property (the -description method) which cause the section calculation to work in memory instead since the db doesn't know anything about -description.

In 4.0, there were also changes to UITableView to fix a number of issues involving the UITableViewController delegate callbacks. People who needed to use -reloadData on earlier iOS releases to work around trouble should be able to use the finer grained callbacks on iOS4.

-BenT (Apple)

鉴于此，我在 fetchedResultsController initWithFetchRequest 调用中将 .description 添加到我的 sectionNameKeyPath 中。这显然使部分计算发生在内存中而不是磁盘上，这解决了我的部分认为它们拥有的项目比实际更多的问题。

这适用于 4.0，而在 3.0 中，我只是从 controllerDidChangeContent 回调中调用 reloadData。如果您有类似问题，请随时给我留言。