IllegalStateException: nie można wykonać tej akcji po onSaveInstanceState z ViewPager

Istnieje wiele powiązanych problemów z podobnym Komunikatem o błędzie. Sprawdź drugą linię tego konkretnego śladu stosu. Wyjątek ten jest szczególnie związany z wywołaniem FragmentManagerImpl.popBackStackImmediate.

Wywołanie tej metody, podobnie jak popBackStack, spowoduje zawsze niepowodzenie z IllegalArgumentException, jeśli stan sesji został już zapisany. Sprawdź źródło. Nic nie możesz zrobić, aby powstrzymać ten wyjątek.

• usunięcie połączenia do super.onSaveInstanceState nie pomoże.
• Tworzenie fragmentu z Nie pomoże.

Oto jak zaobserwowałem problem:

• jest formularz z przyciskiem submit.
• Po kliknięciu przycisku tworzy się okno dialogowe i rozpoczyna się proces asynchroniczny.
• użytkownik klika klucz domowy przed zakończeniem procesu - wywoływany jest onSaveInstanceState.
• proces kończy się, wywołanie zwrotne jest i popBackStackImmediate jest próbowany.
• IllegalStateException jest wyrzucony.

Oto, co zrobiłem, aby go rozwiązać:

Ponieważ nie jest możliwe, aby uniknąć IllegalStateException w wywołaniu zwrotnym, Złap i zignoruj go.

try {
    activity.getSupportFragmentManager().popBackStackImmediate(name);
} catch (IllegalStateException ignored) {
    // There's no way to avoid getting this if saveInstanceState has already been called.
}

To wystarczy, aby powstrzymać awarię aplikacji. Ale teraz użytkownik przywróci aplikację i zobaczy, że Przycisk, o którym myślał, że nacisnął, w ogóle nie został naciśnięty (myślą). Fragment formularza wciąż się pokazuje!

Aby to naprawić, po utworzeniu okna dialogowego wprowadź stan wskazujący, że proces się rozpoczął.

progressDialog.show(fragmentManager, TAG);
submitPressed = true;

I zapisz ten stan w pakiecie.

@Override
public void onSaveInstanceState(Bundle outState) {
    ...
    outState.putBoolean(SUBMIT_PRESSED, submitPressed);
}

Nie zapomnij załaduj go ponownie w onViewCreated

Następnie, po wznowieniu, wycofaj fragmenty, jeśli wcześniej próbowano przesłać. Uniemożliwia to użytkownikowi powrót do tego, co wydaje się nie przesłanym formularzem.

@Override
public void onResume() {
    super.onResume();
    if (submitPressed) {
        // no need to try-catch this, because we are not in a callback
        activity.getSupportFragmentManager().popBackStackImmediate(name);
        submitPressed = false;
    }
}

Sprawdź czy aktywność {[1] } przed pokazaniem fragmentu i zwróć uwagę na commitAllowingStateLoss().

Przykład:

if(!isFinishing()) {
FragmentManager fm = getSupportFragmentManager();
            FragmentTransaction ft = fm.beginTransaction();
            DummyFragment dummyFragment = DummyFragment.newInstance();
            ft.add(R.id.dummy_fragment_layout, dummyFragment);
            ft.commitAllowingStateLoss();
}

Oto inne rozwiązanie tego problemu.

Używając prywatnej zmiennej członkowskiej, możesz ustawić zwrócone dane jako intencję, która może być następnie przetworzona po super.onResume ();

Like so:

private Intent mOnActivityResultIntent = null; 

@Override
protected void onResume() {
    super.onResume();
    if(mOnActivityResultIntent != null){
        ... do things ...
        mOnActivityResultIntent = null;
    }
 }

@Override
public void onActivityResult(int requestCode, int resultCode, Intent data){
    if(data != null){
        mOnActivityResultIntent = data;
    }
}

Jest Październik 2017, a Google tworzy bibliotekę wsparcia dla Androida z nowym komponentem things call Lifecycle. Dostarcza nowego pomysłu na ten problem "nie można wykonać tej akcji po onSaveInstanceState".

W skrócie:

• użyj komponentu cyklu życia, aby określić, czy to właściwy czas na wyświetlenie fragmentu.

Dłuższa wersja z wyjaśnieniem:

