Android API 11以降で、Googleはと呼ばれる新しいクラスをリリースしましたFragment。
ビデオでは、Googleは可能な限り（link1、link2）、アクティビティの代わりにフラグメントを使用することを提案していますが、その理由は正確には説明されていません。
フラグメントの目的とそれらのいくつかの可能な使用法（単純なビュー/レイアウトで簡単に実現できるいくつかのUIの例を除く）は何ですか？
私の質問はフラグメントについてです：
ボーナスの質問：
＃1と＃2フラグメントを使用する目的は何ですか？アクティビティ/ビュー/レイアウトを使用する場合と比較してフラグメントを使用することの長所と短所は何ですか？
フラグメントは、再利用可能なユーザーインターフェースを作成するためのAndroidのソリューションです。アクティビティとレイアウトを使用して（たとえば、インクルードを使用して）同じことのいくつかを実現できます。でも; フラグメントは、HoneyComb以降のAndroidAPIに接続されています。詳しく説明させてください。
ActionBar。_ そこにあるタブでアプリをナビゲートしたい場合は、ActionBar.TabListenerインターフェースがメソッドFragmentTransactionへの入力引数としてを提供していることがすぐにわかりますonTabSelected。おそらくこれを無視して、何か他の賢いことをすることができますが、APIを使用するのではなく、APIに対して作業することになります。
FragmentManagerハンドルは非常に巧妙な方法であなたのために「戻る」。戻るとは、通常のアクティビティのように、最後のアクティビティに戻ることを意味するものではありません。これは、前のフラグメント状態に戻ることを意味します。
クールViewPagerを使用して、FragmentPagerAdapterスワイプインターフェイスを作成できます。コードは通常のFragmentPagerAdapterアダプターよりもはるかにクリーンであり、個々のフラグメントのインスタンス化を制御します。
携帯電話とタブレットの両方のアプリケーションを作成しようとするときにフラグメントを使用すると、生活がはるかに楽になります。フラグメントはHoneycomb+APIと非常に密接に関連しているため、コードを再利用するために電話でも使用する必要があります。そこで、互換性ライブラリが役に立ちます。
電話専用のアプリにはフラグメントを使用することもできますし、使用する必要があります。移植性を念頭に置いている場合。と互換性ライブラリを使用ActionBarSherlockして、バージョン1.6までずっと同じように見える「ICSルック」アプリを作成します。ActionBarタブ、オーバーフロー、分割アクションバー、ビューページャーなどの最新機能を利用できます。
ボーナス2
フラグメント間で通信するための最良の方法はインテントです。フラグメント内の何かを押すと、通常StartActivity()、そのデータを使用して呼び出します。インテントは、起動するアクティビティのすべてのフラグメントに渡されます。
どのビデオについて言及しているのかはわかりませんが、アクティビティの代わりにフラグメントを使用する必要があると言っているとは思えません。なぜなら、それらは直接交換可能ではないからです。実際には、開発者ガイドにかなり詳細なエントリがあります。詳細については、それを読むことを検討してください。
つまり、フラグメントはアクティビティ内に存在し、各アクティビティは多くのフラグメントをホストできます。アクティビティと同様に特定のライフサイクルがあり、アクティビティとは異なり、最上位のアプリケーション コンポーネントではありません。フラグメントの利点には、コードの再利用とモジュール性 (多くのアクティビティで同じリスト ビューを使用するなど) が含まれます。これには、マルチペイン インターフェイスを構築する機能 (主にタブレットで役立ちます) が含まれます。主な欠点は、(いくらか) 複雑さが増すことです。通常、非標準で堅牢性の低い方法で (カスタム) ビューを使用して同じことを実現できます。
Fragment は、よりモジュール化されたアクティビティ設計を可能にするアクティビティに配置できる、アプリケーションのユーザー インターフェイスまたは動作の一部です。フラグメントは一種のサブアクティビティであると言っても過言ではありません。
以下は、フラグメントに関する重要なポイントです。
フラグメントには、独自のレイアウトと独自の動作があり、独自のライフサイクル コールバックがあります。
アクティビティの実行中に、アクティビティのフラグメントを追加または削除できます。
複数のフラグメントを 1 つのアクティビティに結合して、マルチペイン UI を構築できます。
フラグメントは、複数のアクティビティで使用できます。
フラグメントのライフサイクルは、そのホスト アクティビティのライフサイクルと密接に関連しています。
アクティビティが一時停止すると、アクティビティで使用可能なすべてのフラグメントも停止します。
フラグメントは、ユーザー インターフェイス コンポーネントを持たない動作を実装できます。
フラグメントは、API バージョン 11 でAndroid 3 (Honeycomb)の Android API に追加されました。
詳しくはFragments公式サイトをご覧ください。
これは、フラグメントで見つけた重要な情報です。
歴史的に、Android アプリの各画面は個別のアクティビティとして実装されていました。Android のインテント メカニズムではアクティビティ間で直接参照型 (つまりオブジェクト) を渡すことができないため、画面間で情報を渡す際に問題が生じます。代わりに、オブジェクトをシリアル化するか、グローバルにアクセス可能な参照を使用可能にする必要があります。
各画面を個別の Fragment にすることで、このデータ受け渡しの問題は完全に回避されます。フラグメントは、特定のアクティビティのコンテキスト内に常に存在し、常にそのアクティビティにアクセスできます。関心のある情報をアクティビティ内に格納することにより、各画面のフラグメントは、アクティビティを介してオブジェクト参照に簡単にアクセスできます。
ソース: https://www.pluralsight.com/blog/software-development/android-fragments
フラグメントは、すべてのページにナビゲーション ドロワーを保持したい場合などに特に役立ちます。必要なフラグメントを使用してフレーム レイアウトを膨張させても、ナビゲーション ドロワーにアクセスできます。
アクティビティを使用した場合、すべてのアクティビティでドロワーを保持する必要があり、コードが冗長になります。これは、フラグメントの興味深い使用法の 1 つです。
私は Android を初めて使用しますが、フラグメントがこのように役立つと考えています。
私はこれがすでに死ぬほど議論されていることを知っていますが、さらにいくつかのポイントを追加したいと思います:
Frags を使用して を設定し、独自にクリックをMenu処理できます。MenuItemしたがって、アクティビティにさらに変調オプションを提供します。アクティビティが認識しなくても ContextualActionBar などを実行でき、基本的に、アクティビティが処理する基本的なもの (ナビゲーション/設定/情報) から切り離すことができます。
子 Frags を持つ親 Frag を使用すると、コンポーネントをモジュール化するための追加オプションを利用できます。たとえば、Frag を簡単に交換したり、Pager 内に新しい Frag を配置したり、Frag を削除したり、再配置したりできます。アクティビティがそれについて何も知らずに、より高いレベルのものに焦点を当てるだけです。
フラグメントはアクティビティ内に存在しますが、アクティビティは単独で存在します。
以前にフロントエンドを書いたことがある場合は、(React、Vue、または Angular) などのフロントエンド コンポーネントを使用します。アクティビティ内の再利用可能なコンポーネントのようなフラグメントについて考えてみてください。