在没有 UITableViewController 的情况下使用 NSFetchedResultsController

发布于 2024-09-10 13:11:21 字数 1596 浏览 2 评论 0原文

我在尝试使用 NSFetchedResultsController 而没有相应的 UITableViewController 时遇到了问题。

根据苹果文档

“ NSFetchedResultsController 旨在有效管理从 Core Data 获取请求返回的结果,以为 UITableView 对象提供数据。”

因此,我首先研究了是否建议使用不带 UITableViewController 的 NSFetchedResultsController 并遇到 这篇 Stackoverflow 帖子结论是,至少在某些情况下,这不是一个坏主意。

但现在我遇到了一个问题,当相应的 UITableViewController 不存在时,NSFetchedResultsController 的行为有所不同。问题是当 UITableViewController 不存在时, NSFetchedResultsController 返回的对象没有 IndexPaths。我已在 stackoverflow 帖子 中记录了此问题。 (请注意,这是问题的简化,在某些情况下,对象确实具有 IndexPaths,但我遇到了足够多的问题,相信期望没有 UITableViewController 的 IndexPaths 是一个坏主意。)

没有 IndexPaths,我无法按排序顺序访问返回的对象,也无法访问特定对象。所以我正在寻找一种让 NSFetchedResults 控制器返回带有 IndexPaths 的对象的方法,或者一种访问对象的替代方法。 (或者也许我根本不应该使用 NSFetchedResultsController?)

对于替代方法,一种解决方法是将 fetchedObjects 传递给数组,然后使用该数组。但根据我的经验,创建指向 FRC 对象的新指针总是会导致问题。我认为每次我尝试用自己的指针保留 NSManagedObject 时,它最终都会导致错误。

仅供参考,我想要创建的是一个类似于照片中导航栏的导航栏。如果您想象可以动态地将照片添加到“照片”应用程序中,那么由 NSFetchedResultsController 管理栏中的照片是有意义的——这样添加新照片就会动态添加到栏的末尾,就像如何将新对象动态添加到 UITableView 中。

感谢您提供任何可以帮助我的想法!

更新 这个问题(暂时)通过使用 -[NSFetchedResultsController fetchedObjects] objectAtIndex:] 解决

I'm running into problems trying to use a NSFetchedResultsController without a corresponding UITableViewController.

According to Apples documentation:

"NSFetchedResultsController is intended to efficiently manage the results returned from a Core Data fetch request to provide data for a UITableView object."

So I first researched whether using the NSFetchedResultsController without a UITableViewController was advisable and encounter this Stackoverflow post where it is concluded that, at least in some circumstances, it's not a bad idea.

But now I've encountered an issue where the NSFetchedResultsController behaves differently when a corresponding UITableViewController isn't present. The problem is when a UITableViewController is not present, the objects returned by the NSFetchedResultsController do not have IndexPaths. I've documented this problem in a stackoverflow post. (Note this is a simplification of the issue, in some circumstances the objects do have IndexPaths, but I've encountered enough problems to believe that expecting IndexPaths without a UITableViewController is a bad idea.)

Without IndexPaths, I can't access the returned objects in their sort order, and I can't access specific objects. So what I am looking for is either a way to get the NSFetchedResults controller to return objects with IndexPaths, or an alternative way to access the objects. (Or perhaps I shouldn't be using an NSFetchedResultsController at all?)

Re alternative methods, one work around would be to pass the fetchedObjects to an array, and then work with that array. But in my experience creating new pointers to FRC objects always causes problems. I think every time I've ever tried to retain an NSManagedObject with my own pointers it has eventually caused a bug.

FYI, what I am trying to create is a navigation bar similar to the navigation bar in Photos. If you imagined you could dynamically add photos to the Photos application, then it would make sense for the photos in the bar to managed by an NSFetchedResultsController -- so that adding a new photo would be dynamically added to the end of the bar, much like how adding a new object is dynamically added to a UITableView.

Thanks for any ideas you might be able to help me out with!

UPDATE this issue is (tentatively) solved by using -[NSFetchedResultsController fetchedObjects] objectAtIndex:]

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

不爱素颜 2024-09-17 13:11:21

这是通过使用 -[NSFetchedResultsController fetchedObjects] objectAtIndex:] 来解决的。

NSFetchedResultsController 表现为托管对象的集合,类似于 NSArray,这使得它易于使用。事实上,它公开了一个名为 fetchedObjects 的 NSArray 类型的只读属性,以便更轻松地访问它获取的对象。

This is solved by using -[NSFetchedResultsController fetchedObjects] objectAtIndex:]

NSFetchedResultsController behaves as a collection of managed objects, similar to an NSArray, which makes it easy to use. In fact, it exposes a read-only property called fetchedObjects that is of type NSArray to make things even easier to access the objects it fetches.

半城柳色半声笛 2024-09-17 13:11:21

使用 -[NSFetchedResultsController fetchedObjects] 有什么问题吗?当你说你在创建新指针并保留它们时遇到问题时,我不太确定你的意思是什么 - 你能解释更多吗?您通常不必保留 NSManagedObject(它们是根据需要获取和出错的),因此这可能是问题所在。

Is there anything wrong with working with -[NSFetchedResultsController fetchedObjects]? I'm not quite sure what you mean when you say you running into problems creating new pointers and retaining them--could you explain more? You shouldn't usually have to retain NSManagedObjects (they're fetched and faulted as needed), so that might be the issue.

从此见与不见 2024-09-17 13:11:21

(请注意,这是以下内容的简化
问题,在某些情况下
对象确实有 IndexPaths,但我已经
遇到足够多的问题值得相信
期望 IndexPaths 没有
UITableViewController 是一个坏主意。)

UITableView 和 NSFetchedResultsController 都使用 NSIndexPath UIKit Additions 对 NSIndexPath 的扩展。该扩展类生成具有显式部分和行属性的索引路径。这些路径应该使用以下方式手动创建:

+[NSIndexPath indexPathForRow:inSection:]

如果您使用其他方法创建indexPath,接收器必须推断部分和行属性。他们通常会正确推断,但错误的可能性仍然存在。

(Note this is a simplification of the
issue, in some circumstances the
objects do have IndexPaths, but I've
encountered enough problems to believe
that expecting IndexPaths without a
UITableViewController is a bad idea.)

Both UITableView and NSFetchedResultsController use the NSIndexPath UIKit Additions extensions to NSIndexPath. That extended class generates indexPaths with explicit section and row attribute. These paths should be manually created using:

+[NSIndexPath indexPathForRow:inSection:]

If you use other methods to create the indexPath, the receivers have to infer the section and row attributes. They will usually infer correctly but the possibility of error remains.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文