2013-03-05 2 views
7

Aujourd'hui, j'ai remarqué un comportement étrange dans mon application.OnActivityCreated() de Fragment est appelé après onDestroy() de l'activité

Cela se produit lorsque j'arrête mon application à l'aide de la vue Appareils d'Eclipse. Quelqu'un peut-il l'expliquer?

Pourquoi onActivityCreated() de Fragment est-il appelé même lorsque Activity est déjà détruit? MyHomeActivity contient deux Fragment s et un journal similaire est généré pour les deux.

Ici, je colle des bûches pour un Fragment. NullPointerException est un problème secondaire.

Je suis surpris de savoir pourquoi onActivityCreated() est appelée lorsque la pile d'appels a été lancée à partir de onDestroy() de MyHomeActivity?

03-05 12:31:21.414: W/System.err(5638): java.lang.NullPointerException 
03-05 12:31:21.421: W/System.err(5638):  at **MyListViewFrag.onActivityCreated**(BuddyListViewFrag.java:85) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.Fragment.performActivityCreated(Fragment.java:1468) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:931) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1088) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1070) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentManagerImpl.dispatchReallyStop(FragmentManager.java:1888) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentActivity.onReallyStop(FragmentActivity.java:787) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentActivity.doReallyStop(FragmentActivity.java:764) 
03-05 12:31:21.421: W/System.err(5638):  at android.support.v4.app.FragmentActivity.onDestroy(FragmentActivity.java:322) 
03-05 12:31:21.421: W/System.err(5638):  at MyFragmentActivity.onDestroy(RbrFragmentActivity.java:57) 
03-05 12:31:21.421: W/System.err(5638):  at **MyHomeActivity.onDestroy**(MyHomeActivity.java:254) 
03-05 12:31:21.421: W/System.err(5638):  at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:2663) 
03-05 12:31:21.421: W/System.err(5638):  at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:2694) 
03-05 12:31:21.421: W/System.err(5638):  at android.app.ActivityThread.access$2100(ActivityThread.java:117) 
03-05 12:31:21.421: W/System.err(5638):  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:968) 
03-05 12:31:21.421: W/System.err(5638):  at android.os.Handler.dispatchMessage(Handler.java:99) 
03-05 12:31:21.421: W/System.err(5638):  at android.os.Looper.loop(Looper.java:130) 
03-05 12:31:21.421: W/System.err(5638):  at android.app.ActivityThread.main(ActivityThread.java:3687) 
03-05 12:31:21.429: W/System.err(5638):  at java.lang.reflect.Method.invokeNative(Native Method) 
03-05 12:31:21.429: W/System.err(5638):  at java.lang.reflect.Method.invoke(Method.java:507) 
03-05 12:31:21.429: W/System.err(5638):  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867) 
03-05 12:31:21.429: W/System.err(5638):  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625) 
03-05 12:31:21.429: W/System.err(5638):  at dalvik.system.NativeStart.main(Native Method) 

J'utilise la bibliothèque de soutien pour fournir Fragment s aux dispositifs de pré-HoneyComb, si cela fait une différence.

+0

Vous semblez surcharger le rappel 'onDestroy'. Que faites vous ici? – Luksprog

+0

rien que d'appeler super.OnDestroy() – aProgrammer

+0

Je viens de remarquer ce même comportement sur mon émulateur 4.2. Avez-vous trouvé plus d'infos? –

Répondre

14

Après quelques essais et l'examen FragmentManager.moveToState, je crois que lorsque le Fragment est géré par un FragmentPagerAdapter, il est inévitable qu'un Fragment qui était auparavant fusionné en savedState (dans le cadre du processus d'arrêt de l'application avant de tuer la processus à partir de l'onglet DDMS dans eclipse), doit d'abord être "créé" (dans la terminologie de FragmentManager) avant de pouvoir être détruit.

Cela peut en fait être une conséquence non intentionnelle du processus de reconstruction des fragments à partir de l'état enregistré. Lorsque le FragmentActivity est en cours d'exécution onCreate et finish() est appelé, l'intention est que le FragmentActivity arrête la configuration et quitte. L'expérience visuelle est que cela se produit, mais il semble que le FragmentManager le prend sur lui-même pour continuer le cycle de vie pour Fragment s précédemment, albiet avec quelques raccourcis. Ce processus semble exécuter les méthodes du cycle de vie jusqu'à onActivityCreated, puis exécuter onDestroy et onDetach, en ignorant les intermédiaires.

La meilleure façon de gérer cela semble être de résoudre les problèmes secondaires (dans ce cas, votre NPE) causés par ce démarrage. Il semble qu'il y aurait de la place pour optimiser ceci du cycle de vie Fragment, mais avec la bibliothèque de support r12, la situation semble être une conséquence de la conception.

+0

J'ai également remarqué exactement le même comportement. Cependant j'attendais une réponse qui puisse mettre tous les points ensemble. Merci beaucoup cela peut être très utile pour les autres et oui, j'ai déjà résolu que NPE et cela a résolu ce problème étrange. Ce n'est certainement pas prévu des gars Android ... – aProgrammer

+0

Merci pour cette explication. Quelques années plus tard, cette logique semble toujours être la même, malheureusement. –

Questions connexes