- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath{
}
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingSt
结果写完后,滑动删除掉一行之后点击导航栏的返回按钮居然出现了崩溃现象,而且崩溃是出现在跳回到之前的界面之后,我想着,不可能啊,之前也不是没有这样用过,之前都不出问题,怎么现在出问题了,并且崩溃之后也没有打印出相关的日志,也没有提示信息,直接到了 main 函数里,我想这样的崩溃大家是最头痛的,毫无头绪,虽然之后在偶然的情况下,我把上面的第一个方法给注释掉了,后来也就不崩溃了,问题得到了解决,今天,任务不算很重,我重新想想,越想越要把这个问题给彻底的搞明白,于是重新再回到这个demo里面,我心里想,一般直接跳到main函数里的并且不打印任何日志的崩溃应该和内存有关系(这只是一种直觉,我也不太确定),于是我就沿着这个不太明确的思路慢慢找问题,通过xcode自带的僵尸方法,这样一来就会有打印错误提示了,具体方法如下:
保存后,重新运行程序,再重复之前的操作,bug 出现了,右下角也有打印出日志了,问题如下:
[HistoryViewController tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x10930c140
也就是说,tableView:canEditRowAtIndexPath
于是,我在函数里加了这样几行代码
- (void)viewWillDisappear:(BOOL)animated {
}
然后再重新运行,重复之前的操作,问题解决了,perfect,,,,
虽然问题解决了,但是还是觉得,canEditRowAtIndex 这个方法应该不会有问题,于是我再 ios 6 的模拟器下运行程序,重复操作没问题(当然注释掉viewWillDisappear
至此,问题得到解决,以上列出了两种解决方案:1,删掉canEditRowAtIndexPath这个方法不用,不会出问题;
2,加上上面说的 viewWillDisappear 方法也可以解决问题;但是我个人推荐第二种方法,虽然第一种方法也是可以解决问题的,但是个人还是觉得这两个方法配套使用比较好。
最终总结出问题 可能是在 canEditRowAtIndexPath 这个方法里设置了YES然后返回的时候没有把它设置成 NO 所以报错,ios6会自动设置成NO,iOS7 就手动设置成 NO也可以。所以以后无论什么版本,我们都加上viewWillDisappear手动设置 editing 这个属性为NO 这样确保万无一失。