41

私のアプリはフラグメントアクティビティを使用しています。縦向きモードのみで、画面を回転させる方法はありません。

元々はメソッドを使用していましたが、これらをフラグメントアクティビティ用commit()に無差別に変更する予定ですcommitAllowingStateLoss()

フラグメントを使用する個々のケースを再評価せずに無差別にこれを行わない理由はありますか?

4

5 に答える 5

57

私が正しく理解していれば、フラグメントを使用する個々のケースを再評価せずに無差別にこれを行わない理由はありますか?

答えは「はい」です。フラグメントを使用する個々のケースを慎重に再評価することなく、これを行うべきではありません。

もちろん、設定の変更 (画面の回転) による再起動を防止することで、主要な問題領域の 1 つを排除しましonSaveInstanceStateたcommitAllowingStateLoss。この場合、UI のフラグメントまたは一部が失われる可能性があります。これに関する非公式な議論については、この投稿を参照してください。

commitただし、 で置き換える前に考慮すべき状況が他にもありますcommitAllowingStateLoss。

  1. 基本的に、onSaveInstanceState と commitAllowingStateLoss の間の UI の更新: Android: IllegalStateException - スローされるのはいつですか?

  2. アクティビティの UI を更新するヘッドレス フラグメントがある場合、それらの更新の一部が失われる可能性があります (この記事を参照してください)。

  3. 電話/タブのリソースが不足しているため、Android はフラグメントを「強制終了」する可能性があります (この回答を参照してください)。

もちろん、画面の回転が防止onSaveInstanceStateされている場合は、呼び出されない可能性があります。その場合、更新が失われる可能性が高くなります。

使用することに決めた場合commitAllowingStateLoss、関連するリスクを最小限に抑えるためにできることは次のとおりです。たとえば、親アクティビティが次に再開されたときにcommit/を実行することを検討してexecutePendingTransactionsください (これを実行したくないことはわかっていますが、他の誰かがこれを読む可能性があります)。

最後に（再び誰かがこれを読んだ場合に備えて - これはあなたの場合には関係ありません）IllegalStateExceptionコミットから に移動するよりもおそらく an を処理するより安全な方法がありますcommitAllowStateLoss。たとえば、コミットに固執してIllegalStateException. または、Androidのバグに遭遇した可能性があり、回避策がある可能性があります。

于 2013-07-08T12:56:47.223 に答える
6 
public abstract int commit ()

このトランザクションのコミットをスケジュールします。コミットはすぐには行われません。次回のスレッドの準備ができたときに実行されるように、メイン スレッドでの作業としてスケジュールされます。

トランザクションは、その状態を保存するアクティビティを含む前に、このメソッドでのみコミットできます。その時点以降にコミットを試みると、例外がスローされます。これは、アクティビティをその状態から復元する必要がある場合、コミット後の状態が失われる可能性があるためです。コミットを失ってもよい状況については、commitAllowingStateLoss() を参照してください。

public abstract int commitAllowingStateLoss ()

API レベル 11 で追加

commit() と似ていますが、アクティビティの状態が保存された後にコミットを実行できます。後でアクティビティをその状態から復元する必要がある場合、コミットが失われる可能性があるため、これは危険です。そのため、これは、ユーザーの UI 状態が予期せず変更されても問題ない場合にのみ使用する必要があります。

FragmentActivity制限事項

Honeycomb (3.0) より前では、アクティビティの状態は一時停止する前に保存されていました。フラグメントはかなりの量の新しい状態であり、十分に動的であるため、一時停止と停止の間で頻繁に変更する必要があります。これらのクラスは、保存後にフラグメントの状態を変更しようとすると例外をスローし、UI の状態が偶発的に失われるのを防ぎます。ただし、一時停止する前に状態が保存される Honeycomb より前では、これは制限が厳しすぎます。これに対処するために、Honeycomb より前のプラットフォームで実行している場合、状態の保存と停止中のアクティビティの間でフラグメントを変更しても、例外はスローされません。これは、アクティビティが最後に保存された状態から復元された場合、これはユーザーが最後に見たものより少し前のスナップショットである可能性があることを意味します。

したがって、状態の喪失に関心がない場合は、あなたの決定は問題ないと思います。あなたの決定に役立つことを願っています。

于 2013-07-03T01:36:35.177 に答える
3

commitAllowingStateLoss() を無差別に使用するのではなく、OnPostResume コールバックで commit() を使用することをお勧めします。次のブログ投稿では、詳細な説明を提供してい ます http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html

@Override
protected void onPostResume() {
    super.onPostResume();
    // Commit your transactions here.
}
于 2014-08-20T14:07:26.003 に答える
1

このように次のメソッドをオーバーライドできます

@Override
public void supportFinishAfterTransition() {
    finish();
    super.supportFinishAfterTransition();
}

それは私のために働いた。

于 2016-12-24T22:30:41.477 に答える