On s'attendait à ce que l'adaptateur soit `` frais '' lors de la restauration de l'état

Mon problème était donc que je créais mon FragmentStateAdapter dans mon champ de classe Fragment où il n'a été créé qu'une seule fois. Ainsi, lorsque mon onCreateView a été appelé une deuxième fois, j'ai eu ce problème. Si je recrée l'adaptateur à chaque appel onCreateView, cela semble fonctionner.

J'ai rencontré le même problème avec ViewPager2. Après de nombreux efforts pour tester différentes méthodes, cela a fonctionné pour moi:

public void onResumeOfYourFragment() {
    viewPager2.setAdapter(yourAdapter);
}

Lorsque vous revenez au fragment à nouveau:

public void onExitOfYourFragment() {
    viewPager2.setAdapter(null);
}

java.lang.IllegalStateException: Expected the adapter to be 'fresh' while restoring state. également cette java.lang.IllegalStateException: Expected the adapter to be 'fresh' while restoring state. je java.lang.IllegalStateException: Expected the adapter to be 'fresh' while restoring state. lors de l'utilisation de ViewPager2 dans un fragment.

Il semble que le problème soit dû au fait que mViewPager2.setAdapter(mFragmentStateAdapter); dans ma méthode onCreateView () .

Je l'ai corrigé en déplaçant mViewPager2.setAdapter(mMyFragmentStateAdapter); à ma méthode onResume () .

J'ai résolu ce problème en testant s'il est égal à null

if(recyclerView.adapter == null) {recyclerView.adapter = myAdapter}

J'ai eu du mal avec cela et aucune des réponses précédentes n'a aidé.

Cela peut ne pas fonctionner pour toutes les situations possibles, mais dans mon cas, les fragments contenant ViewPager2 ont été corrigés et peu nombreux, et j'ai résolu ce problème en effectuant un changement de fragment avec les méthodes show() et hide() FragmentTransaction , au lieu de replace() couramment recommandé pour ce. Appliquez show() au fragment actif et hide() à tous les autres. Cela évite les opérations telles que la recréation de vues et la restauration de l'état qui déclenchent le problème.

il peut être corrigé par viewPager2.isSaveEnabled = false

Cet adaptateur / vue est utile en remplacement de FragmentStatePagerAdapter.

Si ce que vous cherchez est de préserver les fragments lors de la rentrée de Backstack, cela serait extrêmement difficile à réaliser avec cet adaptateur.

L'équipe a mis de nombreuses pauses en place pour éviter cela, Dieu seul sait pourquoi ...

Ils auraient pu utiliser un observateur de cycle de vie auto-détachant, dont la capacité était déjà prévue dans son code, mais nulle part dans l'architecture Android n'utilise cette capacité ...

Ils auraient dû utiliser ce composant inachevé pour écouter le cycle de vie global des Fragments au lieu de son viewLifeCycle, à partir de là, on peut mettre à l'échelle l'écoute du Fragment au viewLifeCycle. (attacher / détacher l'observateur viewLifeCycle ON_START / ON_STOP)

Deuxièmement ... même si cela est fait, le fait que le viewPager lui-même soit construit sur un recyclerView rend extrêmement difficile la gestion de ce que vous attendez du comportement d'un Fragment, qui est un état de conservation, une instanciation unique, et un cycle de vie bien défini (destruction contrôlable / attendue).

Cet adaptateur est contradictoire dans sa fonctionnalité, il vérifie si le viewPager a déjà été alimenté en Fragments, tout en nécessitant toujours un adaptateur «frais» lors de la réentrée.

Il préserve les fragments à la sortie du backStack, tout en s'attendant à les recréer tous lors de la réentrée.

Les pauses sur place pour empêcher un adaptateur instancié par champ, en supposant que toutes les autres variables sont déjà prises en compte pour une gestion correcte de viewLifeCycle (enregistrement / désinscription et définition et réinitialisation des paramètres) sont:

public FragmentStateAdapter(@NonNull FragmentManager fragmentManager,
        @NonNull Lifecycle lifecycle) {
    mFragmentManager = fragmentManager;
    mLifecycle = lifecycle;
    super.setHasStableIds(true);
}

Deuxième pause:

private void scheduleGracePeriodEnd() {
    final Handler handler = new Handler(Looper.getMainLooper());
    final Runnable runnable = new Runnable() {
        @Override
        public void run() {
            mIsInGracePeriod = false;
            gcFragments(); // good opportunity to GC
        }
    };

    mLifecycle.addObserver(new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            if (event == Lifecycle.Event.ON_DESTROY) {
                handler.removeCallbacks(runnable);
                source.getLifecycle().removeObserver(this);
            }
        }
    });

    handler.postDelayed(runnable, GRACE_WINDOW_TIME_MS);
}

où mFragmentMaxLifecycleEnforcer doit être == null lors de la réentrance ou il lève une exception dans checkArgument ().

Troisièmement: un ramasse-miettes de fragments mis en place lors de la réentrée ( vers la vue, à partir de la pile arrière) qui est post-retardé à 10 secondes qui tente de détruire les fragments hors écran, provoquant des fuites de mémoire sur toutes les pages hors écran car il tue leurs FragmentManagers respectifs qui contrôlent leur Cycle de la vie.

@CallSuper
@Override
public void onAttachedToRecyclerView(@NonNull RecyclerView recyclerView) {
    checkArgument(mFragmentMaxLifecycleEnforcer == null);
    mFragmentMaxLifecycleEnforcer = new FragmentMaxLifecycleEnforcer();
    mFragmentMaxLifecycleEnforcer.register(recyclerView);
}

Et tous à cause de son principal coupable: le constructeur:

@Override
    public final void restoreState(@NonNull Parcelable savedState) {
        if (!mSavedStates.isEmpty() || !mFragments.isEmpty()) {
            throw new IllegalStateException(
                    "Expected the adapter to be 'fresh' while restoring state.");
        }
.....
}