159

Activity1 つの画面を で実装し、他のすべての画面を およびFragmentsで実装することを考えていmanaging all the fragments thru the activityます。

それは良い考えですか？私の答えはNOですが、それでもこの考えについてもっとはっきりと知りたいと思っています。

アイデアの長所と短所は何ですか？

ノート：

フラグメントとアクティビティのリンクは教えないでください。

編集：

フラグメントとアクティビティに関するものを次に示します。

長所：

  1. フラグメントは、サブ アクティビティとしてアクティビティと共に使用することを意図しています。
  2. フラグメントはアクティビティの代わりにはなりません。
  3. フラグメントは再利用性を目的としています (再利用性を実現する方法を知る必要があります)。
  4. フラグメントは、タブレットと電話の両方をサポートするコードを記述するための最良の方法です。

短所：

  1. フラグメントからデータを取得するためのインターフェースを実装する必要があります。
  2. ダイアログについては、それを表示するために長い道のりを歩まなければなりません。

タブレットを考慮していないのに、なぜフラグメントを使用する必要があるのでしょうか? アクティビティとフラグメントの開始時間の差は?

4

8 に答える 8

95

作成するアプリによって異なります。私は両方のアプローチを使用していくつかのアプリを作成しましたが、一方の方法が常に他方よりも優れているとは言えません。私が作成した最新のアプリでは、単一のActivityアプローチと Facebook スタイルのナビゲーションを使用しました。ナビゲーション リストから項目を選択するときは、単一​​のFragmentコンテナーを更新してそのセクションを表示します。

とはいえ、シングルを持つことActivityは多くの複雑さももたらします. 編集フォームがあり、ユーザーが選択または作成する必要があるアイテムの一部について、新しい画面に移動する必要があるとします。アクティビティでは、新しい画面を呼び出すだけstartActivityForResultですFragmentsが、そのようなことはないため、値を に保存しActivity、メインの編集フラグメントで をチェックしActivityて、データが選択されていて、ユーザーに表示する必要があるかどうかを確認します。

Aravind が単一のActivityタイプに固執することについて言っていることも真実ですが、実際にはその制限ではありません。あなたのアクティビティは FragmentActivity であり、必要がない限り、MapView実際の制限はありません。ただし、マップを表示したい場合は実行できますが、Android 互換性ライブラリを変更してFragmentActivity拡張するMapActivityか、公開されているandroid-support-v4-googlemaps を使用する必要があります。

最終的に、私が知っているほとんどの開発者は、1 つのActivityルートをたどり、コードを簡素化するために複数のアクティビティに戻りました。UIに関しては、タブレットではActivity、デザイナーが思いついたクレイジーな相互作用を実現するためだけに、単一の使用に行き詰まることがあります:)

- 編集 -

Google がついにMapFragment互換ライブラリをリリースしたので、android-support-v4-googlemaps ハックを使用する必要がなくなりました。更新についてはこちらをご覧ください: Google Maps Android API v2

-- 編集 2 --

フラグメントの最新 (2017 年) の状態に関するこの素晴らしい投稿を読んだところ、この古い回答を思い出しました。私が共有したいと思った: Fragments: The Solution to All of Android's Problems

于 2012-08-31T19:00:05.173 に答える
85

私は、1 つのアクティビティと 17 のフラグメントをすべてフルスクリーンで持つプロジェクト (開発に 5 か月) を完了しようとしています。これは私の 2 番目のフラグメント ベースのプロジェクトです (前は 4 か月でした)。

長所

  • 主なアクティビティは 700 行のコードで、フラグメント ナビゲーションの順序を適切に管理しています。
  • 各フラグメントは独自のクラスに適切に分離されており、比較的小さくなっています (数百行の UI 要素)。
  • 管理者は「これらの画面の順序を入れ替えてみませんか」と言うことができ、私はそれを非常に簡単に行うことができます。これらのフラグメントは相互に依存せず、アクティビティを通じてすべて通信するからです。個々のアクティビティを掘り下げて、それらがお互いを呼び出している場所を見つける必要はありません。
  • 私のアプリは非常にグラフィックスが多く、1 画面 1 のアクティビティとしては機能しません。これらすべてのサブ アクティビティがメモリ内にあると、常にアプリのメモリが不足するため、finish()非表示のすべてのアクティビティに対して、フラグメントの場合と同様に、ナビゲーション用に同じ制御ロジックを作成する必要があります。このため、フラグメントでそれを行うこともできます。
  • タブレット アプリを作成する場合は、すべてが適切に分離されているため、リファクタリングが容易になります。

短所

  • フラグメントの使い方を学ぶ必要があります
于 2013-08-08T09:46:47.030 に答える
16

