Fragment#setRetainInstance(true)は紛らわしいと思います。 Android Developer API から抽出されたJavadocは次のとおりです。
public voidsetRetainInstance(ブール保持)
アクティビティの再作成(構成の変更など)でフラグメントインスタンスを保持するかどうかを制御します。これは、バックスタックにないフラグメントでのみ使用できます。設定されている場合、アクティビティが再作成されるとき、フラグメントのライフサイクルはわずかに異なります。
- onDestroy()は呼び出されません(ただし、フラグメントは現在のアクティビティから切り離されているため、onDetach()は呼び出されます)。
- onCreate(Bundle)は、フラグメントが再作成されていないため呼び出されません。
- onAttach(Activity)とonActivityCreated(Bundle)は引き続き呼び出されます。
質問:開発者としてどのようにこれを使用し、なぜそれが物事を簡単にするのですか?
開発者としてどのようにこれを使用しますか
setRetainInstance(true)
を呼び出します。通常は、onCreateView()
またはonActivityCreated()
で使用します。
そしてなぜそれが物事を簡単にするのですか?
構成の変更(たとえば、デバイスをポートレートからランドスケープに回転させる)を越えたデータの保持を処理するために、onRetainNonConfigurationInstance()
よりも単純になる傾向があります。保持されないフラグメントは破棄され、構成の変更時に再作成されます。保持されたフラグメントはそうではありません。したがって、これらの保持されたフラグメントが保持するデータは、構成変更後のアクティビティで使用できます。
ソケットなどの長時間実行されるリソースを開いたままにしておくのに非常に役立ちます。 Bluetoothソケットへの参照を保持するUIなしのフラグメントがあり、ユーザーが電話を入れたときにそれらを再接続することを心配する必要はありません。
また、ビットマップやサーバーデータのようにロードに時間がかかるリソースへの参照を保持するのにも便利です。一度ロードして、保持されたフラグメントに保持します。アクティビティがリロードされても、それはまだ存在しているため、再構築する必要はありません。
この回答は非常に遅れて追加されましたが、物事が明確になると思いました。私のことを言ってください。 setRetainInstanceが次の場合:
[〜#〜] false [〜#〜]
[〜#〜] true [〜#〜]
上記がDialogFragmentsとFragmentsに適用されることを忘れないでください。