なぜ「UITableViewControllerを使わずにUIViewControllerにUITableViewを乗せましょう」言われるのか。
理由はいくつか考えられます。
- レイアウト変更に弱い
- 自動処理がカスタマイズの邪魔になる場合がある
これらを説明していきます。
1. レイアウト変更に弱い
今ではUICollectionLayoutListConfigurationなど最新のAPIが存在して、「UICollectionViewで動的なレイアウトを組んでいきましょう」という流れがありますが、以前は表現したいものに応じてTableView or CollectionViewの使い分けでした。
その際に、最初はTableViewを使って画面を組んでいたとしても、アプリのアップデートに応じて「テーブルの上にグラフを表示したい」などのレイアウト要件が発生するかもしれません。
そのような時にUITableViewControllerでは対応が難しいです。なぜなら、ViewControllerの上にTableViewが張り付いていて、Storyboardの上からプログラマがtableViewの制約を変更したり新しいUI要素を付け加える事ができないからです。(Containerパターンを利用すれば一応対応は可能ですが、少し複雑になってしまいます)
このように、実際のプロジェクトで「後々レイアウトの対応が大変になる」という経験をしたプログラマの人たちは、「UITableViewControllerを使うな」と言います。
2. 自動処理がカスタマイズの邪魔になる場合がある
UITableViewControllerは、UIViewControllerのサブクラスであり、自身にUITableViewDataSourceとUITableViewDelegateを適応させています。
そして、その恩恵として以下のような自動処理が適応されています。
- キーボード上げ下げ時のcontentInset調整を自動対応
- ViewControllerのsetEditingを自動でTableViewに伝搬
- UITableViewCellの「swipe to delete」modeをViewControllerに伝搬
- viewWillAppear()で自動でデータをリロード、セレクションのクリア
- viewDidAppear()で自動でUIScrollViewのindicatorをflash
などなど。
基本的なPros/Consとしては以下になると思います。
Pros
「あまりTableにカスタマイズを多く施さない場合は自動化の恩恵を十分に受けられ、Appleのチームによって良く考えられた工夫をタダで得られてお得」
Cons
「UITableViewをかなりカスタマイズして独自の処理を頑張りたい時には、自動で処理を伝搬されるのが、むしろ邪魔になる」
このようにPros/Consが裏表の関係になっていますが、「作り始めは良かったけど、カスマイズの要件が膨らんでいくごとに自動処理へのoverride対応が大変になってしまい、むしろUITableView with UIViewControllerで作るよりコード量が増えてしまった」のような経験をしたプログラマの人たちは「UITableViewControllerを使うな」と言います。
まとめ
以上のように、非常に便利な反面、要件への柔軟な対応という観点では幾らか問題もあり、変化し続けるビジネスの要求により耐えやすい「UITableView with UIViewController」の構成が好まれるようになった。という話でした。
みなさんはどのような状況で「UITableViewControllerを使ってはダメだ」と思われたでしょうか？よければコメントで教えてください。