iOS Interface Builderのアーキテクチャーアプローチ

Question

このデザインモックアップをtableviewとして、カスタムセルタイプの側面に埋め込まれたセクショングループでコード化するか、スクロールビューにグループを入れて各セクションにUIViewを構築させますか？

これは意見に基づく質問でも「一般向け」でもありません。これはiOS開発の設計上の問題です。

Interface-Builderでは、私は以下のイメージのような7つの画面を持っています。スクロールにテーブルビューを使用し、グループ化されたセクションを使用すると、スクロールできないセクションは、より良い単語がないため静的にする必要があります。それも可能ですか？

セクションヘッダーは、私が望むものではない過去のページをスクロールするまで、一番上に表示されます。

スクロールビューに静的なスクロール不可能なテーブルを置くことはできません。スクロールビューは逆順であるためです。また、この方法では、各セクションに異なるサイズのヘッダーがあり、各セクションに異なるセルタイプがあります。これを行うにはむしろタッキー/ハッキーに見えます。

私は、この外観を持つ7つの画面があるので、たくさんの建物thatsのUIViewビルドアプローチを使用します。

ネイティブiOS開発アプローチに基づくより良い決定は何ですか？各画面に多数のカスタムTableViewを使用するか、またはサブビュー付きのUIViewを使用する方が良いでしょうか？両方のアプローチには、私の経験では珍しい、私にとって大きなトレードオフがあります。私は後に行くより良いアプローチを見ていますか？

Answer 1

テーブルを使用しての問題は、あなたが根本的に異なる表情をするとき、あなたは多くの場合、自分がそれと戦っ見つけることです。ある時点では、パブリックAPIを無効にし、セルまたはテーブルビューの基になるビューを操作して操作するコードを作成しようとするかもしれません。

これは「許容」で、「プライベートAPI」とはみなされませんが、将来のiOSバージョンではこの動作が破られることがあります。

私はテーブルの振る舞いから離れた何かをしたいとき、私はテーブルを使用しません。

あなたの場合、セクションを使用してヘッダーを別のセルタイプにすることはできません。おそらくそれほど悪くはありません。残りのあなたのモックアップは、テーブルとして実装可能なように見えます。