IllegalStateException: Diese Aktion kann nach onSaveInstanceState mit ViewPager nicht ausgeführt werden

Gibt es viele ähnliche Probleme mit einer ähnlichen Fehlermeldung. Überprüfen Sie die zweite Zeile von diesem bestimmten stack-trace. Diese Ausnahme ist speziell im Zusammenhang mit dem Aufruf FragmentManagerImpl.popBackStackImmediate.

Diese Methode aufrufen, wie popBackStack wird immer scheitern mit IllegalArgumentException wenn der session state ist schon gespeichert. Überprüfen Sie die Quelle. Es gibt nichts, was Sie tun können, um dies zu stoppen Ausnahme ausgelöst wird.

• Entfernen der Aufruf super.onSaveInstanceState wird nicht helfen.
• Erstellen des Fragments mit commitAllowingStateLoss wird nicht helfen.

Hier, wie ich beobachtet das problem:

• Es gibt ein Formular mit einem submit-button.
• Wenn die Schaltfläche geklickt wird, wird ein dialog erstellt, und einen asynchronen Prozess beginnt.
• Der Benutzer auf die home-Taste, bevor der Vorgang abgeschlossen ist - onSaveInstanceState genannt wird.
• Der Prozess abgeschlossen ist, wird ein callback gemacht und popBackStackImmediate versucht wird.
• IllegalStateException geworfen wird.

Hier ist, was ich Tat, um es zu lösen:

Da es nicht möglich ist, zu vermeiden, die IllegalStateException im callback, fangen und ignorieren es.

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

Dies ist genug, um die app abstürzt. Aber jetzt wird der Benutzer wiederherstellen Sie die app und sehen Sie, dass die Schaltfläche, die Sie dachten, Sie gedrückt nicht gedrückt wurde (Sie denken). Die form fragment wird noch zeigen!

Um dies zu beheben, wenn das Dialogfeld erstellt wird, stellen Sie einen Status angeben, der Prozess hat begonnen.

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

Und speichern Sie diesen Zustand in dem bundle.

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

Vergessen Sie nicht, laden es wieder in onViewCreated

Dann, bei der Wiederaufnahme, Wiederherstellung der Fragmente, wenn unterbreiten, wurde bereits versucht. Dies verhindert, dass der Benutzer kommt zurück zu dem, was scheint wie eine un-vorgelegten form.

@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;
    }
}

InformationsquelleAutor der Antwort Synesso

Hier ist eine andere Lösung für dieses problem.

Sich für eine private member-variable können Sie die zurückgegebenen Daten als eine Absicht, die dann bearbeitet werden, nachdem super.onResume();

Etwa 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;
    }
}

InformationsquelleAutor der Antwort Jed

VORSICHT, mit transaction.commitAllowingStateLoss() führen könnte eine schlechte Erfahrung für den Benutzer. Für mehr Informationen, warum diese Ausnahme wird geworfen, siehe dieser Beitrag.

InformationsquelleAutor der Antwort Eric Brandwein

Es ist Oktober 2017, und Google lässt Android-Support-Bibliothek, mit der neue Dinge zu nennen-Lifecycle-Komponente. Es bietet eine neue Idee für dieses 'nicht durchführen Kann diese Aktion nach onSaveInstanceState" problem.

Kurz:

• Verwenden der lifecycle-Komponente, um zu bestimmen, wenn es die richtige Zeit für knallen bis Ihr das fragment.

Längere version mit erklären:

