J'ai trouvé de nombreux exemples d'une question similaire sur SO, mais aucune réponse ne répond malheureusement à mes exigences.
J'ai différentes dispositions pour le portrait et le paysage et j'utilise la pile arrière, ce qui m'empêche à la fois d'utiliser setRetainState()
et des astuces en utilisant des routines de changement de configuration.
J'affiche certaines informations à l'utilisateur dans TextViews, qui ne sont pas enregistrées dans le gestionnaire par défaut. Lors de la rédaction de ma candidature en utilisant uniquement des activités, les éléments suivants ont bien fonctionné:
TextView vstup;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.whatever);
vstup = (TextView)findViewById(R.id.whatever);
/* (...) */
}
@Override
public void onSaveInstanceState(Bundle state) {
super.onSaveInstanceState(state);
state.putCharSequence(App.VSTUP, vstup.getText());
}
@Override
public void onRestoreInstanceState(Bundle state) {
super.onRestoreInstanceState(state);
vstup.setText(state.getCharSequence(App.VSTUP));
}
Avec Fragment
s, cela ne fonctionne que dans des situations très spécifiques. Plus précisément, ce qui casse horriblement est de remplacer un fragment, de le placer dans la pile arrière, puis de faire pivoter l'écran pendant que le nouveau fragment est affiché. D'après ce que j'ai compris, l'ancien fragment ne reçoit pas d'appel à onSaveInstanceState()
lorsqu'il est remplacé mais reste en quelque sorte lié à la Activity
et cette méthode est appelée plus tard lorsqu'elle View
n'existe plus, donc je cherche l'un de mes TextView
résultats dans a NullPointerException
.
De plus, j'ai trouvé que garder la référence à mon TextViews
n'est pas une bonne idée avec Fragment
s, même si ça allait avec Activity
. Dans ce cas, onSaveInstanceState()
enregistre réellement l'état mais le problème réapparaît si je fais pivoter l'écran deux fois lorsque le fragment est masqué, car il onCreateView()
n'est pas appelé dans la nouvelle instance.
Je pensais que de sauver l'état onDestroyView()
dans un certain Bundle
élément de membre de classe de type (il est en fait plus de données, pas seulement un TextView
) et les économies que dans , onSaveInstanceState()
mais il y a d' autres inconvénients. Principalement, si le fragment est actuellement affiché, l'ordre d'appeler les deux fonctions est inversé, donc je devrais tenir compte de deux situations différentes. Il doit y avoir une solution plus propre et correcte!