onActivityResult () & onResume ()

Quelqu’un pourrait-il me dire qui est appelé en premier, est-ce onActivityResult() ou est-il onResume() ? Exemple:

Activité A appelle startActivityForResult() pour démarrer l’activité B. B exécute, termine et renvoie un résultat à A, mais quelle méthode de A est appelée en premier, onActivityResult() ou onResume() ?

Je sais que quelqu’un a déjà répondu à cette question en se référant aux documents d’activité , mais je ne pouvais pas y trouver moi-même.

Premier appel à onActivityResult() puis onResume() .

Citation de docs:

protected void onActivityResult (int requestCode, int resultCode, Intent data)

Depuis: API Niveau 1 Appelé lorsqu’une activité que vous avez lancée se termine, vous donnant le requestCode avec lequel vous l’avez démarré, le resultCode renvoyé et toutes les données supplémentaires qu’il contient. Le resultCode sera RESULT_CANCELED si l’activité l’a explicitement renvoyée, n’a renvoyé aucun résultat ou s’est bloqué pendant son fonctionnement. Vous recevrez cet appel immédiatement avant onResume () lorsque votre activité redémarre.

Comme d’autres l’ont signalé, onActivityResult () est appelé avant onResume () au redémarrage de votre activité.

Diane Hackborn explique que onActivityResult () est appelée avant onResume () pour permettre la réception et la disponibilité de tout ce qui pourrait affecter l’interface utilisateur avant de mettre à jour l’interface utilisateur (probablement pour éviter une double mise à jour – une fois dans onResume () sans result, puis dans onActivityResult (), en ajoutant le résultat renvoyé).

https://groups.google.com/forum/?fromgroups=#!topic/android-developers/3epIML7fjGw

Une conséquence de ceci est que toutes les initialisations que vous auriez pu décider d’exécuter uniquement dans onResume () (par exemple, les initialisations de données provenant d’une source externe dont vous avez besoin) plutôt que dans onCreate () ne seraient pas initialisées. onActivityResult () intervient dans le cadre du redémarrage d’une application qui a été vidée de sa mémoire par le système d’exploitation (car onResume () n’aurait pas été appelé avant onActivityResult ()).

Dans ce cas, onActivityResult () devrait être prêt à effectuer de telles initialisations pour toutes les variables utilisées par onActivityResult ().

Bien sûr, si les initialisations nécessaires à onActivityResult () pouvaient être effectuées dans onCreate () plutôt que dans onResume (), alors, puisque onCreate () sera appelé au redémarrage avant onActivityResult () et onResume (), ce serait le La façon la plus simple de choisir des choses que vous n’avez pas besoin de faire à chaque reprise de l’application. Si, toutefois, les données que vous initialisez proviennent d’une source externe et que vous en avez besoin, vous pouvez initialiser ces données dans onCreate () et onResume (), avec onResume () vérifiant un indicateur défini dans onCreate () pour voir si les données viennent d’être initialisées dans onCreate), puis les mettre à jour dans onResume () uniquement si elles ne l’ont pas été. De cette façon, un millésime sera toujours disponible (au moins à la date de la reprise de l’application).

Une autre façon de gérer cela consiste à stocker les informations renvoyées par onActivityResult () dans des variables qui seront récupérées par onResume () et traitées là-bas (après que toutes les initialisations requirejses ont été effectuées par onResume ()), plutôt que d’effectuer le traitement dans le corps de onActivityResult () lui-même.

C’est une fonctionnalité très documentée, sans explication ni avertissement (dans les documents officiels) concernant les conséquences de cette séquence quelque peu inattendue. Il est également très facile de passer à côté du problème pendant les tests, car sur un périphérique avec beaucoup de mémoire qui n’exécute pas beaucoup d’applications, l’activité qui appelle startActivityForResult () (ou ses variantes) peut ne jamais activité démarrée pour retourner un résultat via onActivityResult (), et donc toutes les initialisations effectuées par onResume () seront déjà disponibles, et le problème ne sera donc peut-être pas détecté.

Il y a une exploration informative de certains des problèmes entourant ce séquencement (y compris un avertissement concernant les tentatives d’utilisation de l’object Application de l’application pour protéger les variables de ses effets), accompagné d’un diagramme de séquence UML dessiné à la main:

http://steveliles.github.com/android_activity_lifecycle_gotcha.html

onActivityResult() est appelée en premier (il suffit de confirmer ceci avec quelques instructions de log et de voir que onActivityResult() est bien appelé avant onResume() )

Une conséquence de ceci est que toutes les initialisations que vous auriez pu décider d’exécuter uniquement dans onResume () (par exemple, les initialisations de données provenant d’une source externe dont vous avez besoin) plutôt que dans onCreate() ne seraient pas initialisées. onActivityResult() intervient dans le cadre du redémarrage d’une application qui a été vidée de sa mémoire par le système d’exploitation (car onResume() n’aurait pas été appelé avant onActivityResult() ).

Dans ce cas, onActivityResult () devrait être prêt à effectuer de telles initialisations pour toutes les variables utilisées par onActivityResult ().

Bien sûr, si les initialisations nécessaires à onActivityResult() pouvaient être effectuées dans onCreate() plutôt que dans onResume() , alors, puisque onCreate() sera appelé au redémarrage avant onActivityResult() et onResume() , ce serait le La façon la plus simple de choisir des choses que vous n’avez pas besoin de faire à chaque reprise de l’application. Si, toutefois, les données que vous initialisez proviennent d’une source externe et que vous en avez besoin, vous pouvez initialiser ces données dans onCreate() et onResume() , avec onResume() vérifiant un indicateur défini dans onCreate() pour voir si les données viennent d’être initialisées dans onCreate() , puis de les mettre à jour dans onResume() uniquement si elles ne l’ont pas été. De cette façon, un millésime sera toujours disponible (au moins à la date de la reprise de l’application).