• warum dieses problem kommen?

  Es ist, weil Sie versuchen, zu verwenden FragmentManager von Ihrer Aktivität(die wird halten Sie Ihre fragment nehme ich an?) ein commit für eine Transaktion für Sie fragment. In der Regel würde dies so Aussehen, wie Sie versuchen zu tun, einige Transaktion für ein bis kommenden fragment, während die host-Aktivität bereits call savedInstanceState - Methode(user kann passieren, berühren Sie die home-Taste, so dass die Aktivität ruft onStop(), in meinem Fall ist es der Grund)

  In der Regel dieses problem sollte nicht passieren-wir versuchen immer zu laden-fragment in die Aktivität, ganz am Anfang, wie die onCreate() Methode ist ein perfekter Ort für diese. Aber manchmal passieren, vor allem, wenn Sie sich nicht entscheiden kann, welches fragment Sie laden Sie zu Aktivität, oder Sie versuchen zu laden, fragment aus einem AsyncTask block(oder alles dauert ein wenig Zeit). Die Zeit, bevor das fragment Transaktion wirklich passiert, aber nach der Aktivität onCreate() Methode, der Benutzer kann nichts tun. Wenn Benutzer drücken Sie die home-Taste, die Auslöser der Aktivität onSavedInstanceState() Methode, es wäre ein can not perform this action Absturz.

  Wenn jemand will, um zu sehen, tiefer in dieses Problem, ich schlage vor, Sie nehmen einen Blick auf dieses blog post. Es schaut tief in die source-code-Ebene und erklären einem viel über es. Auch gibt es den Grund, dass Sie sollten nicht die commitAllowingStateLoss() Methode zur Umgehung dieses crash(Vertrauen Sie mir, es bietet nichts gutes für Ihren code)

• Wie man dieses Problem beheben?

  • Sollte ich commitAllowingStateLoss() Methode zum laden von fragment? NÖ, sollte Sie nicht;

  • Soll ich überschreiben onSaveInstanceState Methode, ignorieren super Methode drin? NÖ, sollte Sie nicht;

  • Sollte ich die magischen isFinishing im inneren Tätigkeit, um zu prüfen, ob die host-Aktivität ist im richtigen moment für fragment-Transaktion? Ja diese sieht aus wie die richtige Weise zu tun.

• Nehmen Sie einen Blick an, was Lebenszyklus Komponente tun können.

  Im Grunde, Google macht einige Umsetzung innerhalb der AppCompatActivity Klasse(und einige andere Basisklasse, die Sie sollten in Ihrem Projekt verwenden), das macht es einfacher zu ermitteln der aktuellen Lebenszyklus-Status. Werfen Sie einen Blick zurück zu unserem problem: warum sollte dieses problem auftreten? Es ist, weil wir etwas tun, am falschen timing. So versuchen wir, es nicht zu tun, und das problem wird verschwunden sein.

  Code ich ein wenig für mein eigenes Projekt, hier ist, was ich Tue, mit LifeCycle. Ich code in Kotlin.

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()
    }

Als ich oben zeige. Ich werde das überprüfen der Lebenszyklus-Status der host-Aktivität. Mit Lifecycle-Komponente innerhalb der support-Bibliothek, das könnte genauer sein. Der code lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED) bedeutet, wenn der aktuelle Zustand mindestens onResume, nicht später als? Das macht sicher, dass meine Methode nicht ausführen, während einige andere Leben Zustand(wie onStop).

• Ist alles getan?

  Natürlich nicht. Der code, den ich gezeigt habe, sagt eine neue Weise zu verhindern Anwendung abstürzt. Aber wenn Sie es tun, gehen Sie auf den Zustand der onStop ist, dass der code nicht Dinge tun, und so zeigen, dass nichts auf Ihrem Bildschirm. Wenn der Benutzer zurück zu der Anwendung, sehen Sie eine leere Leinwand, die leere host-Aktivität zeigt keine Fragmente an alle. Es ist schlechte Erfahrung(ja, ein bisschen besser als ein Absturz).

  So, hier ich wünschte, es könnte etwas schöner: die app wird nicht Abstürzen, wenn es um Leben Staat später als onResume der transaction-Methode Leben ist-Zustand bewusst; außerdem ist die Aktivität, die versuchen weiterhin zu fertigen, das fragment Transaktion Aktion, nachdem der Benutzer kommen zurück zu unserer app.

  Füge ich etwas mehr zu dieser Methode:

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()
        }
    }
}