• Dlaczego ten problem wyszedł na jaw?

  To dlatego, że próbujesz użyć FragmentManager ze swojej aktywności (która będzie trzymać Twój fragment, jak przypuszczam?), aby zatwierdzić transakcję dla Ciebie. Zazwyczaj wygląda to tak, jakbyś próbował wykonać jakąś transakcję dla nadchodzącego fragmentu, tymczasem aktywność hosta już wywołuje metodę savedInstanceState (Użytkownik może się zdarzyć, że dotknie przycisku home, więc aktywność wywołuje onStop(), w moim przypadku jest to powód) {]}

  Zazwyczaj ten problem nie powinien się zdarzyć - zawsze staramy się załadować fragment do aktywności na samym Początek, jak metoda onCreate() jest do tego idealnym miejscem. Ale czasami zdarza się to , zwłaszcza gdy nie możesz zdecydować, który fragment załadujesz do tej czynności, lub próbujesz załadować fragment z bloku AsyncTask (lub cokolwiek zajmie trochę czasu). Czas, zanim transakcja fragmentu naprawdę się wydarzy, ale po metodzie onCreate() aktywności, użytkownik może zrobić wszystko. Jeśli użytkownik naciśnie przycisk home, który uruchomi metodę onSavedInstanceState(), pojawi się can not perform this action crash.

  Jeśli ktoś chce zajrzeć głębiej w ten temat, proponuję zajrzeć na ten blog post . Wygląda głęboko w warstwie kodu źródłowego i wyjaśnia wiele na ten temat. Ponadto, podaje powód, dla którego nie powinieneś używać metody commitAllowingStateLoss(), aby obejść tę awarię (zaufaj mi, nie oferuje ona nic dobrego dla Twojego kodu)

• Jak to naprawić?

  • Czy powinienem użyć metody commitAllowingStateLoss() do załadowania fragmentu? Nope you nie powinno;

  • Czy powinienem nadpisać metodę onSaveInstanceState, zignorować metodę super wewnątrz niej? nie powinieneś;

  • Czy powinienem użyć magicznej aktywności isFinishing wewnątrz, aby sprawdzić, czy aktywność hosta jest we właściwym momencie dla transakcji fragmentarycznej? Tak, to wygląda na właściwą drogę.

• Spójrz na to, co może zrobić komponent cyklu życia .

  W zasadzie Google sprawia, że niektóre implementacja wewnątrz klasy AppCompatActivity (i kilku innych klas bazowych, których powinieneś użyć w projekcie), co ułatwia określenie bieżącego stanu cyklu życia. Przyjrzyjmy się naszemu problemowi: dlaczego miałby się on wydarzyć? To dlatego, że robimy coś w złym momencie. Więc staramy się tego nie robić, a ten problem zniknie.

  Trochę koduję do własnego projektu, oto co robię używając LifeCycle. Koduję w Kotlinie.

val hostActivity: AppCompatActivity? = null // the activity to host fragments. It's value should be properly initialized.

fun dispatchFragment(frag: Fragment) {
    hostActivity?.let {
       if(it.lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED)){
           showFragment(frag)
       }
    }
}

private fun showFragment(frag: Fragment) {
    hostActivity?.let {
        Transaction.begin(it, R.id.frag_container)
                .show(frag)
                .commit()
    }

Jak pokazałem powyżej. I sprawdzi stan cyklu życia aktywności hosta. W przypadku komponentu cyklu życia w bibliotece Wsparcia może to być bardziej szczegółowe. Kod lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED) oznacza, jeśli obecny stan jest co najmniej onResume, nie później niż to? Co sprawia, że moja metoda nie będzie wykonywana podczas innego stanu życia(jak onStop).

• Wszystko gotowe? Oczywiście, że nie. Kod, który pokazałem, mówi o nowym sposobie zapobiegania awarii aplikacji. Ale jeśli dojdzie do stanu onStop, ta linia kod nie robi rzeczy, a tym samym nic nie pokazuje na ekranie. Kiedy użytkownicy wrócą do aplikacji, zobaczą pusty ekran, czyli pustą aktywność hosta, nie pokazującą żadnych fragmentów. To złe doświadczenie(tak trochę lepsze niż awaria).

  Więc chciałbym, żeby było coś ładniejszego: aplikacja nie zawiesi się, jeśli dojdzie do stanu życia później niż onResume, metoda transakcji jest świadomy stanu życia; poza tym, aktywność będzie próbować kontynuować, aby zakończyć tę transakcję fragment akcja, po powrocie użytkownika do naszej aplikacji.

  Dodaję coś więcej do tej metody:

