を使用して開発されていない本格的なアプリを持っていFragmentsます。私の混乱は、をFragmentsの代わりに持つように変更する必要があるということです Activities。私が伝えたいのは、アプリケーションでは縦向きのみを使用しており、タブレットではなく電話のみを念頭に置いて構築されているということです。だから私の質問は、私がアプリの全体の構造を変更して使用した場合、それは何か良いことをするでしょうかFragments？
私の知る限り、フラグメントは何かを再利用したい場合にのみ使用する必要があります。任意の提案をいただければ幸いです。
Fragments動的でマルチペインのユーザーインターフェイスを作成するために使用できるため、使用する画面領域がはるかに多いタブレットに最適です。もちろん、電話では状況が少し異なり、遊ぶスペースがはるかにActivity狭く、複数を含めることを心配せずに1つのフィッティングを画面に表示するだけで苦労する場合がありますFragments。
Fragments動的なインターフェイスや、タブレットと電話の互換性を支援するのに非常に適しています。また、アクティビティよりもはるかに優れたコミュニケーションが可能であるため、電話のみの設定でも使用することには確かに利点があります。（FragmentsManager使用できる機能については、を参照してください）
使用例の1つを下の図に示します（Android Developerサイトから取得）
Fragmentsこれは、タブレットでは同じ画面を占有し、電話ではよりアクティビティに似た形式に切り替えることができるの柔軟性を示しています。Fragmentに比べてそのような利点を与えるのは、この種の力ですActivity。
したがって、柔軟性の観点から指向性ソリューションに切り替えることには明らかに利点がありFragmentますが、元の質問では、電話のみを対象とし、縦向きのみを対象としていると述べています。
すでに存在しているアプリケーションがありActivities、それが満足のいくソリューションであり、使い勝手が良いという条件で、切り替える理由はなかったとFragments思います（チャレンジを探しているか、暇がない限り、ファンシーないじくり回し）。利点はありますが、フラグメントの追加などの大幅な変更により、アプリケーションにバグが発生し、ユーザーエクスペリエンスに影響を与える可能性があります（少なくとも短期的には）。
長期的には、タブレットのサポートを折り畳むことを検討している場合、または横向きを使用したい場合は、エクスペリエンスFragmentsを向上させるために何ができるかを検討し始め、これを現在のものと統合することをお勧めしますお使いの携帯電話アプリケーションのフロー。
そうでなければ、あなたが作成した現在のソリューションで十分であり、それがあなたの顧客ベースに好評である限り、私は変更する理由がないと思います。
もちろん、将来のプロジェクトのために、または現在のプロジェクトのUIを更新するときが来た場合でも、FragmentAPIに慣れても害はありません。
FragmentsAndroid 3.0（APIレベル11）からのみネイティブにサポートされていることを指摘する価値があります。以前のデバイスをサポートするには、インストールに含まれるAndroidサポートパッケージが必要になります。そのため、現在のアプリケーションが2.xデバイスを対象としている場合、ネイティブAPIレベル（Android 3.0以降など）に移行しない限り、シンプルさと.apkサイズのためにアクティビティベースのアプローチを使用します。これは個人的な好みですが、最終的には元の質問に対する答えは個人的な好みに要約されます。
フラグメントは、コードを管理可能な部分にモジュール化する方法と考えてください。各フラグメントは、機能とUIの小さな部分を表しています。これにより、さまざまなシナリオに合わせてコードを簡単に調整できます。
今すぐタブレットをサポートする予定はありません（タブレットユーザーがアプリをインストールする方法に関係なく）、より大きなサイズの5〜6インチのデバイスと、アプリをそれらに拡張する可能性について考えてください。できるだけ多くのデバイスにアプリをインストールすると、最高のアプリがデバイスに合わせてエクスペリエンスを調整します。
フラグメントへの移行は難しいことではありません。機能の小さな部分を取り、それをフラグメントに移動します。次に、新しいパターンがいかに簡単で柔軟であるかがわかります。アクティビティとフラグメントは連携できるため、アプリケーション全体を書き直す必要はありません。
フラグメントをスキップすることで、長期的には開発タスクが非常に難しくなると思います。
将来タブレットをサポートする予定がない場合は、そのままにしておきます。アプリをフラグメントに変換しても、何も得られません。
新しいアプリケーションを開始する場合は、状況が異なります。将来、他のフォームファクターをサポートする必要が生じた場合に備えて、より柔軟にするために、最初からフラグメントを使用します。この機能はサポートライブラリで利用できるため、古いデバイスでも使用できます。
アクティビティ間よりもフラグメント間の相互作用を設定する方が簡単です。
活動の場合：
startActivityForResult()/を使用する必要がありますonActivityResult();Parcelable、アクティビティ間で受け渡されるためにインターフェースを実装する必要があります。フラグメントの場合：
FragmentManagerデータの受け渡しは、フラグメントのインスタンスを取得してメソッドを呼び出すのと同じくらい簡単です。Parcelable;また、のインスタンスはのインスタンスFragmentよりも軽量でありActivity、初期化/再開にかかる時間とリソースが少なくて済みます。
一般に、フラグメントを使用すると、UIのコンポーネント間の相互作用がよりクリーンでエレガントになり、実装が容易になります。
アプリケーションまたはアプリケーションのいずれかに関する限り、フラグメントを使用することをお勧めします。フラグメントを使用しても、アプリケーションに害を及ぼすことはなく、タブレット用のアプリケーションをさらに拡張しながら、負担を軽減することもできます。アプリケーションのフラグメント。
フラグメントを使用するようにアプリケーションを変換し終えたところです。理由は次のとおりです。
これらは、フラグメントを使用する最も説得力のある理由です。
もう少し手間がかかるかもしれませんが、市場に出回っているタブレットの数が大幅に増え、採用率が高いので、より優れたUIでタブレットをサポートすることを検討する価値はありますか？
本当にこれを行いたくなく、高度なビューを使用してビューページングを行う必要がない場合は、フラグメントを使用するためにフラグメントを使用するようにプロジェクトを過剰に設計する必要はありません。あなたはそれらについて学ぶかもしれないと主張するかもしれませんが、あなたがあなたの次のプロジェクトでそれらを使うようになるとき、あなたはそれから学ぶことができます（それは私がしたことであり、それはうまくいきました）。