1つのアクティビティと他のすべてのフラグメント[終了]

私は1画面の実装を考えていますActivityし、他のすべてのsreens Fragmentsとmanaging all the fragments thru the activity。

それは良い考えですか？私の答えは「いいえ」ですが、それでもこの考えについてもっと明確に知りたいのです。

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

注意：

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

編集：

これはフラグメントとアクティビティに関するものです：

長所：

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

短所：

1. フラグメントからデータを取得するには、インターフェースを実装する必要があります。
2. 対話については、それを示すのに長い道のりが必要です。

タブレットを考慮しない場合、なぜフラグメントを使用する必要があるのですか？アクティビティとフラグメントの開始時間の違いは何ですか？

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

とはいえ、シングルを使用すると、Activity複雑さが増します。編集フォームがあり、ユーザーが選択または作成する必要がある一部のアイテムについて、新しい画面に移動する必要があるとします。アクティビティでは、新しい画面をstartActivityForResultが、とFragmentsあなたは上の値を格納し終わるようなものは存在しないActivityとメインの編集フラグメントはチェックしたActivityデータが選択されていて、ユーザーに表示する必要があるかどうかを確認するためには。

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

結局のところ、私が知っているほとんどの開発者はActivity、コードを簡略化するために、1つのルートで複数のアクティビティに戻ってきました。UIに関しては、タブレットではActivity、デザイナーが思いついたクレイジーなインタラクションを実現するためだけに、シングルを使用するのが難しい場合があります。

-編集-

グーグルがついにリリース MapFragment互換性ライブラリをしたため、android-support-v4-googlemapsハックを使用する必要がなくなりました。アップデートについてはこちらをお読みください：Google Maps Android API v2

-編集2-

私はフラグメントの現代（2017）の状態に関するこの素晴らしい記事を読んだだけで、この古い答えを思い出しました。私が共有すると思いました：フラグメント：Androidのすべての問題の解決策

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

長所

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

短所

• あなたはフラグメントを使用する方法を学ぶ必要があります

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

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

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

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

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

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

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

長所

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

短所

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

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

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

長所：

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

短所：

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

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

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

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

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