class FragmentDispatcher(_host: FragmentActivity) : LifecycleObserver {
    private val hostActivity: FragmentActivity? = _host
    private val lifeCycle: Lifecycle? = _host.lifecycle
    private val profilePendingList = mutableListOf<BaseFragment>()

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun resume() {
        if (profilePendingList.isNotEmpty()) {
            showFragment(profilePendingList.last())
        }
    }

    fun dispatcherFragment(frag: BaseFragment) {
        if (lifeCycle?.currentState?.isAtLeast(Lifecycle.State.RESUMED) == true) {
            showFragment(frag)
        } else {
            profilePendingList.clear()
            profilePendingList.add(frag)
        }
    }

    private fun showFragment(frag: BaseFragment) {
        hostActivity?.let {
            Transaction.begin(it, R.id.frag_container)
                    .show(frag)
                    .commit()
        }
    }
}

Utrzymuję listę wewnątrz tej klasy dispatcher, aby przechowywać te fragmenty nie mają szans na zakończenie akcji transakcyjnej. A gdy użytkownik wróci z ekranu głównego i stwierdzi, że fragment nadal czeka na uruchomienie, przejdzie do metody resume() pod adnotacją @OnLifecycleEvent(Lifecycle.Event.ON_RESUME). Teraz myślę, że powinno działać tak, jak się spodziewałem.

Rozwiązanie krótkie i robocze:

Kroki

Krok 1: nadpisanie onSaveInstanceState stanu w odpowiednim fragmencie. I usuń z niego super metodę.

 @Override
public void onSaveInstanceState( Bundle outState ) {

}  

Krok 2: Użycie fragmentTransaction.commitAllowingStateLoss( );

Zamiast fragmentTransaction.commit( ); podczas operacji fragment.

Uwaga , użycie transaction.commitAllowingStateLoss() może spowodować złe wrażenia dla użytkownika. Aby uzyskać więcej informacji na temat tego wyjątku, Zobacz ten post .

Znalazłem brudne rozwiązanie tego rodzaju problemu. Jeśli nadal chcesz zachować ActivityGroups z jakiegokolwiek powodu( miałem powody ograniczenia czasu), po prostu zaimplementuj

public void onBackPressed() {}

W twoim Activity i zrób tam jakiś back kod. nawet jeśli nie ma takiej metody na starszych urządzeniach, metoda ta zostanie wywołana przez nowsze.

Nie używaj metody commithallowingstateloss (), powinna być używana tylko w przypadkach, gdy jest w porządku, aby stan interfejsu użytkownika nieoczekiwanie zmienił się u użytkownika.

Https://developer.android.com/reference/android/app/FragmentTransaction.html#commitAllowingStateLoss()

Jeśli transakcja ma miejsce w ChildFragmentManager programu parentFragment, użyj parentFragment.isResume () na zewnątrz, aby sprawdzić zamiast tego.

if (parentFragment.isResume()) {
    DummyFragment dummyFragment = DummyFragment.newInstance();
    transaction = childFragmentManager.BeginTransaction();
    trans.Replace(Resource.Id.fragmentContainer, startFragment);
}

Miałem podobny problem, scenariusz był taki:

• Moja aktywność polega na dodawaniu / zastępowaniu fragmentów listy.
• każdy fragment listy ma odniesienie do aktywności, aby powiadomić aktywność, gdy element listy zostanie kliknięty (wzór obserwatora).
• każdy fragment listy wywołuje setRetainInstance(true);w swojej metodzie onCreate.

Metoda onCreate działania wyglądała następująco:

mMainFragment = (SelectionFragment) getSupportFragmentManager()
                .findFragmentByTag(MAIN_FRAGMENT_TAG);
        if (mMainFragment == null) {
            mMainFragment = new SelectionFragment();

            mMainFragment.setListAdapter(new ArrayAdapter<String>(this,
                    R.layout.item_main_menu, getResources().getStringArray(
                            R.array.main_menu)));
mMainFragment.setOnSelectionChangedListener(this);
            FragmentTransaction transaction = getSupportFragmentManager()
                    .beginTransaction();
            transaction.add(R.id.content, mMainFragment, MAIN_FRAGMENT_TAG);
            transaction.commit();
        }

