Core Data: Using the NSFetchedResultsController class
If you are displaying data from a Core Data store, a NSFetchedResultsController can help you with most of the leg work getting the UITableView segmented and displaying quickly. Segmenting a UITableView into sections from data in your store can be tricky but the NSFetchedResultsController class makes it painless, using the sectionNameKeyPath attribute.
What the NSFetchedResultsController does for you:
- Caches results application wide, identified by a cache key
- Manages the stored results for the controller
- Notifies your controller when records are updated or changed to allow the interface to reflect changes
- Segments data by a key into sections for the UITableView, see sectionNameKeyPath
- Simple methods to fill in the necessary UITableViewDataSource methods like tableView:numberOfRowsInSection:
If you have been using a NSArray or NSDictionary to pass around Core Data results you will find the NSFetchedResultsController a final proper solution to do what you need. It's not hard to implement and with little change to any existing code. It's just a matter of adding NSFetchedResultsControllerDelegate to your UITableViewController class, adding in the alloc methods for the request object on your controller and finally changing the data source methods to fetch their information from the NSFetchedResultsController property.
Atebits fast scrolling: Using CoreGraphics
Developer of the much loved Twitter for iPhone, formerly Tweetie, application has revealed an insight into a method to speeding up a UITableViewCell even more. It uses a technique where you render the cell's content using CoreGrahpics on a custom UITableViewCell impelementation.
Basically the technique is to give the table a cell that has been flattened. Traditionally you would layer UITextView's and UIImageView's on the UITableViewCell and that would be that. This method makes you do the same but render the layers out to a flattened layer. It's not a technique that you may have to implement but its worth knowing the deeper operations of the UITableView.
So when the cell is requested, the custom UITableViewCell class is allocated and initialised. Then the drawContentView: method is called and what happens next is the layers are then drawn onto the UIView, like flattening or rasterising a Photoshop document from many layers to one layer. This way the cell is a rendered graphic that the UITableView can throw around with ease.
For more information and sample code on this practice you can see Atebits post: http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-UITableView/
This is not common in all applications however with a graphically intense cell this may be a better option than a typical layered UIView.
Getting down to brass tacks
In a summary of what has been covered there are a few things to always have in your mind when developing a UITableView:
- Keep the data source methods as light as possible.
- Manage your memory efficiently and implement the Lazy Loading practice.
- Investigate alternative User Interfaces to cut down or refine the cell to make it faster to display.
- Use helpful classes in the API, like NSFetchedResultsController, where applicable
- Analyse your code using Instruments and make sure there are no leaks.