Database Reference
In-Depth Information
tableView
.
deleteRowsAtIndexPaths
([indexPath],
withRowAnimation: .
Automatic
)
case
.Update:
let
cell =
tableView
.
cellForRowAtIndexPath
(indexPath)
as
TeamCell
configureCell
(cell, indexPath: indexPath)
case
.Move:
tableView
.
deleteRowsAtIndexPaths
([indexPath],
withRowAnimation: .
Automatic
)
tableView
.
insertRowsAtIndexPaths
([newIndexPath],
withRowAnimation: .
Automatic
)
default
:
break
}
}
func
controllerDidChangeContent(controller:
NSFetchedResultsController
!) {
tableView
.
endUpdates
()
}
Whew! That's a wall of code. Fortunately, it's mostly boilerplate and easy to
understand. Let's briefly go over all three methods you just added or modified:
•
controllerWillChangeContent:
This delegate method notifies you that changes
are about to occur. You ready your table view using
beginUpdates()
.
•
controller(_:didChangeObject...)
: This method is quite a mouthful. And with
good reason—it tells you exactly what objects changed, what the type of change
was (insertion, deletion, update or reordering) and what the affected index paths
are.
This middle method is the proverbial glue that synchronizes your table view with
Core Data. No matter how much the underlying data changes, your table view will
stay true to what's going on in the persistent store.
•
controllerDidChangeContent:
The delegate method you had originally
implemented to refresh the UI turned out to be the third of three delegate
methods that notify you of changes. Rather than refresh the table view, you just
need to call
endUpdates()
to apply the changes.
Note:
What you end up doing with the change notifications depends on your
individual app. The implementation you see above is an example Apple
provided in the
NSFetchedResultsControllerDelegate
documentation. Note that
the order and nature of the methods ties in very neatly to the “begin updates-
make changes-end updates” pattern used to update table views. This is not a
coincidence!