Wyjątkiem był wrzucony, ponieważ zmienia się konfiguracja kiedy (urządzenie się obraca), zostaje utworzona aktywność, główny fragment jest pobierany z historii menedżera fragmentów i jednocześnie fragment ma już stare odniesienie do zniszczonej aktywności

Zmiana implementacji na to rozwiązała problem:

mMainFragment = (SelectionFragment) getSupportFragmentManager()
                .findFragmentByTag(MAIN_FRAGMENT_TAG);
        if (mMainFragment == null) {
            mMainFragment = new SelectionFragment();

            mMainFragment.setListAdapter(new ArrayAdapter<String>(this,
                    R.layout.item_main_menu, getResources().getStringArray(
                            R.array.main_menu)));
            FragmentTransaction transaction = getSupportFragmentManager()
                    .beginTransaction();
            transaction.add(R.id.content, mMainFragment, MAIN_FRAGMENT_TAG);
            transaction.commit();
        }
        mMainFragment.setOnSelectionChangedListener(this);

Musisz ustawić słuchaczy za każdym razem, gdy aktywność jest tworzona, aby uniknąć sytuacji, w której fragmenty mają odniesienia do starych zniszczone przypadki działalności.

Otrzymywałem ten wyjątek, gdy naciskałem przycisk Wstecz, aby anulować wybór intencji na mojej aktywności fragmentu mapy. Rozwiązałem to, zamieniając kod onResume (gdzie inicjalizowałem fragment) na OnStart () i aplikacja działa dobrze.Mam nadzieję, że to pomoże.

Myślę, że użycie transaction.commitAllowingStateLoss(); nie jest najlepszym rozwiązaniem. Ten wyjątek zostanie wyrzucony, gdy zmieni się konfiguracja aktywności i zostanie wywołany fragment onSavedInstanceState(), a następnie twoja metoda wywołania zwrotnego asynchronicznego spróbuje zatwierdzić fragment.

Prostym rozwiązaniem może być sprawdzenie czy aktywność zmienia konfigurację czy nie

Np. sprawdź isChangingConfigurations()

Tzn.

