*** -[AlwayedDownVC tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x17a971
2015-10-22 01:34
337 查看
这几天做的项目中需要用到tableView滑动删除这个功能,就很习惯的用tableView的两个数据源方法
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath{
return YES;
}
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath;
结果写完后,滑动删除掉一行之后点击导航栏的返回按钮居然出现了崩溃现象,而且崩溃是出现在跳回到之前的界面之后,我想着,不可能啊,之前也不是没有这样用过,之前都不出问题,怎么现在出问题了,并且崩溃之后也没有打印出相关的日志,也没有提示信息,直接到了 main 函数里,我想这样的崩溃大家是最头痛的,毫无头绪,虽然之后在偶然的情况下,我把上面的第一个方法给注释掉了,后来也就不崩溃了,问题得到了解决,今天,任务不算很重,我重新想想,越想越要把这个问题给彻底的搞明白,于是重新再回到这个demo里面,我心里想,一般直接跳到main函数里的并且不打印任何日志的崩溃应该和内存有关系(这只是一种直觉,我也不太确定),于是我就沿着这个不太明确的思路慢慢找问题,通过xcode自带的僵尸方法,这样一来就会有打印错误提示了,具体方法如下:
保存后,重新运行程序,再重复之前的操作,bug 出现了,右下角也有打印出日志了,问题如下:
[HistoryViewController tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x10930c140
也就是说,tableView:canEditRowAtIndexPath 这个方法有问题,那我就纳闷儿了,这个方法怎么可能会有问题,难怪我之前注释掉了这个方法就没问题了,果然是这里有问题,知道了问题针对它解决掉也就不会是什么难事儿了,我初步怀疑是 return YES 的问题,
于是,我在函数里加了这样几行代码
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.bgTableView setEditing:NO];
}
然后再重新运行,重复之前的操作,问题解决了,perfect,,,,
虽然问题解决了,但是还是觉得,canEditRowAtIndex 这个方法应该不会有问题,于是我再 ios 6 的模拟器下运行程序,重复操作没问题(当然注释掉viewWillDisappear 方法),后来到网上找了好多资料,很大神都说可能是苹果自身的问题,ios7 才有这个问题,ios6 以及以下不会出现这种问题,
至此,问题得到解决,以上列出了两种解决方案:1,删掉canEditRowAtIndexPath这个方法不用,不会出问题;
2,加上上面说的 viewWillDisappear 方法也可以解决问题;但是我个人推荐第二种方法,虽然第一种方法也是可以解决问题的,但是个人还是觉得这两个方法配套使用比较好。
最终总结出问题 可能是在 canEditRowAtIndexPath 这个方法里设置了YES然后返回的时候没有把它设置成 NO 所以报错,ios6会自动设置成NO,iOS7 就手动设置成 NO也可以。所以以后无论什么版本,我们都加上viewWillDisappear手动设置 editing 这个属性为NO 这样确保万无一失。
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath{
return YES;
}
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath;
结果写完后,滑动删除掉一行之后点击导航栏的返回按钮居然出现了崩溃现象,而且崩溃是出现在跳回到之前的界面之后,我想着,不可能啊,之前也不是没有这样用过,之前都不出问题,怎么现在出问题了,并且崩溃之后也没有打印出相关的日志,也没有提示信息,直接到了 main 函数里,我想这样的崩溃大家是最头痛的,毫无头绪,虽然之后在偶然的情况下,我把上面的第一个方法给注释掉了,后来也就不崩溃了,问题得到了解决,今天,任务不算很重,我重新想想,越想越要把这个问题给彻底的搞明白,于是重新再回到这个demo里面,我心里想,一般直接跳到main函数里的并且不打印任何日志的崩溃应该和内存有关系(这只是一种直觉,我也不太确定),于是我就沿着这个不太明确的思路慢慢找问题,通过xcode自带的僵尸方法,这样一来就会有打印错误提示了,具体方法如下:
保存后,重新运行程序,再重复之前的操作,bug 出现了,右下角也有打印出日志了,问题如下:
[HistoryViewController tableView:canEditRowAtIndexPath:]: message sent to deallocated instance 0x10930c140
也就是说,tableView:canEditRowAtIndexPath 这个方法有问题,那我就纳闷儿了,这个方法怎么可能会有问题,难怪我之前注释掉了这个方法就没问题了,果然是这里有问题,知道了问题针对它解决掉也就不会是什么难事儿了,我初步怀疑是 return YES 的问题,
于是,我在函数里加了这样几行代码
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.bgTableView setEditing:NO];
}
然后再重新运行,重复之前的操作,问题解决了,perfect,,,,
虽然问题解决了,但是还是觉得,canEditRowAtIndex 这个方法应该不会有问题,于是我再 ios 6 的模拟器下运行程序,重复操作没问题(当然注释掉viewWillDisappear 方法),后来到网上找了好多资料,很大神都说可能是苹果自身的问题,ios7 才有这个问题,ios6 以及以下不会出现这种问题,
至此,问题得到解决,以上列出了两种解决方案:1,删掉canEditRowAtIndexPath这个方法不用,不会出问题;
2,加上上面说的 viewWillDisappear 方法也可以解决问题;但是我个人推荐第二种方法,虽然第一种方法也是可以解决问题的,但是个人还是觉得这两个方法配套使用比较好。
最终总结出问题 可能是在 canEditRowAtIndexPath 这个方法里设置了YES然后返回的时候没有把它设置成 NO 所以报错,ios6会自动设置成NO,iOS7 就手动设置成 NO也可以。所以以后无论什么版本,我们都加上viewWillDisappear手动设置 editing 这个属性为NO 这样确保万无一失。
相关文章推荐
- 10010---SpringMVC ModelAttribute
- gson在android中的应用
- Happy Number - LeetCode
- 【Alpha】第二次Scrum meeting
- 第一次开通博客啊,哈哈 发一篇。
- 关于 微软必应词典客户端 的案例分析
- 解决 居中 问题
- WEB前端学习 Day 1(DIV+盒子模型+CSS文本+实例)
- jquery通过ajax-json访问java后台传递参数,通过request.getParameter获取不到参数的说明
- Leetcode Sqrt(x)
- HTML--内联元素与块级元素
- HTML--内联元素与块级元素
- 一姑娘让我们帮她参考一下联想的电脑好不好
- 关于 微软必应词典客户端 的案例分析
- IP、TCP和DNS与HTTP的密切关系
- 网络编程
- Excel实战之JXL解析
- Linux中Workqueue机制分析
- Daily Srum 10.21
- NetBIOS与Winsock编程接口