如何以编程方式检索 Core Data 应用程序的表选择和表行？
我正在尝试制作一个核心数据应用程序，其中当您在 TableView 中选择一个“玩家”时，所有队友的列表会出现在第二个 tableView 中，其中一列表示这两个玩家在同一场比赛中玩了多少次“团队”（另一个实体）。
这让我完全陷入困境，因为虽然我知道如何从普通数组填充表格，但使用 ArrayControllers 和 Core Data 确实扰乱了我对情况的看法。
你会如何处理这个问题？
I'm trying to make a Core Data app in which when you select one "Player" in a TableView, and a list of all teammates appears in a second tableView, with a column for how many times those two players have played on the same "Team" (another entity).
This has got me completely stuck, because while I know how to fill up a table from a normal array, using ArrayControllers and Core Data has really cluttered up my view of the situation.
How would you approach this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的问题是绑定问题，而不是核心数据问题。 :-)
你绝对应该掌握 Cocoa Bindings 在处理核心数据之前。这是在文档中陈述的并且是非常正确的。
你的问题的主题似乎与正文不同，所以我都会回答。
除了显示队友
核心数据之外，假设您有一个表示 Player 实例的表。玩家拥有一支球队。球队有很多球员。因此，可以推断 Player 的实例有“team.players”（减去其自身）作为队友。无论您是否使用核心数据来管理模型，整体关系都是如此。
如果您通读并掌握了 Cocoa Bindings，您会发现使用基本的 Master/Detail 设置（为简单起见，为 Detail 部分使用额外的数组控制器）。您的 Master 数组控制器代表所有 Player 实例，而您的详细数组控制器代表 Teammates - 或 Master 的选择的“team.players”（减去其自身）。
Teammates 数组控制器将照常设置其实体和托管对象上下文（请参阅文档）。 “contentSet”将绑定到主阵列控制器的“selection”控制器键，并以“team.players”作为模型键路径。
技巧是使用 谓词。您可以使用数组控制器的过滤谓词来完成此操作。也许格式为“self != %@”，其中“%@”代表主阵列控制器的选择。我将把谓词（它本身是一个复杂的主题）留给您。请记住，您可以在代码 ([myController setFilterPredicate:myPredicate]) 中或使用绑定来设置它们。谓词也独立于核心数据。
获取选择
由于数组控制器负责表所代表的数组，因此最好询问数组控制器其选择是什么。一种方法是向其 -arrangedObjets 询问其 -selectedIndexes 处的对象。
您还可以询问它的 -selectedObjects。文档（API 参考和概念文档）中描述的这两种方法之间存在差异，您绝对应该理解，但是 询问控制器是最重要的概念，无论你是否使用NSArrayController 或一些符合 和 协议的自定义控制器。
免责声明： 在一次清酒社交晚会后匆忙输入。没有检查错误。 :-)
Yours is a Bindings problem, not a Core Data problem. :-)
You should definitely get a handle on Cocoa Bindings before dealing with Core Data. This is stated in the docs and is very true.
The subject of your question seems to differ from the body, so I'll answer both.
Showing the Teammates
Core Data aside, assume you have a table representing Player instances. Player has one Team. Team has many players. Therefore, it's inferred that an instance of Player has "team.players" (minus itself) as teammates. Whether you're using Core Data to manage the model or not, this is true of the overall relationships.
If you read through and master Cocoa Bindings, you'll find that this is not hard at all to set up using a basic Master/Detail setup (with an extra array controller for the Detail part, for simplicity). Your Master array controller represents all Player instances, while your detail array controller represents the Teammates - or the Master's selection's "team.players" (minus itself).
The Teammates array controller will have its entity and managed object context set up as usual (see the docs). The "contentSet" will be bound to the Master array controller's "selection" controller key, with "team.players" as the model key path.
The trick is to filter out the Master controller's selected player using predicates. This you can do with the array controller's Filter Predicate. Maybe one with a format of "self != %@", where "%@" represents the Master array controller's selection. I'll leave Predicates (a complicated topic unto itself) to you. Remember, you can set them in code ([myController setFilterPredicate:myPredicate]) or by using bindings. Predicates are independent of Core Data as well.
Getting Selection
Since the array controller is in charge of the array the table represents, it's best to ask the array controller what its selection is. One way is to ask its -arrangedObjets for the objects at its -selectedIndexes.
You can also ask it for its -selectedObjects. There are differences between these two approaches that are described by the documentation (API reference and conceptual docs) that you should definitely understand, but asking the controller is the most important concept, regardless of whether you use an NSArrayController or some custom controller that conforms to the and protocols.
Disclaimer: Typed hastily after a social Sake evening. Not checked for errors. :-)