たとえば、ユーザーが REST (またはその他の長時間実行される非同期操作) 中にデバイスの向きを変更した場合、フラグメントはアクティビティから切り離されます。
したがって、このフラグメントgetActivity()
が REST 応答を処理するコードのどこかで使用すると、null ポインターが発生します。
null チェックを使用して のすべての呼び出しを保護できgetActivity()
ますが、チェックラインと使用ラインの間でアクティビティが null になる可能性はまだあります。また、これを行う場所がたくさんあるため、コードがめちゃくちゃになります。
向き変更時にレイアウトを変更したい場合、 setRetainInstance(true) は使用できません。+複数のフラグメント、setRetainInstance(true)、画面の回転など、いくつかの奇妙な効果もあります。
したがって、これにより、残りの呼び出しをフラグメントで処理するのは一般的に悪い習慣になるのではないかと思いますか?
応答を処理するための非視覚的なフラグメントがアクティビティに含まれているいくつかのプラクティスを見てきました。しかし、これを断片化することはできないと思います。では、アクティビティをメディエーターとして使用し、結果を現在のフラグメントに到達させる必要がありますか?
すべてをフラグメントに入れる方がきれいだと思いました。他の場所でコードを変更する必要がないためです。そして、それは自己完結型のエンティティであり、問題なく別の場所に配置できます。しかし、これらの信頼できないコンテキストへの参照をどうすればよいでしょうか? つまり、フラグメントが再作成された場合、切り離されたフラグメントについてはまったく気にしません。実行していることを黙って終了する必要があり、例外で新しいワークフローを妨げないでください。try catch(Exception)
もちろん、他の状況でスローされる例外を気にするので、すべてを で囲みたくはありません。