DZNEmptyDataSet
DZNEmptyDataSet copied to clipboard
dzenbot
Crash in dzn_original_implementation when working with PFQueryTableViewController (Parse)
Hi there,
I know this is random, but I'm getting a crash when working with a PFQueryTableViewController using the Parse SDK. Specifically, when I delete an object in the data set (through Parse) and call [self loadObjects], there's an exception on line 517:
The exact error itself is "Assertion failure in -[UITableView _endCellAnimationsWithContext:]", and the exception stack shows that dzn_original_implementation is the second-to-last call before the crash:
Any idea what's going on? I don't know enough about either the inner workings of Parse or DZNEmptyDataSet to track down what's going on. DZNEmptyDataSet and Parse have played together just fine elsewhere in my app, so I'm not sure what's different specifically here.
wrong row count changement when you make cell animation such as insertion or deletion.
I'm aware that this is commonly the problem, but it's not in this case. The error does not occur if I stop using DZNEmptyDataSet, and I've carefully checked that the row counts are correct. It looks more like something funny going on with the method swizzling.
Method swizzling is so fragile. I Wish there was a better way of detecting reloadData.
Having this same issue in the same point within dzn_original_implementation, but it happens in UITableView endUpdates with this console message:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'request for rect of header in invalid section (1)'
It only seems to happen on iOS 8.2 or earlier (sim and device)--iOS 8.3 and up is fine. And it only happens after the app has been backgrounded and returns to a view where this tableView updating gets called. So it's likely just an iOS bug?
I'm getting this on ios 9.3 UITableView endUpdates when working with Realm fine-grained notifications.
The same thing. Had to remove beginUpdates/endUpdates from the project.
We had to remove DZNEmptyDataSet from our project because of this bug. This is why you don't method swizzle.
The crash you're seeing is likely nothing with the library, but the swizzled method hiding the true cause of the crash. If you set the tableView's emptyDataSource and emptyDelegate both to nil to disable using this library you should see what the true cause of the crash is.
The swizzling can hide the actual point in your code where the crash is occurring.
