フラグメントと個別のアクティビティを備えた2つのパネルUI

Question

基本的な2つのパネルレイアウト、左側に1つのパネルがメニューに、もう1つは各セクションの主要な機能を備えたハニカムアプリケーションを開始します。

フラグメントAPIの使用可能なサンプルとは反対に、右パネルに表示されるコンテンツは、各メニューオプションのまったく異なるUIで構成されています。

選択したセクションに従って正しいフラグメントを置き換えるだけで魅力的ですが、これはアプリ全体で1つのアクティビティを使用することを意味し、これは良く聞こえません。さらに、フラグメントのライフサイクルは活動に結び付けられているため、活動が殺されるまで断片は殺されず、多くの断片が「生きている」。

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

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

Answer 1

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

アクティビティグループを介した埋め込みアクティビティは素晴らしいアイデアでしたが、アクティビティは他のアクティビティと密接に対話するのではなく、独立した自己完結型コンポーネントになるように設計されているため、常に対処することは困難でした。フラグメントAPIはこれに対してはるかに優れたソリューションであり、組み込みアクティビティの代替品と見なす必要があります。

アクティビティインスタンス全体でデータを保持することは、Activity.onretainnonFigurationInstance（）を通じて達成できますが、これはかなりKlunkyで非自明です。フラグを設定するだけで、フラグメントインスタンス全体を保持できるようにすることにより、フラグメントはそのメカニズムに取って代わります。

DialogFragmentと呼ばれるフラグメントの専門化により、アクティビティライフサイクルの一部として管理されるダイアログを簡単に表示できます。これにより、アクティビティの「管理対象ダイアログ」APIが置き換えられます。

ListFragmentと呼ばれるフラグメントの別の専門化により、データのリストを簡単に表示できます。これは、既存のListActivity（さらにいくつかの機能を備えた）に似ていますが、他のデータで>リストを表示する方法に関する一般的な質問を減らす必要があります。

現在アクティビティに添付されているすべてのフラグメントに関する情報は、アクティビティの保存されたインスタンス状態のフレームワークによって保存され、再起動時に復元されます。これにより、自分自身を書くために必要なコードを保存および復元する状態の量を大幅に削減できます。

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

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

---

編集、説明: ：アプリに単一のアクティビティを使用すると、必ずしも悪い決定ではないと思います。アプリの機能に基づいて行うべき決定です。記事に基づいて、アクティビティは独立していますが、フラグメントは、通常、アクティビティの範囲内の他のフラグメントと組み合わせると関連性があります。さまざまなアクティビティの組み合わせで説明する状況は、解決するために断片を設計した問題点の1つです。