現在、リソース ファイルでさまざまなフラグメントを定義し、それらを含むアクティビティの onCreate メソッドに非表示にしていますが、これは各フラグメントが独自に定義する特性の 1 つになると予想されるため、このアプローチには満足していません。 .
Fragments を客観視しすぎているのか、それともテクニックを見逃しているのか?
ありがとう、R
現在、リソース ファイルでさまざまなフラグメントを定義し、それらを含むアクティビティの onCreate メソッドに非表示にしていますが、これは各フラグメントが独自に定義する特性の 1 つになると予想されるため、このアプローチには満足していません。 .
Fragments を客観視しすぎているのか、それともテクニックを見逃しているのか?
ありがとう、R
これは、各フラグメントが独自に定義する特性の 1 つになると予想されるため、このアプローチには満足していません。
私はその評価に同意しません。
フラグメントは、画面の小さなセクションと、画面のその小さなセクション内に純粋に含まれるすべてのイベントを担当します。
フラグメントがアクティビティ A、アクティビティ B、またはアクティビティ C のいずれにホストされているか、他のフラグメントと並んでいるかどうか、現在表示されているかどうかなどは、フラグメントの責任ではありません。その責任はホスティング アクティビティ (フラグメントが再利用される場合はアクティビティ) にあります。ホスティング アクティビティは、画面サイズと、特定のフラグメントを画面にロードするために何をすべきかを認識しています。
結局のところ、ルールは変更される可能性があります。おそらく、フラグメントは小さい/通常の画面では隠されていますが、大きい/特大の画面では表示されます。または、最初はフラグメントが個別に使用されていたが、後で にロードされた可能性がありViewPager
ます。または、おそらくフラグメントは の一部として動的に作成されFragmentTransaction
、BACK スタックに追加されるため、ユーザーは個別にフラグメントを取り除くことができます。IMHO、フラグメントは、その 1 つの個々のフラグメントの境界をすべて超えているため、このようなことを認識したり、気にしたりする必要はありません。