if(!isChangingConfigurations()) { //commit transaction. }

SprawdźTen link również

Jeśli robisz FragmentTransaction w onActivityResult co możesz zrobić możesz ustawić jakąś wartość logiczną wewnątrz onActivityResult następnie w onResume możesz zrobić FragmentTransaction na podstawie wartości logicznej. Proszę zapoznać się z poniższym kodem.

@Override
protected void onResume() {
    super.onResume;
    if(isSwitchFragment){
        isSwitchFragment=false;
        bottomNavigationView.getTabAt(POS_FEED).select();
    }
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (requestCode == FilterActivity.FILTER_REQUEST_EVENT && data != null) {
        isSwitchFragment=true;
    }
}

Prawdopodobnie najłagodniejszym i najprostszym rozwiązaniem, jakie znalazłem w moim przypadku, było uniknięcie wyrzucania obrażającego fragmentu ze stosu w odpowiedzi na wynik działania. Więc zmiana tego połączenia w moim onActivityResult():

popMyFragmentAndMoveOn();

Do tego:

new Handler(Looper.getMainLooper()).post(new Runnable() {
    public void run() {
        popMyFragmentAndMoveOn();
    }
}

Za każdym razem, gdy próbujesz załadować fragment do swojej aktywności, upewnij się, że aktywność jest w wznowieniu i nie będzie pauzować state.In stan pauzy może skończyć się utratą operacji commit, która została wykonana.

Możesz użyć transakcji.commitAllowingStateLoss () zamiast transaction.commit () to load fragment

Lub

Utwórz wartość logiczną i sprawdź, czy aktywność nie będzie działać w onpause

@Override
public void onResume() {
    super.onResume();
    mIsResumed = true;
}

@Override
public void onPause() {
    mIsResumed = false;
    super.onPause();
}

Następnie podczas wczytywania sprawdź fragment

if(mIsResumed){
//load the your fragment
}

W odniesieniu do @Anthonyeef świetna odpowiedź, oto przykładowy kod w Javie:

private boolean shouldShowFragmentInOnResume;

private void someMethodThatShowsTheFragment() {

    if (this.getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
        showFragment();
    } else {
        shouldShowFragmentInOnResume = true;
    }
}

private void showFragment() {
    //Your code here
}

@Override
protected void onResume() {
    super.onResume();

    if (shouldShowFragmentInOnResume) {
        shouldShowFragmentInOnResume = false;
        showFragment();
    }
}

Dodaj to do swojej aktywności

@Override
public void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    if (outState.isEmpty()) {
        // Work-around for a pre-Android 4.2 bug
        outState.putBoolean("bug:fix", true);
    }
}

Począwszy od biblioteki wsparcia w wersji 24.0.0 można wywołać metodę FragmentTransaction.commitNow(), która zatwierdzi tę transakcję synchronicznie zamiast wywoływać commit(), a następnie executePendingTransactions(). Jak Dokumentacja mówi to podejście jeszcze lepiej:

Wywołanie commitNow jest lepsze niż wywołanie commit (), po którym następuje executePendingTransactions (), ponieważ ta ostatnia będzie miała efekt uboczny próby zatwierdzenia wszystkich aktualnie oczekujących transakcji, niezależnie od tego, czy jest to pożądane zachowanie, czy nie.

Również doświadczyłem tego problemu i problem pojawia się za każdym razem, gdy zmienia się kontekst twojego FragmentActivity (np. zmienia się orientacja ekranu itp.). Więc najlepszą poprawką jest zaktualizowanie kontekstu z FragmentActivity.

Wyjątek rzuca się tutaj (w fragmencie):

@Override
public void onBackPressed() {
    if (!mFragments.getSupportFragmentManager().popBackStackImmediate()) {
        super.onBackPressed();
    }
}

W FragmentManager.popBackStatckImmediate()，FragmentManager.checkStateLoss() nazywa się po pierwsze. To jest przyczyna IllegalStateException. Zobacz implementację poniżej:

private void checkStateLoss() {
    if (mStateSaved) { // Boom!
        throw new IllegalStateException(
                "Can not perform this action after onSaveInstanceState");
    }
    if (mNoTransactionsBecause != null) {
        throw new IllegalStateException(
                "Can not perform this action inside of " + mNoTransactionsBecause);
    }
}

Rozwiązuję ten problem po prostu za pomocą flagi, aby zaznaczyć aktualny status aktywności. Oto moje rozwiązanie:

public class MainActivity extends AppCompatActivity {
    /**
     * A flag that marks whether current Activity has saved its instance state
     */
    private boolean mHasSaveInstanceState;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        mHasSaveInstanceState = true;
        super.onSaveInstanceState(outState);
    }

    @Override
    protected void onResume() {
        super.onResume();
        mHasSaveInstanceState = false;
    }

    @Override
    public void onBackPressed() {
        if (!mHasSaveInstanceState) {
            // avoid FragmentManager.checkStateLoss()'s throwing IllegalStateException
            super.onBackPressed();
        }
    }

}

Skończyłem z utworzeniem fragmentu bazowego i sprawiłem, że wszystkie fragmenty w mojej aplikacji rozszerzają go

public class BaseFragment extends Fragment {

    private boolean mStateSaved;

    @CallSuper
    @Override
    public void onSaveInstanceState(Bundle outState) {
        mStateSaved = true;
        super.onSaveInstanceState(outState);
    }

    /**
     * Version of {@link #show(FragmentManager, String)} that no-ops when an IllegalStateException
     * would otherwise occur.
     */
    public void showAllowingStateLoss(FragmentManager manager, String tag) {
        // API 26 added this convenient method
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            if (manager.isStateSaved()) {
                return;
            }
        }

        if (mStateSaved) {
            return;
        }

        show(manager, tag);
    }
}

Wtedy gdy próbuję pokazać fragment używam showAllowingStateLoss zamiast show

Tak:

MyFragment.newInstance()
.showAllowingStateLoss(getFragmentManager(), MY_FRAGMENT.TAG);

Doszedłem do tego rozwiązania z tego PR: https://github.com/googlesamples/easypermissions/pull/170/files

Inne możliwe obejście, które nie jestem pewien, czy pomaga we wszystkich przypadkach (pochodzenie Proszę.) :

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
        final View rootView = findViewById(android.R.id.content);
        if (rootView != null) {
            rootView.cancelPendingInputEvents();
        }
    }
}

Wiem, że jest akceptowana odpowiedź przez @Ovidiu Latcu, ale po jakimś czasie błąd nadal utrzymuje się.

