關於iOS多個tableView的設計?
一個界面有4個tableView,或者更多.
tableView的DataSource,Delegate,交給誰去處理?如何處理數據傳輸與用戶交互.~~小彩筆~~
我始終認為一個界面出現多個 table 是非常糟糕的設計。
你要看清楚到底是非要多個 table 不可，還是多個 section 配不同的 cell 就可以搞定。
真的非要多個 table 不可就按照第一個答案的方法。
在 MVC 裡面，為了避免 VC 臃腫，我習慣不把 dataSource 直接掛在 VC 上。而是用一個專門的對象來代理 dataSource，他與 VC 同生命周期，如果 cell 上面的事件比較複雜，可能會引入額外的 callback，不過相比讓 VC 爆炸，這很值得。
或者用 ReactiveCocoa 去做 MVVM。Childviewcontroller
看MVVM的邏輯。
一個界面(viewController)4個tableView很大可能就是設計有問題，應該多從設計方面考慮。
分享一下Container View的好處，有時候PageViewController好多了。
storyboard特別友好的顯示了VC之間的關係
一個界面多個Table其實是非常常見的設計，這個得需要自己對著設計實現的理解
簡單的，直接用tableviewController分開管理table的數據，然後通過addchildviewcontoller加到主要的controller中，複雜點的界面，tableviewController無法解決的，那就直接用viewController再內嵌tableView就行了。這樣做做的話，可以更好的區分每個vc的作用，以後對其做單獨的修改更新的時候也會顯得特別的簡單明了；
還有，如果覺得數據通用可以分類統一管理的，可以把dataSource甚至delegate都用單獨的類實現代理多個table，這樣就可以讓代碼更加簡潔了ReactiveCocoa吧。
MVC massive，被吐槽的太多了。
剛好上星期的需求做過類似的東西……第一個版本是用了最土的方法，1個tableView，用1個index來控制4個介面4套數據4個緩存……每個tableViewDelegate和datasource都要switch case……後來換了個方案，用pageViewController來管理4個Controller…看起來就好很多了……樓上說的用section管理這個思路也很贊……
推薦閱讀：