まず、何をするにしても、アクティビティやフラグメントに大きく依存しないモデル、ビュー、プレゼンターを使用するモジュール設計があることを確認してください。

アクティビティとフラグメントは実際に何を提供しますか?

  1. ライフサイクル イベントとバックスタック
  2. コンテキストとリソース

したがって、そのためにのみ使用してください。彼らには十分な責任があります。過度に複雑にしないでください。Activity または Fragment で TextView をインスタンス化することさえ悪い習慣であると私は主張します。public View findViewById (int id)のようなメソッドがPUBLICである理由があります。

質問はより単純になります。複数の独立したライフサイクル イベントとバックスタックが必要ですか? そうかもしれないと思う場合は、フラグメントを使用してください。絶対にないと思う場合は、フラグメントを使用しないでください。

最終的には、独自のバックスタックとライフ サイクルを作成できます。しかし、なぜ車輪を再作成するのですか？

編集：なぜこれに反対票を投じるのですか？単目的クラスの方々！各アクティビティまたはフラグメントは、ビューをインスタンス化するプレゼンターをインスタンス化できる必要があります。プレゼンターとビューは交換可能なモジュールです。アクティビティまたはフラグメントにプレゼンターの責任があるのはなぜですか??

于 2013-10-09T15:56:37.463 に答える
12

長所

すべてのフラグメントは互いに独立しているため、単一のアクティビティからフラグメントを制御できます。フラグメントには独自のライフサイクル ( onPause、onCreate、 ...) があります。onStartライフサイクルを持つことで、フラグメントは独立してイベントに応答し、 を介して状態を保存し、onSaveInstanceState元に戻すことができます (つまり、着信後に再開するときや、ユーザーが [戻る] ボタンをクリックしたときなど)。

短所

  1. アクティビティのコードを複雑にします。
  2. フラグメントの順序を管理する必要があります。

とはいえ、いくつかのビューを表示したいアプリを作成する必要があるかのように、これは非常に良い考えです。このアイデアにより、複数のフラグメントを 1 つのビューで表示できるようになります。

于 2012-09-06T06:59:30.863 に答える
2

アプリのデザイン レイアウトによって異なります。デザイン レイアウトで ActionBar のタブを使用している場合、アプリのシングル アクティビティで、タブのクリックでフラグメントを変更できるとします。これでアクティビティができ、ActionBar に 3 つのタブがあり、フラグメントによって提供されるタブのビューがあるとします。これにより、管理が容易になり、実現可能になります。そのため、すべてはアプリの設計スキームと、アプリの構築をどのように決定するかによって異なります。

于 2012-09-04T10:49:21.943 に答える
1

長所：

  • xmlレイアウトを介して、複数の画面サイズと向きで使用できる単一のインターフェイスを作成するために使用できます。

短所：

  • アクティビティにはより複雑なコードが必要です。

現在の画面サイズと向きに基づいて異なるxmlレイアウトを使用すると、アプリが使いやすくなり、携帯電話とタブレットの両方でアプリをリリースする予定がある場合に、アプリの複数のバージョンをリリースする必要性を減らすことができるため、これは良い考えだと思います。アプリがタブレットと携帯電話の両方で使用されることがない場合は、おそらく問題を起こす価値はありません。

于 2012-08-28T16:22:36.003 に答える
0

私は、より優れた柔軟性を提供するために、すべてのビューの拡張をフラグメントに延期することを支持しています。たとえば、複数のフラグメントを集約し、電話で同じフラグメントを再利用してフラグメントごとに 1 つの画面を表示するタブレット用の 1 つのランディング アクティビティを用意します。ただし、電話の実装では、画面ごとに個別のアクティビティが必要です。ビューのインフレーションについては、対応するフラグメントにすぐに任せるため、アクティビティにはあまり多くのコードはありません。

タブやメニューのナビゲーションが完全に新しい画面になるだけなので、タブやスライドアウトメニューが導入されたときに電話の実装を単一のランディングアクティビティに変更する必要があるのは悪い考えだと思います.

于 2013-11-13T15:09:36.957 に答える
-1

シングルアクティビティアプローチを使用しない最も重要な理由は、アクティビティのライフサイクルを利用できるようにするためです。アクティビティには、アプリケーションの特定の部分のコンテキスト動作が含まれ、フラグメントはその動作を補足します。onPauseアクティビティライフサイクルのオーバーライド可能なステップを利用する機能があると、やなどのメソッドを使用して、あるアクティビティの動作を別のアクティビティから分離するのに役立ちますonResume。このライフサイクルにより、前のコンテキストに戻ることもできます。シングルアクティビティアプローチでは、フラグメントを残した後、そのフラグメントに戻るメカニズムを作成する必要があります。

于 2012-08-30T19:25:57.787 に答える