onActivityResult () & onResume ()

Question

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

L'activité d'Un des appels startActivityForResult() pour démarrer l'Activité de B. B s'exécute, remplit et retourne un résultat à une, mais la méthode de A est appelé en premier, onActivityResult() ou onResume()?

Je connais quelqu'un qui a déjà répondu en se référant à l' Activité de Docs, mais je n'arrivais pas à trouver en moi-même.

Answer 1

Premier appel, onActivityResult() alors onResume().

Citation de docs:

protected void onActivityResult (int requestCode, int resultCode, Intent de données)

Depuis: l'API de Niveau 1 Appelée lorsqu'un d'activité, vous avez lancé des sorties, donnant vous le requestCode vous avez commencé avec, la resultCode il revint, et toutes les autres données. L' resultCode sera RESULT_CANCELED si l'activité explicitement retourné, n'a pas renvoyé de résultat, ou écrasé au cours de son fonctionnement. Vous recevrez cet appel immédiatement avant onResume() lorsque votre activité est re-départ.

Answer 2

Comme d'autres l'ont publié, onActivityResult() est appelée avant onResume() lorsque votre activité est en cours de redémarrage.

Diane Hackborn explique que onActivityResult() est appelée avant onResume() afin de permettre à tout ce qui pourrait affecter l'INTERFACE utilisateur pour être reçu et disponible avant la mise à jour de l'INTERFACE utilisateur (sans doute pour éviter un double-mise à jour - une fois dans onResume() sans le résultat retourné, puis dans onActivityResult(), en ajoutant le résultat retourné).

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

Une conséquence de ceci est que les initialisations vous pourriez avoir décidé de n'effectuer que dans onResume() (par exemple, les initialisations de données à partir d'une source extérieure que vous avez besoin pour être frais) plutôt que dans onCreate(), serait non initialisée lors d'un appel onActivityResult() se produit dans le cadre de la reprise d'une application qui a été évacué de la mémoire par le système d'exploitation (parce que onResume() n'aurait pas été appelé avant onActivityResult()).

Dans cette situation, onActivityResult() devrait être prêt à procéder à une telle initialisation de ces variables qui sont utilisées par onActivityResult().

Bien sûr, si les initialisations nécessaires par onActivityResult() peut être effectuée dans onCreate() plutôt que dans onResume(), puis depuis onCreate() sera appelée sur un redémarrage avant que les deux onActivityResult() et onResume(), qui serait la façon la plus simple d'aller pour des choses que vous n'avez pas besoin de le faire chaque fois que l'application est repris. Si, toutefois, les données que vous êtes initialisation provient d'une source extérieure et vous en avez besoin pour être frais, vous pouvez initialiser ces données dans les deux onCreate() et onResume(), avec onResume() vérification d'un indicateur défini dans onCreate() pour voir si les données ont simplement été initialisée dans le onCreate), et ensuite le mettre à jour dans onResume() uniquement si ils ne l'ont pas été. De cette façon, un certain millésime de il sera toujours disponible (au moins à compter du moment précédent, l'application a été repris).

Une autre façon de gérer cela est de stocker les informations retournées par onActivityResult() dans des variables qui aura ramassé par onResume() et traitées (après les initialisations nécessaires ont été effectuées par onResume()), plutôt que d'effectuer la transformation dans le corps de onActivityResult() elle-même.

C'est une fonctionnalité qui est très clairement documenté, avec aucune explication ni avertissement offert (dans la langue officielle docs) sur les conséquences de cette quelque peu inattendu de séquençage. Il est également très facile de manquer le problème lors d'un test, parce que sur un appareil avec beaucoup de mémoire qui n'est pas en cours d'exécution de nombreuses applications, l'activité qui est l'appel de startActivityForResult() (ou ses variantes) ne peut jamais obtenir vidées de mémoire, en attente de l'activité pour retourner un résultat par onActivityResult(), et donc toutes les initialisations effectuées par onResume() sera déjà disponible, et donc le problème ne peut pas être détecté.

Il y a une information à l'exploration de certaines des questions entourant ce séquençage (y compris un avertissement concernant les tentatives d'utilisation de l'app objet de l'Application afin de protéger les variables à partir de ses effets), complet avec un dessin à la main diagramme de séquence UML, ici:

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

Answer 3

onActivityResult() est appelé en premier (je viens de le confirmer avec quelques déclarations de journal et nous voyons que onActivityResult() est effectivement appelé avant onResume() )