@Override
protected void onSaveInstanceState(Bundle outState) {
     //No call for super(). Bug on API Level > 11.
}

Crashlytics wciąż wysyła mi ten dziwny komunikat o błędzie.

Jednak błąd występujący teraz tylko w wersji 7+ (Nugat) Moją poprawką było użycie commit () zamiast commit() w fragmentTransaction.

Ten post {[11] } jest pomocny dla commit callowingstateloss () i nigdy więcej nie miał problemu z fragmentem.

Podsumowując, zaakceptowana odpowiedź tutaj może działać na wersjach Pre Nougat android.

Miałem dokładnie ten sam problem. Stało się to z powodu zniszczenia poprzedniej działalności. po zakończeniu poprzedniej działalności został zniszczony. I put it base activity (WRONG)

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    SpinnerCustom2.setFragmentManager(getSupportFragmentManager());
    onCreateDrawerActivity(savedInstanceState);
}

Włożyłem go do onstartu to było słuszne

@Override
protected void onStart() {
    super.onStart();
    SpinnerCustom2.setFragmentManager(getSupportFragmentManager());

}

Aby ominąć ten problem, możemy użyć komponentu architektury nawigacji , który został wprowadzony w Google I/O 2018. Komponent Architektura nawigacji upraszcza implementację nawigacji w aplikacji na Androida.

Dzięki Uprzejmości: rozwiązanie dla IllegalStateException

Ten problem denerwował mnie przez długi czas, ale na szczęście przyszedłem z konkretnym rozwiązaniem. Szczegółowe wyjaśnienie tego jest tutaj .

Użycie commitAllowStateloss() może zapobiec temu wyjątkowi, ale prowadzi do interfejsu użytkownika irregularities.So far zrozumieliśmy, że IllegalStateException występuje, gdy próbujemy zatwierdzić fragment po utracie stanu aktywności - więc powinniśmy po prostu opóźnić transakcja aż do stanu restored.It można po prostu zrobić tak

Zadeklaruj dwie prywatne zmienne logiczne

 public class MainActivity extends AppCompatActivity {

    //Boolean variable to mark if the transaction is safe
    private boolean isTransactionSafe;

    //Boolean variable to mark if there is any transaction pending
    private boolean isTransactionPending;

Teraz w onpostresume() i onPause ustawiamy i wyłączamy naszą boolowską zmienną isTransactionSafe. Chodzi o to, aby oznaczyć trasnsaction bezpiecznie tylko wtedy, gdy aktywność jest na pierwszym planie, więc nie ma szans na stateloss.

/*
onPostResume is called only when the activity's state is completely restored. In this we will
set our boolean variable to true. Indicating that transaction is safe now
 */
public void onPostResume(){
    super.onPostResume();
    isTransactionSafe=true;
}
/*
onPause is called just before the activity moves to background and also before onSaveInstanceState. In this
we will mark the transaction as unsafe
 */

public void onPause(){
    super.onPause();
    isTransactionSafe=false;

}

private void commitFragment(){
    if(isTransactionSafe) {
        MyFragment myFragment = new MyFragment();
        FragmentManager fragmentManager = getFragmentManager();
        FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
        fragmentTransaction.add(R.id.frame, myFragment);
        fragmentTransaction.commit();
    }
}

- to, co zrobiliśmy do tej pory, uratuje przed nielegalnym przyjęciem, ale nasze transakcje zostaną utracone, jeśli zostaną wykonane po przeniesieniu aktywności do tła, coś w rodzaju commit callowstateloss (). Aby w tym pomóc, mamy zmienną boolean isTransactionPending

public void onPostResume(){
   super.onPostResume();
   isTransactionSafe=true;
/* Here after the activity is restored we check if there is any transaction pending from
the last restoration
*/
   if (isTransactionPending) {
      commitFragment();
   }
}


private void commitFragment(){

 if(isTransactionSafe) {
     MyFragment myFragment = new MyFragment();
     FragmentManager fragmentManager = getFragmentManager();
     FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
     fragmentTransaction.add(R.id.frame, myFragment);
     fragmentTransaction.commit();
     isTransactionPending=false;
 }else {
     /*
     If any transaction is not done because the activity is in background. We set the
     isTransactionPending variable to true so that we can pick this up when we come back to
foreground
     */
     isTransactionPending=true;
 }
}