因?yàn)轫?xiàng)目是屬于效率工作類軟件，程序中大量界面都涉及到了實(shí)時(shí)的數(shù)據(jù)保存悉罕。昨天做任務(wù)標(biāo)題實(shí)時(shí)保存時(shí)處理的不大好笼平，這里記錄一下。
如圖 有三個(gè)數(shù)據(jù)處理項(xiàng)陨仅。一個(gè)是完成按鈕 一個(gè)是標(biāo)題 一個(gè)是任務(wù)下發(fā)成員津滞。除了標(biāo)題之外，其余兩個(gè)都很好做灼伤。比如完成按鈕 切換選中狀態(tài)的時(shí)候就可以發(fā)送網(wǎng)絡(luò)請求給服務(wù)器触徐，下發(fā)成員從成員控制器返回后可以發(fā)送請求給服務(wù)器。
對于標(biāo)題而言狐赡。如果做實(shí)時(shí)保存的話明顯不大可行撞鹉，總不可能標(biāo)題一變就發(fā)送請求。那你輸入的時(shí)候 是不是一直會(huì)發(fā)送網(wǎng)絡(luò)請求呢。所以我選擇了失焦保存去處理鸟雏。也就是說用戶在輸入的時(shí)候不做處理享郊，當(dāng)用戶輸入完了，UITextView失去焦點(diǎn)的時(shí)候發(fā)生請求給服務(wù)器保存數(shù)據(jù)孝鹊。但這會(huì)導(dǎo)致一個(gè)問題炊琉，如果用戶輸入完標(biāo)題后，立馬點(diǎn)擊左上角的返回保存按鈕又活，此時(shí)并不會(huì)立即觸發(fā)失焦事件苔咪，而是先觸發(fā)返回事件，這樣的話控制器銷毀了柳骄，對應(yīng)的失焦事件代碼也不會(huì)再執(zhí)行了团赏。
為了解決這個(gè)問題，我第一次處理的方法是加了一個(gè)變量耐薯，實(shí)時(shí)記錄標(biāo)題舔清。在返回的時(shí)候再保存一次。
這樣完全可以解決問題可柿。但是不好的點(diǎn)在于鸠踪，當(dāng)用戶輸入完標(biāo)題后并沒有立即點(diǎn)擊返回按鈕，而是操作了任務(wù)的其他功能項(xiàng)复斥，觸發(fā)失焦事件保存當(dāng)前標(biāo)題营密，這樣返回的時(shí)候會(huì)多一次保存。這種解決思路并不好目锭。
今天無意中看到筆記模塊自己之前寫的代碼评汰，發(fā)現(xiàn)這個(gè)問題只需要用一句代碼就可以完美解決：【self.view endEditing:YES】
這樣既可以避免重復(fù)保存的情況出現(xiàn)，又可以潔簡代碼痢虹。
后來我想了一下被去，這句代碼我一直在用。但是為什么出現(xiàn)問題的時(shí)候我并沒有第一時(shí)間想到這個(gè)奖唯。因?yàn)槲以谝婚_始想問題的時(shí)候方向就錯(cuò)了惨缆。
既然問題是因?yàn)橛脩糨斎胪陿?biāo)題后直接返回 會(huì)先觸發(fā)返回事件，從而導(dǎo)致失焦保存方法不執(zhí)行丰捷，我不應(yīng)該去想在返回事件里處理一下這種特殊情況坯墨。我應(yīng)該想的是避免這種特殊情況。這是很重要的一點(diǎn)病往，通俗來講捣染，就是遇到一種特殊情況，我們首先考慮的應(yīng)該是避免這種情況的發(fā)生而不是加一堆無意義的代碼去處理這種情況停巷。放在我的項(xiàng)目里來說耍攘，也就是在返回之前讓頁面的所有view結(jié)束編輯狀態(tài)榕栏，這樣就可以在返回之前觸發(fā)失焦事件，這才是問題最好的解決思路蕾各。
