The table view’s index path controller. A default controller is created automatically with nil for identifierKeyPath, sectionNameKeyPath and cellIdentifierKeyPath. It is not uncommon to replace this default instance with a custom controller. For example, if Core Data is being used, one would typically provide a controller created with the initWithFetchRequest:managedObjectContext:sectionNameKeyPath:identifierKeyPath:cacheName: initializer.

The implementation of tableView:cellForRowAtIndexPath: calls this method to ask for the cell’s identifier before attempting to dequeue a cell. The default implementation of this method first asks the data model for an identifier and, if none is provided, returns the “Cell”. Data models that don’t use TLIndexPathItem as their item type typically return nil and so it is not uncommon to override this method with custom logic.

This method should be overridden to enable view controller-backed cells. The default implementation returns nil. If this method returns a view controller for the given cell and index path, the table view controller will automatically install the backing controller as a child view controller in cellForRowAtIndexPath and uninstall it in tableView:didEndDisplayingCell:forRowAtIndexPath:. This method is responsible for installing the view controller’s view into the cell’s view heirarchy.

Returns a prototype instance of the specified cell. This can be useful for getting basic information about the table view’s cells outside of the scope of any specific cell. For example, this method is used internally to automatically calculate the cell’s height in tableView:heightForRowAtIndexPath:.

Returns the backing view controller for the given cell, if any. This method is used internally and can also be called in custom code, for example when configuring the cell in cellForRowAtIndexPath. To enable view controller-backed cells, override the companion method tableView:instantiateViewControllerForCell:atIndexPath:.