ios - 如何在 TableView 中实现搜索(使用 FRC)

Question

基础很简单:只需实现 <UISearchBarDelegate,UISearchDisplayDelegate>在你的 TableView Controller 中。这是 an adequate tutorial .

诀窍是要意识到有两个 Controller :一个 TableView Controller 和一个搜索显示 Controller 。每个 Controller 都有自己的 TableView 。因此有两个 TableView 在起作用:普通 TableView 和搜索显示 TableView 。当委托(delegate)方法有一个 UITableView 参数时，区分传入的是哪个 TableView ，并相应地做不同的事情。

除了上述基础知识，数据结构成为我的主要挑战。更具体地说，如何过滤和存储搜索结果？我们有三种选择:

A.

• 普通 TableView 一个FRC

• 创建一个数组属性来存储结果

• 使用 filteredArrayWithPredicate过滤获取的对象(数组)

• 为FRC指定一个缓存，将获取的对象存储在内存中以提高性能

B.

• 普通 TableView 一个FRC

• 修改 FRC 的谓词以进行过滤。 Apple 文档指示执行此操作的 3 个步骤:

  1. 删除 FRC 缓存(最好不要一开始就使用)
  2. 改变谓词
  3. 调用 performFetch

C.

两个 FRC，每个 TableView 一个。 this popular post 的接受答案中提供了详细的实现。

---

我认为 A 是正确的方法。我的理由包括:

A 很好地完成了所有工作。而且它只需要对具有 FRC 属性的 TableView Controller 进行微不足道的更改。更具体地说，只是在每个委托(delegate)方法中区分两个 TableView ，并添加一个 NSArray 属性来存储获取结果。当然，还要添加过滤代码。

B 有一个潜在的缺点:FRC 委托(delegate)方法会混淆正在使用哪个提取请求？是搜索前，搜索中，还是搜索后？尽管可能有解决方案，但我认为只要解决方案 A 有效，就不值得花时间。

第二个缺点是，如果我们希望搜索结果即时更改。用户在搜索栏中输入的每个字母都会导致 FRC 执行 Fetch，这是相当昂贵的。

C 通过使用两个 FRC 避免了 B 的第一个缺点，但由于完全相同的原因，它遭受了第二个缺点。

其他需要考虑的事项:

• 在后台队列中进行过滤。因此，当用户在搜索栏中输入内容时，无论您的过滤有多昂贵，屏幕都不会被阻塞。

• 创建一个辅助方法来区分两个 TableView 。在相关委托(delegate)方法中调用辅助方法，使代码更简洁。

以上是我对 TableView 实现搜索的理解。如有错误，请帮忙指出。非常感谢。

Answer 1

我认为关于 UITableViews 和 FRC 存在一些概念错误。 FRC 只是一个从 Core Data 获取数据的类，并且与 MOC 一起确保它保持数据完整性，即使您有多个选项卡同时访问同一个数据库，每个选项卡都进行自己的更新。在幕后，有一些流程在起作用，以确保一个选项卡中的更新反射(reflect)在所有其他选项卡中。我实际上要说的是，如果您绕过推荐的方法，将会产生后果。

performFetch 输出可以存储在缓存中，如果出于某种原因需要执行 [tableview reloadData]，则可以跳过获取；您当然可以编程让 tableview 从多个来源获取数据，但我看不出有任何理由这样做。如果多个来源的唯一原因是在搜索之前跟踪结果，则应该有一种方法可以重置谓词，以便 FRC 获得所有(当前)记录。对于我的应用程序，将所有或所有记录放入搜索栏中，会导致谓词 1=1 获取所有记录。同样，这在单 View 应用程序中可能没有那么重要，但是具有多个并发更新的选项卡式应用程序将需要这样做以确保数据在所有地方都是最新的。