本文的內容是對這篇文章的閱讀總結
原文連結:A Case For Using Storyboards on iOS
顯然王巍的這篇文章裡的實踐經驗比本文原作者的觀點更加值得認可:再看關於 Storyboard 的一些爭論
很多開發者對於在專案中Storyboard是嚴格禁止的。SB容易引發衝突,檔案的可讀性差,載入速度可能更慢都是開發者常常提到的缺點。然而我認為這些是在一些ie使用場景下是可以避免的,SB在專案中依然有適用的地方。
使用SB的好處
直觀!
- 可以直接看到介面的視覺效果
- 新增AutoLayout時更加符合直覺
在SB中的操作可以馬上展示到眼前。使用體驗很好,也提高了效率。
如何正確的使用
一個SB中只有一個VC!
這樣就減少了衝突的可能,兩個開發者同時修改一個VC的概率很低,就算衝突了也只是一個VC較容易解決。
這種方式也為更便捷的從SB中初始化VC提供了一種方式。直接根據類名載入SB中的 initial view controller 就可以了。不需要給每個VC指定識別符號。
有很多特性(static TableView)只能在SB中使用,在xib中不支援,都使用了SB後,這些特性也可以在SB中自如的使用。
不要使用segue
segue的跳轉非常不靈活,如果都在prepare中處理資料也非常死板。所以不要使用segue跳轉。
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
usernameToSend = usernames[indexPath.row]
performSegue(withIdentifier: SegueIdentifier.showUserDetails, sender: nil)
}
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
///
}複製程式碼
控制元件的屬性在程式碼中設定
比如 font 或者 color ,如果直接在 SB 中只能設定一個固定的值,建議還是通過程式碼使用常量設定,可以方便的控制全域性的控制元件的樣式。
如果要通過一些關鍵字查詢屬性設定,在程式碼中也比在SB中更容易被查詢到。
技術是死的,人是活的
不要因為某個技術有一些缺點就一棍子打死。並不是有缺點就要全盤放棄。不要給自己這種限制,在合適的場景你依然應該考慮使用這項技術。
原文:
My point is to not disregard a whole technology because you don’t like one aspect of it. You are free to pick and choose which parts you want to use. It’s not all or nothing.
歡迎關注我的微博:@沒故事的卓同學