70

Activitiesまたはを使用するかどうかについては、多くの議論がありますFragments。例えば：

私が見つけた議論のほとんどは、Android 4.2 より前にリリースされたものです。
Android 4.2 では、Google がネストされた Fragmentsを発明しました。

したがって、実際には、複数を使用する理由はもうありませんActivity。

初期の段階では、タブレットとスマートフォンを同時に快適Fragmentsにサポートするためのアプリ内で使用されることになっていました。

したがって、たとえば、アイテムをクリックListViewすると詳細を開くことができる があります。Viewスマートフォンでは、 を置き換えて、代わりListViewに詳細を表示しViewます。リストを詳細ビューに置き換える代わりに、タブレットViewsは両方を同時に表示できます。

ネストされた現在Fragments、他にも多くの可能性があります。単一Activityの を使用する場合は、一般的な情報を に保存するActivityと、すべてのFragment人がアクセスできます。

これに加えて、Fragments入れ子Fragmentsになっている人は、子供の情報を保存することもできFragmentsます。

をFragments簡単に再利用できるので、同時にViews複数を表示でき、 から簡単にダイアログを作成できます。これはおそらく、いくつかのコピーと貼り付けのアクション以上のものではありません。FragmentFragment

代わりに使用する場合Activities、これを行うには多くの変更を真剣に行う必要があります。

私は最近、2つを簡単に使用して本当に美しく動的なものを取得できるアプリケーションFragment-ViewPagerを実装しました（ある種：今日の情報 - 昨日の情報）。私の意見Fragmentsでは、私たちの生活をより簡単にします:)

質問:

  • なぜ複数使用する必要があるのActivityですか?

Activitiesを使用する代わりに、複数を使用する方が理にかなっている良い例を教えてくださいFragments。

  • を使わざるを得ない良い例はありますActivitiesか？

MapsやYouTubeなどのより大きなフレームワークのほとんどは、すでに をサポートしていると思いますFragments。したがって、に依存する必要はありませんActivities。NavigationBarまた、TabHosts、ViewPager、ActionBarを使用する場合の対処は非常に簡単ですかFragments。

Udacity より:

多くのフラグメントを含む 1 つのアクティビティを常に作成しないのはなぜですか?

  1. 複雑さの増大
  2. よりハードなインテント処理
  3. 読み取り、保守、およびテストが困難
  4. 密結合のリスク
  5. セキュリティ上の懸念
4

5 に答える 5

96

まず、1 つのアクティビティとネストされたフラグメントのみを使用して巨大なアプリケーションを作成できることに同意します。それがソフトウェアの面白さです。さまざまなアプローチを使用して同じ機能を実現できます。私にとって、複数のアクティビティを使用するという選択は、カプセル化、再利用可能性、およびテスト可能性に対する私の個人的な好みに帰着します。

他のアプリケーションで再利用できるウィジェットがある場合は、それを Fragment にします。たとえば、私のアプリには「サーバーと同期」ボタンがあり、プログレス バーを使用して同期プロセスを視覚的に表示するカスタム フラグメントを作成しました。別のアプリケーションでこのウィジェットを使用できることは容易に想像できるので、Fragment として開発しました。

新しいタスクが前のタスクから概念的に独立しているように、アプリ内でタスクを切り替える場合は、新しいアクティビティを使用します。たとえば、私のアプリの最初のページでは、ユーザーを選択するよう求められます。ユーザーをクリックすると、そのユーザーのメイン メニューに移動します。ユーザー用のこのメイン メニューは、新しいアクティビティに表示されます。

ここで、大規模で複雑なアプリと、そのアプリの開発に割り当てられた開発者チームを想像してみましょう。アプリを個別のアクティビティに分割できる場合、タスクを分割することは概念的に非常に簡単です。各アクティビティは独自のサンドボックスであるため、並行開発はシンプルで単体テスト可能です。共通のニーズがある場合でも、チームはフラグメントを開発して再利用する必要があります。ソフトウェア開発ではコードの再利用が十分に行われるわけではありませんが、正しく行われれば、再利用可能なフラグメントがたくさんあるはずです。

