Androidアプリでは、ユーザーに表示される2つの画面*があります。1つはクエリの準備用で、もう1つは結果の表示用です。ここでの適切なUIは、1つの画面でクエリの準備を行い、2番目の画面で結果を確認することです。このアプリは電話ユーザーを対象としているため、2つを同時に表示する必要はありません。
従来のAndroidの方法は、aQueryPreparationActivityとaの2つのアクティビティを使用しDisplayResultActivity、2つを切り替えることです。ただし、AndroidUIがフラグメントに切り替わる方法についてはますます耳にします。2つの画面を2つのフラグメントとして実装し、アクティビティでそれらを切り替えることはできますが、問題を起こす価値はありますか？基本的に、Androidにすでにあるアクティビティ管理コードを再現します。
ここで2つのフラグメントを使用する理由はありますか？
*screen必ずしもアクティビティではないため、この用語を使用しています...
個人的には、常にフラグメントを使用して開発しています。
しかし、フラグメントを使用するために私があなたに与えることができる最も良い理由は、あなたが受話器とタブレットデバイスのために開発するとき、あなたが多くの再利用性を得るということです。
両方の画面を同時に表示する必要はないとおっしゃっていましたね。しかし、後でタブレットデバイス用に同じ「画面」を開発し、準備画面が不毛で、queryprepと表示結果の両方を同時に表示したい場合は、まったく新しい3番目のアクティビティを作成する必要があります。 。
フラグメントを使用した場合は、1つのアクティビティと2つのフラグメントを再利用します。そのアクティビティは、画面のサイズを決定し、適切なレイアウトを表示するのに十分スマートにコーディングする必要があります。
コードの再利用性と柔軟性は、ここで流行語です。
ご不明な点がございましたら、コメントを残していただければ、回答を拡大させていただきます。私の答えが気に入ったら、賛成して受け入れてください。
フラグメントは、UI 要素と関連する動作を単一の再利用可能なモジュールにカプセル化するために導入されました。フラグメントの前に、2 つ以上のアクティビティに共通する同じコードの多くを書き直す必要がありました。特に、UI/コントロール コードをスーパー クラスに抽象化するための適切なアプローチが見つからなかった場合はそうです。これは、アクティビティが 1 回しか呼び出さないという制限によってさらに複雑になりましたsetContentView。そのため、アクティビティ間でコードを共有することは、それほど良いことではありませんでした。
さて、あなたの質問に答えるために、それはすべてあなた次第です. 今後、QueryPreparation または DisplayResult ui をモジュール (レイアウトとその背後にあるロジック) として使用できると思われる場合は、フラグメントの実装に進みます。携帯電話の横向きビューや、Nexus 7 のような小型のタブレットをサポートする場合は、別のレイアウトになる可能性があります。それが絶対に起こらないと確信している場合は、アクティビティに固執してください。個人的には、どこでもフラグメントを使用しており、今後の再利用のために実装を「将来保証」するための確実な方法です。
つまり、フラグメントはタブレット/大画面デバイスの出現に対応するために導入され、開発者はコードをほとんど変更せずに幅広い画面サイズで実行されるアプリケーションを作成できるようになりました。
詳細については、こちらの Android ブログ をご覧ください。このブログでは、Fragments への移行の理由について、より細かい技術的な詳細についても説明しています。また、Goolge IO 2012 で導入された DialogFragments は、Dialogs の代わりに使用することを検討する必要があります。こちらの別のブログ記事でそれらについて説明しています。
Fragments と DialogFragments を最初から使用することに慣れたほうがよいでしょう。これが Android の動きです。個々のアクティビティを使用するのは、テストなどの目的で簡単なアプリを本当に実行する必要がある場合のみです。私の意見では、フラグメントを組み込んで最初に理解するには、もう少しコード作業が必要ですが、努力する価値はあります。