一次UITextView失焦保存所引发的思考

因为项目是属于效率工作类软件,程序中大量界面都涉及到了实时的数据保存。昨天做任务标题实时保存时处理的不大好,这里记录一下。

一次UITextView失焦保存所引发的思考_第1张图片
Snip20170823_17.png

如图 有三个数据处理项。一个是完成按钮 一个是标题 一个是任务下发成员。除了标题之外,其余两个都很好做。比如完成按钮 切换选中状态的时候就可以发送网络请求给服务器,下发成员从成员控制器返回后可以发送请求给服务器。

对于标题而言。如果做实时保存的话明显不大可行,总不可能标题一变就发送请求。那你输入的时候 是不是一直会发送网络请求呢。所以我选择了失焦保存去处理。也就是说用户在输入的时候不做处理,当用户输入完了,UITextView失去焦点的时候发生请求给服务器保存数据。但这会导致一个问题,如果用户输入完标题后,立马点击左上角的返回保存按钮,此时并不会立即触发失焦事件,而是先触发返回事件,这样的话控制器销毁了,对应的失焦事件代码也不会再执行了。

为了解决这个问题,我第一次处理的方法是加了一个变量,实时记录标题。在返回的时候再保存一次。

一次UITextView失焦保存所引发的思考_第2张图片
Snip20170823_21.png
一次UITextView失焦保存所引发的思考_第3张图片
Snip20170823_20.png

这样完全可以解决问题。但是不好的点在于,当用户输入完标题后并没有立即点击返回按钮,而是操作了任务的其他功能项,触发失焦事件保存当前标题,这样返回的时候会多一次保存。这种解决思路并不好。

今天无意中看到笔记模块自己之前写的代码,发现这个问题只需要用一句代码就可以完美解决:【self.view endEditing:YES】

一次UITextView失焦保存所引发的思考_第4张图片
Snip20170823_22.png

这样既可以避免重复保存的情况出现,又可以洁简代码。

后来我想了一下,这句代码我一直在用。但是为什么出现问题的时候我并没有第一时间想到这个。因为我在一开始想问题的时候方向就错了。

既然问题是因为用户输入完标题后直接返回 会先触发返回事件,从而导致失焦保存方法不执行,我不应该去想在返回事件里处理一下这种特殊情况。我应该想的是避免这种特殊情况。这是很重要的一点,通俗来讲,就是遇到一种特殊情况,我们首先考虑的应该是避免这种情况的发生而不是加一堆无意义的代码去处理这种情况。放在我的项目里来说,也就是在返回之前让页面的所有view结束编辑状态,这样就可以在返回之前触发失焦事件,这才是问题最好的解决思路。

你可能感兴趣的:(一次UITextView失焦保存所引发的思考)