ここで、アプリをテストするとします。テスト チームは、各アクティビティを独自のブラック ボックスとして扱うことができます。これは、単一のアクティビティと多数のネストされたフラグメントに依存する単一の巨大なアプリよりもテストが簡単です。これは、バグが存在する場合に特に重要です。明白ではないバグが存在する場合、少なくともバグの範囲が多くのアクティビティのうちの 1 つのアクティビティに限定されていることはわかっています。

要約すると、個人としてアプリを開発しているので、開発に関する決定が他の人に影響を与えることはないと思います。大規模なチームでアプリを開発している場合は、視点が変わる可能性があります。その観点から、私の回答が非常に理にかなっていることを願っています.

于 2013-11-19T18:24:46.000 に答える
1

あなたの質問については、複雑なユーザー エクスペリエンスや、別のハードウェア コンポーネントを使用する必要がある複雑なアプリでは、フラグメントの代わりにアクティビティを使用する必要があるとしか言えません。

たとえば、写真を撮るステップがあるフォームを使用してアプリを作成し、この写真をメモリを使用するハードメモリタスク (顔検出など) に使用する必要がある場合は、このタスクをメインタスクから分離する必要があります。タスク アクティビティを作成し、マニフェストのアクセス許可をパーソナライズして、このアクティビティでのみより多くのメモリを使用できるようにします。

もう 1 つの例は、弱いメモリ アクティビティを使用する場合です (マニフェストで、アクティビティ スタックをクリアし、アクティビティが終了したときにガベージ コレクターが強制的にメモリをクリーンアップするようにプロパティを設定できます)。

より多くのアクティビティとフラグメントを使用する必要がある可能性が最も高い状況は、アプリのユーザー エクスペリエンスです。メニューを含む右側のドロワー カスタムが必要で、メニューのすべてのフラグメントに listView が含まれ、すべてのリスト ビューが詳細に表示される必要がある場合。適切な引き出しを非表示にして、フラグメントから詳細にスライドするアニメーションを作成するために多くのトリックを実行できますが、最も簡単な方法は、詳細用の新しいアクティビティを作成し、メインとは別のロジック/ライフサイクルで管理することです引き出しを使ったアクティビティ。2 つのアプリでこの選択を行いました。

iMeal - https://play.google.com/store/apps/details?id=it.fullsix.chiccoappe

GGRugby - https://play.google.com/store/apps/details?id=it.f6.template

このアプリでは、ドロワーはメイン フラグメント アクティビティにあり、すべてのメニューがコンテンツ フラグメントを変更します。コンテンツ フラグメントのリスト ビューは、アクティビティ コンテキストを意図的に変更し、別のアクティビティに移動します。

最後に、複数の fragmentActivity のみを使用する必要があると思われる状況がいくつかあります...しかし、これは私の作業パターンです。おそらく、アクティビティとフラグメントのみで何かを行うためのトリック/方法またはスコープを見つけることができます。

于 2013-11-12T11:32:22.407 に答える
0

遅すぎることはわかっていますが、Square はフラグメントについて意見を持っています。記事の要点は次のとおりです。

フラグメント: 得られた教訓

欠点はありますが、フラグメントは貴重な教訓を私たちに教えてくれました。この教訓は、アプリを作成するときに再適用できます。

  • 単一アクティビティ インターフェイス: 画面ごとに 1 つのアクティビティを使用する必要はありません。アプリを分離されたウィジェットに分割し、好きなように組み立てることができます。これにより、アニメーション化とライフサイクルが簡単になります。ウィジェットをビュー コードとコントローラー コードに分割できます。
  • バックスタックはアクティビティ固有の概念ではありません。アクティビティ内にバックスタックを実装できます。
  • 新しい API は必要ありません。アクティビティ、ビュー、レイアウト インフレータなど、最初から必要なものはすべて揃っていました。

複数のアクティビティを使用する必要はなく、フラグメントを使用する必要もありません。プレゼンターでカスタム ビューを使用できます。

ここで読むことができます: https://corner.squareup.com/2014/10/advocating-against-android-fragments.html .

Square のモルタル ライブラリは、https ://github.com/square/mortar にあります。

于 2016-06-14T01:53:17.270 に答える