How to implement search in a table view (with FRC)

Question

The basics are simple: just implement <UISearchBarDelegate,UISearchDisplayDelegate> in your table view controller. Here is an adequate tutorial.

The trick is to realize that there are TWO controllers: a table view controller, and a search display controller. Each controller has its own table view. Hence TWO table views are in play: the normal table view and the search display table view. When delegate methods have a UITableView argument, diff which table view is passed in, and do different things accordingly.

Beyond above basics, data structure becomes a main challenge for me. More specific, how to filter and store the search results? We have three options:

A.

• One FRC for the normal table view

• Create an array property to store results

• Use filteredArrayWithPredicate to filter fetched objects (an array)

• Specify a cache for FRC to store fetched objects in memory to enahnce performance

B.

• One FRC for the normal table view

• Modify FRC's predicate to do the filter. Apple doc instructs 3 steps to do that:

  1. Delete FRC cache (better not to use one in the first place)
  2. Change predicate
  3. Invoke performFetch

C.

Two FRC, one for each table view. A detailed implementation is provided in the accepted answer of this popular post

---

I think A is the right way to go. My rationale include:

A does all the job well. And it only requires insignificant changes to a table view controller with FRC property. Being more specific, just diff between the two table views in every delegate methods, and add an NSArray property to store fetch results. And, of course, add the filtering code.

B has a potential drawback: FRC delegate methods will get confused on which fetch request is being used? Is the one before search, or during search, or after search? Although there might be solution out there, I don't think it worth the time provided that solution A is working.

The second drawback is that, if we want search results to change on the fly. Every single letter user types in search bar will cause FRC to performFetch, which is rather expensive.

C avoids B's first drawback by using two FRC, yet it suffers from the second for exactly same reason.

Other things to consider:

• Do filtering in a background queue. So when user type in search bar, screen won't get blocked no matter how expensive your filtering is.

• Create a helper method to diff between the two table views. Call the helper method in relevant delegate methods, which would make code cleaner.

Above are my understanding of implement search in table view. If there is any mistake, please help point it out. Many thanks.

Answer 1

I think there are some conceptual errors regarding UITableViews and FRC. The FRC is just a class to get data from Core Data and together with the MOC ensure that it retains data integrity, even if you have a several tabs that access the same database concurrently , each doing their own updates. Behind the scenes there are processes in play to ensure that an update in one tab gets reflected in all the other tabs. What I am actually saying is there are consequences if you bypass the recommended method.

The performFetch output can be stored in cache and skips fetching if for some reason you need to do a [tableview reloadData]; You can certainly program to get the tableview get its data from multiple sources but I do not see any reason for doing this. If the only reason for multiple sources is to keep track of the results before the search, there should be a way to reset the predicate in order for the FRC to get all the (current) records. In the case of my app, putting all or all records in the searchbar, results in a predicate 1=1 which gets all the records. Again, this may not be that relevant in a single view app, but a tabbed app with a number of concurrent updates will require this to ensure data is current all across.