7

基本的な 2 つのパネル レイアウトを持つ Honeycomb アプリケーションを開始しています。左側に 1 つのパネルがメニュー用に、右側に 1 つのパネルが各セクションの主な機能用です。

Fragments API の利用可能なサンプルとは対照的に、右側のパネルに表示されるコンテンツは、メニュー オプションごとにまったく異なる UI で構成されています。

選択したセクションに応じて適切なフラグメントを置き換えたいと思うかもしれませんが、これはアプリ全体で 1 つのアクティビティのみを使用することを意味し、あまり良くありません。さらに、フラグメントのライフサイクルはアクティビティに関連付けられているため、アクティビティが強制終了されるまでフラグメントは強制終了されず、多くのフラグメントが「生きている」ことになります。

ただし、メニュー オプションごとに 2 つのパネルを持つ異なるアクティビティがあるということは、メニューに使用されるフラグメントをすべてのアクティビティに追加する必要があり、メニューを持つ必要があるすべてのセクションで一貫性のないレイアウトになることを意味します。

ここでのベストプラクティスは何ですか?

4

1 に答える 1

6

このブログ投稿では、アクティビティよりもフラグメントを選択する理由をまとめています。

ActivityGroup による埋め込みアクティビティは良いアイデアでしたが、アクティビティは他のアクティビティと密接に相互作用するのではなく、独立した自己完結型のコンポーネントとして設計されているため、常に扱いが困難でした。Fragment API は、これに対するより優れたソリューションであり、組み込みアクティビティの代替と見なす必要があります。

Activity インスタンス間でデータを保持するには、Activity.onRetainNonConfigurationInstance() を使用できますが、これはかなり面倒でわかりにくいものです。Fragment は、フラグを設定するだけで Fragment インスタンス全体を保持できるようにすることで、そのメカニズムを置き換えます。

DialogFragment と呼ばれる Fragment の特殊化により、Activity ライフサイクルの一部として管理される Dialog を簡単に表示できます。これは、Activity の「マネージ ダイアログ」API を置き換えます。

ListFragment と呼ばれる Fragment の別の特殊化により、データのリストを簡単に表示できます。これは既存の ListActivity に似ていますが (いくつかの機能が追加されています)、a> リストを他のデータとともに表示する方法についてよくある質問を減らす必要があります。

アクティビティに現在アタッチされているすべてのフラグメントに関する情報は、フレームワークによってアクティビティの保存済みインスタンス状態に保存され、再起動時に復元されます。これにより、自分で記述する必要がある状態の保存と復元のコードの量を大幅に減らすことができます。

このフレームワークには、Fragment オブジェクトのバックスタックを管理するためのサポートが組み込まれているため、既存のアクティビティ バック スタックを統合するアクティビティ内の [戻る] ボタンの動作を簡単に提供できます。この状態も自動的に保存および復元されます。

フラグメントはかなり新しいので、その記事を超えて、ベスト プラクティスの多くが見つかるかどうかはわかりません。あなたが下す必要がある決定は、私の相互作用が密に結合され、データを共有することを意図しているのか、それとも相互作用があまりないスタンドアロンのコンポーネントであるかということだと思います。


編集、明確化:アプリに単一のアクティビティを使用することは、必ずしも悪い決定ではないと思います。実際には、アプリの機能に基づいて決定する必要があります。記事に基づいて、アクティビティはスタンドアロンですが、フラグメントは通常、アクティビティの範囲内の他のフラグメントと組み合わされた場合にのみ関連します。さまざまなアクティビティを組み合わせた、あなたが説明する状況は、Fragments が解決するように設計した問題点の 1 つです。

于 2011-03-16T17:17:15.540 に答える