Add extra row to a UITableView managed by NSFetchedResultsController

Question

I'm using a UITableViewController for a table in my app, and I've added an NSFetchedResultsController to provide the data to show in the table (setting self as it's delegate).

However I would like to add a unique cell as the last cell of the table, unrelated to the items produced by the NSFetchedResultsController's predicate, I want this cell to always be at the bottom of the table.

I've tried simply added 1 to these methods in the table view data source:

- (NSUInteger)numberOfSectionsInTableView:(UITableView *)sender
{
    return [[self.fetchedResultsController sections] count] + 1;
}
- (NSUInteger)tableView:(UITableView *)sender numberOfRowsInSection:(NSUInteger)section
{
    return [[[self.fetchedResultsController sections] objectAtIndex:section] numberOfObjects] + 1;
}

And then catching the case where this extra row is being generated like so (the table only has 1 section):

- (UITableViewCell *)tableView:(UITableView *)sender
         cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (indexPath.row == [self.fetchedResultsController.fetchedObjects count]) {
        //Generate the last cell in  table.
    } else {
        //Generate the rest of the cells like normal.
    }
    return nil; //To keep the compiler happy.
}

This checks to see if the index is the last cell and deals with it appropriately.

However I am still getting the following error at runtime:

*** Terminating app due to uncaught exception 'NSRangeException', 
reason: '*** -[__NSArrayM objectAtIndex:]: index 1 beyond bounds [0 .. 0]'

Any idea what's causing this? Or is there a better way of adding an extra row to a table view controlled by an NSFetchedResultsController?

Answer 1

The fetched results controller is pretty tightly tied to the tableview, if you implement all the datasource methods as indicated in the documentation (the updates and so on). It will get pretty messy and hacky.

Could your "extra row" be the footer view of the table instead? This will always be at the bottom. It wouldn't be too much work to make it look like a cell, though from the look of it you want it to look different to the other cells anyway.

Answer 2

Given the table only has one section, this code looks wrong:

- (NSUInteger)numberOfSectionsInTableView:(UITableView *)sender
{
    return [[self.fetchedResultsController sections] count] + 1;
}

I suspect your crash arises when the tableview tries to retrieve the second section; the + 1 should be removed.

It's possible to do more complex things with tables sourced from fetched results controllers (see NSFetchedResultsController prepend a row or section ), so I'm sure this simple case can be made to work.

Answer 3

Why dont you just use the built in Header and Footer Views of UITableView?

Example:

UIView *customBottomView = [UIView alloc] init... //set up your View (what you called custom bottom cell)

self.table.tableFooterView = customBottomView; //alternatively tableHeaderView

Technically you are adding a view that is displayed below (or above) the table that is added to the table and handled wonderfully by the TableView. For users there is no way determine whether this is a (last) cell or simply a view. You'll just have to work around if you were planning on using methods like didSelectRowAtIndexPath

Answer 4

You definitely don't want to hack the index paths, and headers won't do because cells have many advantages you won't want to lose.

So the Apple way to solve this to first make a super-entity. Then make another new entity for the row you want to add, and make it a sub-entity. Then make your existing row entity you were fetching also a sub-entity. Then change your fetch controller's fetch entity to this super-entity, so it will return both of the sub-entities in the results. In the super-entity add a sortOrder property, and set it to 1 on the row you want to appear first, and 2 on all the other rows, this is what makes the new row appear at the top.

This is how Apple implement the Folders list view in the iOS Notes app. The fetch controller's entity is NoteContainer, the 2 sub-entities are Account and Folder. The "All iCloud" row at the top is an Account and the rest are Folder.

NoteContainer (sortOrder)
- Account (1)
- Folder (2)

Note trash is also a folder but with its sort order 3 so it appears last.

The wider lesson here is to model your entities on how you wish them to appear in the UI using a fetch controller, rather than like how you would in a normalised relational database.