1つのアクティビティと他のすべてのフラグメント
Activityで1つの画面を実装し、Fragmentsとmanaging all the fragments thru the activityで他のすべての画面を実装することを考えています。
それは良いアイデアですか？そして私の答えはNOですが、それでもこの考えについてもっと明確に知りたいです。
アイデアの長所と短所は何ですか？
注：
フラグメントとアクティビティのリンクを教えないでください。
編集：
以下は、フラグメントとアクティビティに関するものです。
長所：
- フラグメントは、サブアクティビティとしてアクティビティとともに使用されることを意図しています。
- フラグメントは、アクティビティの代替ではありません。
- フラグメントは再利用性を目的としています（再利用性をどのように実現できるかを知る必要があります）。
- フラグメントは、タブレットと携帯電話の両方をサポートするコードを記述するための最良の方法です。
短所：
- フラグメントからデータを取得するには、インターフェイスを実装する必要があります。
- 対話のために、私たちはそれを示すために長い道のりを歩かなければなりません。
タブレットを検討していない場合にフラグメントを使用する理由は何ですか？アクティビティとフラグメントの開始時間の違いは何ですか？
作成しているアプリによって異なります。両方のアプローチを使用していくつかのアプリを作成しましたが、一方が常に他方より優れているとは言えません。作成した最新のアプリでは、単一のActivityアプローチとFacebookスタイルのナビゲーションを使用しました。ナビゲーションリストから項目を選択するとき、単一のFragmentコンテナを更新してそのセクションを表示します。
そうは言っても、単一のActivityを使用すると、多くの複雑さが生じます。編集フォームがあり、ユーザーが選択または作成する必要があるアイテムの一部については、新しい画面に移動する必要があるとします。アクティビティでは、startActivityForResultを使用して新しい画面を呼び出しますが、Fragmentsを使用すると、そのようなことはないため、Activityに値を保存し、メインの編集フラグメントでActivityは、データが選択されており、ユーザーに表示する必要があるかどうかを確認します。
単一のActivity型に固執することについてAravindが言っていることも事実ですが、実際にはそのような制限はありません。アクティビティは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）の状態に関するこの素晴らしい投稿を読み、この古い答えを思い出しました。私は共有すると思います： フラグメント：Androidのすべての問題の解決策
1つのアクティビティと17個のフラグメントがあり、すべてフルスクリーンであるプロジェクト（開発中の5か月）を終了しようとしています。これは私の2番目のフラグメントベースのプロジェクトです（以前は4か月でした）。
長所
- 主なアクティビティは700行のコードで、フラグメントナビゲーションの順序をうまく管理します。
- 各フラグメントは独自のクラスにうまく分割されており、比較的小さくなっています（〜ui行の100行を結合）。
- 管理者は「ねえ、これらの画面の順序を切り替える方法はどうですか」と言うことができます。これらのフラグメントは互いに依存せず、すべてアクティビティを通じて通信するため、非常に簡単に行うことができます。個々のアクティビティを掘り下げて、互いの呼び出し先を見つける必要はありません。
- 私のアプリは非常にグラフィックが多く、1画面1アクティビティとして機能することはありません。メモリ内のこれらのすべてのサブアクティビティは、アプリを常にメモリ不足にするため、表示されないすべてのアクティビティを
finish()し、フラグメントの場合と同じように、ナビゲーション用に同じ制御ロジックを作成する必要があります。 。これだけでフラグメントを使用することもできます。 - タブレットアプリを使用する場合、すべてが既にうまく分離されているため、リファクタリングを簡単に行うことができます。
短所
- フラグメントの使い方を学ばなければなりません
まず、何をするにしても、アクティビティやフラグメントに大きく依存しない、モデル、ビュー、プレゼンターを使用したモジュラーデザインがあることを確認します。
アクティビティとフラグメントは実際に何を提供しますか？
- ライフサイクルイベントとバックスタック
- コンテキストとリソース
したがって、そのためにそれらを使用しますONLY。彼らには十分な責任がありますが、過度に複雑にしないでください。私は、ActivityまたはFragmentでTextViewをインスタンス化することでさえ、悪い習慣だと主張します。 public View findViewById（int id） are PUBLICなどのメソッドがあります。
質問はより簡単になりました。複数の独立したライフサイクルイベントとバックスタックが必要ですか？もしそうだと思うなら、フラグメントを使用してください。絶対に考えない場合は、フラグメントを使用しないでください。
最終的には、独自のバックスタックとライフサイクルを作成できます。しかし、なぜホイールを再作成するのですか？
編集：なぜこれを反対票ですか？単目的クラスの人々！各アクティビティまたはフラグメントは、ビューをインスタンス化するプレゼンターをインスタンス化できる必要があります。プレゼンターとビューは交換可能なモジュールです。アクティビティまたはフラグメントに発表者の責任があるのはなぜですか？
長所
すべてのフラグメントは互いに独立しているため、単一のアクティビティからフラグメントを制御できます。フラグメントには、独自のライフサイクル（onPause、onCreate、onStart...）があります。ライフサイクルを持つことで、フラグメントはイベントに独立して応答し、onSaveInstanceStateを介して状態を保存し、戻すことができます（つまり、着信コールの後に再開するとき、またはユーザーが[戻る]ボタンをクリックするとき）。
短所
- アクティビティコードに複雑さを作成します。
- フラグメントの順序を管理する必要があります。
それでも、いくつかのビューを表示したいアプリを作成する必要があるかのように、それは非常に良い考えです。この考え方により、単一のビューで複数のフラグメントを表示できます。
アプリのデザインレイアウトによって異なります。デザインレイアウトのActionBarでタブを使用している場合、アプリの単一アクティビティでタブクリックでフラグメントを変更できると仮定します。アクティビティがあり、ActionBarに3つのタブがあり、Fragmentsによって提供されるタブのビューがあるとします。これにより、管理が容易になり、実行も可能になります。そのため、すべてはアプリの設計スキームと、そのためにどのように決定するかによって異なります。
長所：
- Xmlレイアウトを介して、複数の画面サイズと向きで使用可能な単一のインターフェースを作成するために使用できます。
短所：
- アクティビティでより複雑なコードが必要です。
現在の画面サイズと向きに基づいて異なるxmlレイアウトを使用すると、アプリがより使いやすくなり、スマートフォンとタブレットの両方でアプリをリリースする予定がある場合、アプリの複数のバージョンをリリースする必要性を減らすことができるため、それは良い考えだと思います。アプリがタブレットと携帯電話の両方で使用されることがない場合、おそらく面倒な価値はありません。
私は、すべてのビューのインフレーションをフラグメントに延期して、柔軟性を高めることを提案しています。たとえば、複数のフラグメントを集約するタブレットの単一のランディングアクティビティがあり、同じフラグメントを電話機で再利用して、フラグメントごとに1つの画面を表示します。ただし、電話の実装では、各画面に個別のアクティビティがあります。アクティビティには、あまりに多くのコードはありません。ビューのインフレーションのために、対応するフラグメントに直ちに延期するためです。
タブまたはメニューナビゲーションはまったく新しい画面になるため、タブまたはスライドアウトメニューが導入されたときに、電話の実装を単一のランディングアクティビティに変更することは悪い考えだと思います。