0

I have a question model object which has a to many relationship with attempts on that question.

I'm using a Fetched Results Controller to list out the questions. When I tap on a question in the table view, it loads up a detail view with the question.

When an answer is submitted, I want to attach another attempt to the question object so I have a history of attempts.

Here's where things get weird. There is no table view on screen when an answer is submitted, but at the moment I define the relationship between the attempt and the question (i.e. attempt.question = currentQuestion), it causes the underlying fetched results controller to crash.

It seems to be calling the frc delegate method controller:didChangeContent:atIndexPath:forChangeType:newIndexPath: twice, the first for an update (which makes sense, as the question object has changed), but the second for an insert (which doesn't make sense, as no question objects have been deleted or inserted).

The fetch request for the fetched results controller queries only on the question object and isn't interested with attempts on that question.

This happens whether attempts are an ordered or unordered to-many relationship and only on a device, not on the simulator.

I'd appreciate any help with figuring out why this is happening.

Simon Fairbairn
  • 65
  • 8
  • Which Xcode version, which iOS, Simulator or device? Perhaps the same issue as this one: http://stackoverflow.com/questions/31383760/ios-9-attempt-to-delete-and-reload-the-same-index-path ? – Martin R Jul 27 '15 at 09:12
  • Xcode 7. Yes, it's the same error (except it's calling `.Insert` in my case, rather than `.Move`), but the fix worked. Thanks very much. – Simon Fairbairn Jul 27 '15 at 09:15
  • But for `.Insert` only `newIndexPath` is valid. Does the same check `if indexPath != newIndexPath` really solve the problem? Perhaps you can update your question with a log of the events together with the "old" and "new" index path. – Martin R Jul 27 '15 at 09:20

1 Answers1

0

Thanks to Martin R, who pointed me to this solution.

For some reason, even though in my case it's an .Insert event rather than a .Move event as in the linked question, the call to the delegate has still populated the newIndexPath parameter with the same index path as the atIndexPath parameter.

Performing an inequality check against these two parameters before allowing the table view to insert the rows fixes the problem, as the two objects are identical:

(lldb) po indexPath
▿ Optional(<NSIndexPath: 0xc000000000008016> {length = 2, path = 0 - 1})

(lldb) po newIndexPath
▿ Optional(<NSIndexPath: 0xc000000000008016> {length = 2, path = 0 - 1})
Community
  • 1
  • 1
Simon Fairbairn
  • 65
  • 8