Android: onSaveInstanceState n’est pas appelé depuis l’activité

Notez que onRestoreInstanceState() est appelé lorsque l’activité est recréée mais uniquement si:

il a été tué par le système d’exploitation . “Une telle situation se produit lorsque:

• l’orientation de l’appareil change (votre activité est détruite et recréée)
• Il y a une autre activité devant vous et, à un moment donné, le système d’exploitation tue votre activité afin de libérer de la mémoire (par exemple). La prochaine fois que vous commencerez votre activité, on onRestoreInstanceState() . ”

Donc, si vous êtes dans votre activité et que vous appuyez sur le bouton Précédent de l’appareil, votre activité est finish() et la prochaine fois que vous démarrez votre application, elle est redémarrée (cela ressemble à une recréation, non?) temps sans état enregistré parce que vous l’avez intentionnellement quitté lorsque vous appuyez sur le bouton Retour.

J’ai eu une situation similaire. C’était clairement un bug de dev. J’ai remplacé la mauvaise méthode:

 public void onSaveInstanceState(Bundle outState, PersistableBundle outPersistentState) 

Au lieu de cela un correct :

 protected void onSaveInstanceState(Bundle outState) 

Voir la doc ici: http://developer.android.com/reference/android/app/Activity.html

Notez qu’il est important de sauvegarder les données persistantes dans onPause() au lieu de onSaveInstanceState(Bundle) car ce dernier ne fait pas partie des rappels du cycle de vie, il ne sera donc pas appelé dans toutes les situations décrites dans sa documentation.

La documentation de la méthode onSaveInstanceState dit:

Ne confondez pas cette méthode avec les rappels de cycle de vie d’activité tels que onPause() , qui est toujours appelé lorsqu’une activité est placée en arrière-plan ou en cours de destruction, ou onStop() appelé avant la destruction. Lorsque on onPause() et onStop() et non cette méthode, l’utilisateur retourne de l’activité B à l’activité A: il n’est pas nécessaire d’appeler onSaveInstanceState(Bundle) sur B car cette instance particulière ne sera jamais restaurée , le système évite de l’appeler. Un exemple où onPause() est appelée et non onSaveInstanceState(Bundle) est lorsque l’activité B est lancée devant l’activité A: le système peut éviter d’appeler onSaveInstanceState(Bundle) sur l’activité A si elle n’est pas onSaveInstanceState(Bundle) l’état de l’interface utilisateur de A restra intact.

essaye ça:

 @Override public void onPause(){ System.out.println("Saving webview state"); Log.d(TAG, "In onsave"); wv.saveState(outState); super.onPause(); } and @Override public void onResume(){ //restore webview } 

Je ne sais pas quel est le but de cette déclaration, mais essayez ceci et voyez ce qui se passe.

Finalement, vous devrez écrire le back / history dans le stockage persistant. Dans le cas où le périphérique est arrêté à titre d’exemple, tout en évitant un exemple artificiel (à mon avis) où vous appelez onSaveInstanceState dans onPause (ce que vous devrez faire pour obtenir le bundle que vous voulez transmettre à onRestoreInstanceState . peut ensuite passer dans restoreState ).

Par conséquent, en plus de reconsidérer votre conception (si l’utilisateur ferme votre application et que vous ne créez pas de navigateur, souhaite-t-il conserver le même historique?), Vous devez rechercher les SharedPreferences et leur utilisation.

Malheureusement, vous ne pouvez pas mettre un bundle dans les préférences partagées, et je ne vous recommanderais pas non plus d’écrire le bundle via Parcelable (il ne s’agit que d’un IPC, pas d’un stockage persistant). Mais ce que vous pouvez faire, c’est stocker toutes les primitives stockées dans le bundle. Cela pourrait aussi être artificiel, mais il me semble que c’est le seul moyen d’obtenir un stockage permanent.

Et puis reconstruisez votre bundle via les primitives stockées dans SharedPreferences et transmettez-le dans restoreState() . Vous pouvez vérifier le code source d’Android pour voir ce webView.saveState() fait réellement webView.saveState() j’ai regardé le code 2.1 et il semble écrire un int, un object sérialisable, puis un autre bundle pour le certificate SSL. est juste quatre entiers). Au sumt de ma tête, je voudrais juste écrire toutes les primitives que vous pouvez, puis stocker l’emplacement (chaîne) du fichier local que vous écrivez également les données sérialisées.

Même si vous avez une collection ordonnée de la liste BackForward entière, je ne sais pas comment la traduire dans goBack() et goForward() utilisant ces valeurs (il existe une méthode protégée impliquée dans l’ajout d’éléments à la liste, mais vous pouvez ne pas y accéder). Sauf si vous utilisez restoreState() , c’est pourquoi nous allons tout reconstruire correctement.

Sérieusement, à moins que mes compétences de recherche soient abyssales (tout à fait possible), stocker l’historique de WebView dans des endroits au-delà desquels saveInstanceState/restoreInstanceState peut faire votre travail pour vous ne semble pas être un problème. C’est-à-dire que peu de personnes tentent de conserver l’historique WebView lorsque l’utilisateur ferme explicitement son application. Vous devez donc vous demander pourquoi cela se passe?

Des excuses s’il existe un moyen très simple de stocker ces informations de manière persistante et de les recharger dans un WebView btw!