If you are using CoreData, most likely you need to be informed of changes to your table when you have either uploaded or deleted data.

The best way is to use this callback to update the table.  Sample code below:

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
// The fetch controller has sent all current change notifications, so tell the table view to process all updates.

//    reload the list of region
NSMutableArray *array = [[NSMutableArray alloc] initWithCapacity:0];
[array addObject:@"All"];
NSEnumerator *region = [[fetchedResultsController sections] objectEnumerator];
id <NSFetchedResultsSectionInfo> sectionInfo;
while (sectionInfo = [region nextObject]) {
[array addObject:[sectionInfo name]];
}
wineRegionList = array;
wineRegionIndex = 0;

//    reset region to default value
regionVC.wineRegionList = wineRegionList;
regionVC.wineRegionIndex = wineRegionIndex;
[regionVC.tableView reloadData];
[array release];
}

This is interesting.  Got some examples of UISearchBar and the like of capturing the text input and resignFirstResponder when finished with search.

Core Data has good examples of tableView and how to retrieve and display data.

However, not much info is available, even from books, blogs and others on how to use UISearch with an existing TableView with data from Core Data.

Seems like you are on your own when using these 3 related APIs. Together, these 3 APIs can give you the best way to view and search data fetched  using Core Data.

Core Data gives you good memory management when using a large database.  Data is faulted, read from the database for viewable cells.  No need to create a huge array to hold the data.

One way to differentiate which table to display; i.e. normal or searched can be dependent on

// when we start/end showing the search UI
- (void) searchDisplayControllerWillBeginSearch:(UISearchDisplayController *)controller
{
useSearch = YES;
}

- (void) searchDisplayControllerDidEndSearch:(UISearchDisplayController *)controller
{
useSearch = NO;
}

You can use this flag to determine which table to view for your UITableViewDelegate methods.

// called when cancel button pressed
- (void)searchBarCancelButtonClicked:(UISearchBar *) searchBar {
searchBar.text = nil;
[searchBar resignFirstResponder];
[searchBar setShowsCancelButton:YES animated:YES];

//    reset the fetch search controller
fetchedSearchResultsController = nil;
}

You also need to reset the fetchedSearchResultsController at the end of search.  Have to make sure that search results are refreshed upon new search.

Looks like I got some problem with the managed object retain cycle.  Was working fine in previous cell feed version.  Got a series of repeating values during import of data.  Need to have a closer look at the Core Data docs for more info.  Did follow the standard efficient importing earlier.

[object release];
[managedObjectContext save:&error];
[managedObjectContext refreshObject:object mergeChanges:NO];

Sorted out the search text criteria for search list.  But the search expression is currently too crude.  Need a better way to identify words within name.

Using the basic like[c] expression which is grossly inadequate.  Maybe regular expression or a combination of predicate complex expressions to cater for this.

Found a nice solution for this iTunes like search from Cocoa Is My Girlfriend.

Overkill with above solution; just use @”x contains[c] %@” will do.

Most search are based on existing table data that is fetched.  This involves creating another list filtered on the existing list.  This is alright for small list.  For bigger list in terms of thousands of items, you need to justify that memory space in maintaining two sets of list.  Memory is always a premium in iPhone.

The usual fetch request when using is great for the initial list.  For searchable  list based on the UISearchBar, you are likely to type in the criteria string for the list.  This is where predicates will be most useful.  You can setup a predicate based on your search text and pass it as a parameter in your predicates before fetching the search list.

This has the advantage of having a single round trip in fetching the new list.  Also, you do not need to create two lists for the usual search.  That being said, now I need to put this into action.