私は数日前にフラグメントから始めましたが、それは私にとっては有線のようです。複雑さが大幅に増加することの正当な利点はわかりません。アクティビティまたはフラグメントに機能を実装する必要があるかどうかはわかりません。最初に、私はそれを断片に入れようとしましたが、それはしばしば不可能であるように思われます。
例：ボタンをクリックした後、ユーザー入力としてダイアログが表示されます。そこで、リスナーを介してボタンクリックをフラグメントからアクティビティに転送し、アクティビティでダイアログを開きました。ダイアログで、新しい関数を開始しました（つまり、Activityでの実装）。Androidの開発者は、フラグメントにアラートダイアログを追加するためのヒントを提供します。
ただし、このフラグメントはまだ実装されており、アクティビティと重く組み合わされています（ダイアログのボタンアクションはアクティビティにあります）。
そのため、モデルとビューは非常に混同されています。保守が難しい静的コードに付加価値が見当たらないのですか？！
フラグメントについてのあなたの意見やアドバイスは何ですか？
を使用する場合、それらはであるとFragments考えることができ、はであると考えることができます。私の個人的な意見では、FragmentsはタブレットをサポートするためのGoogleのひざまずく反応でしたが、今ではそれらに固執しています:(ViewActivityController
私は毎日断片を使用していますが、確かにあなたの痛みを感じます。それらについて最初に読んだとき、私は「これは本当にクールだ」と思いましたが、それらを使用した後、それらは非常に多くの点で不足していますが、主に私がそれらを誤って使用するためです:(
これが私が遭遇した落とし穴のいくつかです...
クリックを処理するのはフラグメントレイアウトであり、フラグメントレイアウトではないためonclick、フラグメントレイアウトでは使用しないでください。属性を使用し、後で別のフラグメントでフラグメントを使用する場合は、その属性にもメソッドを追加することを忘れないでください。したがって、を使用してから、フラグメントのにクリックハンドラを手動でアタッチします。ActivityFragmentActivityonclickActivityfindViewByIdonCreateView
他のフラグメントと通信する場合はActivity、をコントローラーとして使用してメッセージを送信します。（インターフェイスを使用してこれを行う方法の例がたくさんあります）。ここで重要なのは、あるフラグメントが別のフラグメントと直接通信するデバイスで複数のフラグメントを実行している場合、奇妙な、しかし予測可能な動作に遭遇することです。たとえば、フラグメントAがフラグメントBのビューを直接更新したが、フラグメントBが表示されていない場合（交換したため、電話を検討してください）、フラグメントBが表示されている場合、はView更新されない可能性があります。View再作成されました。したがって、更新する場合は、Fragment必ずフラグメント内のデータを更新してからView、onCreateViewこれは、フラグメントが再び表示されるようになったときに呼び出されます（つまり、現在のフラグメントをポップした場合、前のフラグメントが表示されます）
フラグメントのみを使用して完全なアプリケーションを構築しないでください。代わりに、アクティビティを使用して通常どおりにアプリを作成し、それを処理しFragmentて、見栄えのするビューを作成します（これはそうです）。つまり、複数のフラグメントと複数のアクティビティがあり、一部のアクティビティが複数のフラグメントを使用するようにアプリを設計します。
フラグメントに関する最初の考えは、フラグメントと1つのアクティビティを使用して完全なアプリを作成するだけでよいと思ったものでした...最終的にアプリを完成させましたが、そのアプローチを使用すると非常に多くの問題に遭遇しました。私の次のアプローチは、複数のフラグメントと複数のアクティビティを使用することでしたが、それははるかにうまくいきました。
結論として、フラグメントをとして使用する場合は優れていますViewが、アクティビティのように使用しようとすると、問題が発生します:(->を- Activiy>Fragmentとして考えてください。ControllerView
また、アクティビティライフサイクルに加えてフラグメントライフサイクルを読んで理解することをお勧めします（Pro Android 4にはそれを表す優れた画像があります）。そうすれば、何時間もの苦痛を節約できます:)
フラグメントはビューロジックを提供するため、他のアクティビティに移植できます。ほとんどの場合、アクティビティは真のコントローラーの役割に移行しています。以前のAndroidアーキテクチャでは、ほとんどのアプリを実装するためにViewをサブクラス化した人がいなかったため、Viewロジックとコントローラーロジックが一緒にマッシュアップされていました。彼らは基本的にXMLレイアウトファイルでレイアウトを行い、次にアクティビティで直接ビューオブジェクトを引き出しました。つまり、アクティビティはクリックリスナー、キーリスナー、ドラッグロジックなどを登録していました。これは通常、他のツールキットのViewの別のサブクラスで行うことです。彼らがこれを行ったので、それはあなたがコーディングしたばかりの本当にクールなドラッグマルチタッチジェスチャListViewがその1つのアクティビティで立ち往生していることを意味しました。これを別のアクティビティでもう一度使用します。さてあなたはSOLです フラグメントを使用すると、そのロジックをアクティビティからフラグメントに簡単に移動できます。技術的にはカスタムコンポーネントビューに移動できますが、フラグメントにはさらに別の利点があります。フラグメントを使用すると、タブレットや小型デバイスで実行できるアプリケーションを作成しながら、それぞれのレイアウトを変更できます。それがどのように機能するかを理解するのは難しいですが、単一のアクティビティには、フォームファクタごとに異なるレイアウトを持つ複数のフラグメントを含めることができます。カスタムコンポーネントでは、これほど簡単には実行できないことがあります。さらに、カスタムコンポーネントはレイアウトファイルを使用できません。あなたはフラグメントで諦めない何かを完全なJavaコードに行かなければなりません。ただし、フラグメントにはさらに別の利点があります。フラグメントを使用すると、それぞれのレイアウトを変えながら、タブレットや小型のデバイスで実行できるアプリケーションを作成できます。それがどのように機能するかを理解するのは難しいですが、単一のアクティビティには、フォームファクタごとに異なるレイアウトを持つ複数のフラグメントを含めることができます。カスタムコンポーネントでは、これほど簡単には実行できないことがあります。さらに、カスタムコンポーネントはレイアウトファイルを使用できません。あなたはフラグメントで諦めない何かを完全なJavaコードに行かなければなりません。ただし、フラグメントにはさらに別の利点があります。フラグメントを使用すると、それぞれのレイアウトを変えながら、タブレットや小型のデバイスで実行できるアプリケーションを作成できます。それがどのように機能するかを理解するのは難しいですが、単一のアクティビティには、フォームファクタごとに異なるレイアウトを持つ複数のフラグメントを含めることができます。カスタムコンポーネントでは、これほど簡単には実行できないことがあります。さらに、カスタムコンポーネントはレイアウトファイルを使用できません。あなたはフラグメントで諦めない何かを完全なJavaコードに行かなければなりません。さらに、カスタムコンポーネントはレイアウトファイルを使用できません。あなたはフラグメントで諦めない何かを完全なJavaコードに行かなければなりません。さらに、カスタムコンポーネントはレイアウトファイルを使用できません。あなたはフラグメントで諦めない何かを完全なJavaコードに行かなければなりません。
あなたが提供した例は、フラグメントを設計するための迅速で汚いアプローチだと思います。Fragmentが委任するインターフェイスを抽出することで、バックリファレンス（このネストスコープ）を簡単に抽出できます。
OK、mvアーキテクチャで実行しました...
public AlertDialog openLocInput() {
AlertDialog.Builder alert = new AlertDialog.Builder(getActivity());
alert.setTitle("Login");
alert.setMessage("Enter Pin :");
// Set an EditText view to get user input
final EditText input = new EditText(getActivity());
alert.setView(input);
alert.setPositiveButton("Ok", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int whichButton) {
jsonHandler.obtainMessage(1, input.getText().toString())
.sendToTarget();
dialog.dismiss();
return;
}
});
alert.setNegativeButton("Cancel",
new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int which) {
dialog.dismiss();
return;
}
});
return alert.create();
}
フラグメントに実装されています...フラグメントからこのalertdialogを開始します。
fragment_userlocation_btn_addLocation.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
openLocInput().setOwnerActivity(getActivity());
openLocInput().show();
}
});
フラグメントにも実装されています。
しかし、私はまだ過剰殺害理論を信じています...
UIの5％未満が再利用されると思うので、フラグメントをロードするアクティビティとフラグメントなしのUIロジックを含むアクティビティを混同することをお勧めしますか？
フラグメントの本当の利点はタブレットの最適化だと思いますが、現時点では、モバイルデバイスの使用量と比較したタブレットの使用量は非常に少ないです。それに加えて、タブレットはモバイルデバイスほど「モバイル」ではなく、コンテキストアウェア開発に焦点を合わせていません...