Ich behaupte, eine Liste innerhalb dieser dispatcher Klasse, diese lagern fragment keine chance haben, um die Transaktion abzuschließen action. Und wenn der Benutzer wieder aus der home-Bildschirm und gefunden es ist immer noch fragment warten, gestartet zu werden, es geht um die resume() Methode unter der @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) annotation. Jetzt denke ich, es sollte funktionieren wie ich es erwartet hatte.

InformationsquelleAutor der Antwort Anthonyeef

Nicht verwenden commitAllowingStateLoss(), es sollte nur verwendet werden, für Fälle, in denen es okay ist für den UI-Status zu ändern, der unerwartet auf den Benutzer.

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

Verwenden Sie stattdessen wenn (fragment.isResume()) check außerhalb der operation, die Sie trafen diese IllegalStateException "Kann nicht führen Sie diese Aktion nach onSaveInstanceState"

InformationsquelleAutor der Antwort Chandler

Ich denke, mit transaction.commitAllowingStateLoss(); ist nicht die beste Lösung.
Diese Ausnahme wird geworfen, wenn die Aktivität der Konfiguration geändert und das fragment onSavedInstanceState() aufgerufen wird und danach die asynchrone callback-Methode versucht, einen commit-fragment.

Einfache Lösung könnte sein, zu überprüfen, ob Aktivität ist die änderung der Konfiguration oder nicht

z.B. Scheck isChangingConfigurations()

d.h.

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

Kasse diese link als auch

InformationsquelleAutor der Antwort Amol Desai

Immer, wenn Sie versuchen zu laden, ein fragment, in Ihrer Aktivität stellen Sie sicher, dass die Aktivität im Lebenslauf und nicht auf pause Stand.Im pause-Modus, können Sie am Ende verlieren commit-operation, die getan wird.

Können Sie mit der Transaktion.commitAllowingStateLoss() anstelle von Transaktion.commit() zum laden von fragment

oder

Erstellen Sie eine Boolesche und überprüfen, ob die Aktivität ist nicht zu onpause

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

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

dann beim laden von fragment-check

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

InformationsquelleAutor der Antwort Anonymous

Fügen Sie diese in Ihre Tätigkeit

@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);
    }
}

InformationsquelleAutor der Antwort Balchander V R

Ich habe auch erlebt, dieses Problem und das problem jedes mal Auftritt, wenn der Kontext Ihrer FragmentActivity verändert wird (z.B. Bildschirm-Orientierung geändert wird, etc.). Also ist die beste Lösung für Sie ist zu aktualisieren Kontext von Ihrem FragmentActivity.

InformationsquelleAutor der Antwort Adam

Landete ich mit einem Basis-fragment und machen Sie alle Bruchstücke in meine app erweitern

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);
    }
}

Dann, wenn ich zu zeigen versuche ein fragment benutze ich showAllowingStateLoss statt show

wie diese:

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

Kam ich zu dieser Lösung aus diesem PR: https://github.com/googlesamples/easypermissions/pull/170/files

InformationsquelleAutor der Antwort Ahmad El-Melegy

Ich weiß, es ist eine akzeptierte Antwort von @Ovidiu Latcu aber nach einiger Zeit, die Fehler bestehen immer noch.

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

Crashlytics immer noch senden Sie mir diese komische Fehlermeldung.

Jedoch Fehler jetzt auftreten nur auf version 7+ (Nougat)
Mein fix war zu verwenden commitAllowingStateLoss() anstatt von commit() auf das fragmentTransaction.

Diese post ist hilfreich für commitAllowingStateLoss() und hatte nie ein Problem fragment immer wieder.

Um es zusammenzufassen, die akzeptierte Antwort hier könnte die Arbeit an pre-Nougat android-Versionen.

Diese retten könnte jemand ein paar Stunden Suche.
glücklich Codierungen. <3 cheers

InformationsquelleAutor der Antwort ralphgabb