- Aの下にB、というような相対的な配置ではなく絶対座標による指定。ViewOnlyでレイアウトを組むことができず、indexPathを設定するためのロジックが必須になる
- ↑データ群からindexPathを一意に変換する(場合によっては双方向も)必要があり、ここがFatになりやすい
- StaticTableViewは避けれるが、IBがFatになりやすい。Storyboardのみ。
- 安全なアクセスは生成時に限定されている、ReuseもあるのでデータをCellで保持することが出来ない。もっともMVVMだとVMにデータを保持するので元からそういう作りであれば問題にはならないか。ただしFatVMになりやすいと感じている。
- CellのイベントハンドラをVCに作るときにindexPathを取り出して…など結構煩雑になりがち。
- tableViewCellForIndexPathがFatになりやすい。
- StaticTableViewは避けれるが
- 高さがCellの外にある。Self-sizingで楽にはなったが、変更するとなるとTableViewとの連携が必須。普通のViewのようにはいかない。
- CellのReloadがベストプラクティス。しかしKeyboardとかアニメーションとかその他諸々止事無き事情で我々はCellの高さを変更しなければならなくなるだろう。
- TableHeaderView/TableFooterView 高さ変更が…
- Keyboardとカーソル, Cellの増減にまつわるScrollがハンドリング不可能。
- DataSourceと他のロジックが結合しやすく、気がついたら手遅れになっている。indexPathを前提にロジックを組むともはや切り離せない構造になる。
- ContentViewの上にIBがベタ置きされていてレイアウトを組み直しになる。(XML直書きすれば簡単にViewに戻せたりするケド)
- なんでheaderとfooterのString版はdelegateにおるんや、おまえらdataSourceやろ！
- MultiSelectの扱いやすいEditingModeが隠されててずるい
- 右スワイプも隠れてそう、ずるい