Android - Activité Constructeur vs onCreate

Je comprends que Android Activities ont des cycles de vie spécifiques et que onCreate devrait être substitué et utilisé pour l'initialisation, mais que se passe-t-il exactement dans le constructeur? Existe-t-il des cas où vous pouvez/devez outrepasser le constructeur Activity, ou ne devriez-vous jamais le toucher?Android - Activité Constructeur vs onCreate

Je suppose que le constructeur ne devrait jamais être utilisé parce que les références à Activities ne sont pas complètement nettoyées (entravant ainsi le garbage collector) et que onDestroy est là à cet effet. Est-ce correct?

Source

2010-07-21 idolize

Qu'en est-il du fait qu'Android peut détruire/recréer votre activité à tout moment? Vous ne savez pas si le constructeur sera appelé alors et même si - quel constructeur sera appelé ... (il en va de même pour les fragments et c'est pourquoi chaque fragment doit implémenter un constructeur par défaut vide). –

Je ne vois aucune raison de faire quoi que ce soit dans le constructeur. Vous ne construisez jamais une activité directement, vous ne pouvez donc pas l'utiliser pour transmettre des paramètres. Généralement, faites les choses dans onCreate.

Source

2010-07-21 20:26:02

+65

onCreate() vous empêche d'utiliser les champs finaux. – Gili

Tests? ' privé final InterfaceDep dep; public MyActivity() {dep = new DepImpl(); } MyActivity (InterfaceDep dep) {this.dep = dep; } ... @Mock private InterfaceDep dep; @InjectMocks private MyActivity myActivity; ' – saiyancoder

Mais OnCreate n'est pas appelé une seule fois, ai-je tort? Lorsque je change d'orientation de l'écran et revient par ma main, chaque fois que l'activité se recharge, oncreate s'appelle – fercis

Vous devez remplacer le constructeur lorsque votre activité aura des paramètres personnalisés ou que vous souhaitez effectuer le suivi des appels provenant des classes dont ils ont hérité.

Source

2010-07-21 18:39:20 Pentium10

Pouvez-vous donner plus de détails à ce sujet? Ce que vous décrivez semble intéressant, mais c'est un peu vague. Merci! – idolize

Supposons que vous ayez besoin de créer une classe d'activité personnalisée prenant 2 paramètres ou plus. Vous avez juste besoin d'utiliser le constructeur, vous ne pouvez pas le faire via onCreate et extras. Aide-t-il? – Pentium10

Mais vous ne créez pas explicitement des activités, vous créez une intention ... – idolize

Je suis maintenant sur un cas qui doit remplacer le constructeur. En fait, j'ai des activités qui ont la même structure. Ainsi, au lieu de créer de nombreuses activités, je créerai une activité "Maître" et les autres hériteront de celle-ci. J'ai donc besoin de surcharger le constructeur de l'activité enfant pour pouvoir initialiser certaines variables qui seront utilisées dans les méthodes oncreate. En deux mots, le constructeur vous fait simuler une "masteractivité" qui peut être réutilisée par héritage!

Source

2012-01-13 23:46:03 biboMandroid

+14

Je sais que c'est ancien, mais quel est l'avantage ici sur la simple implémentation de l'instanciation super-champ dans onCreate(). Vous appelez super.onCreate() de l'enfant de toute façon. –

Ainsi, simplement en transmettant différentes valeurs à la même clé dans le bundle ou l'intention lors du lancement de l'activité et ainsi en utilisant la même activité, vous pouvez déterminer ce qu'il faut afficher dans l'activité en fonction de la valeur reçue. Quelle est la raison spécifique pour laquelle vous avez choisi les constructeurs? Ou bien garder la partie non-changeante de l'activité commune et pour le reste de la partie changeante, vous pourriez avoir créé des fragments. –

que l'on appelle d'abord. constructeur ou surcréer. Je pense constructeur – Nepster

Une bonne raison de mettre des choses dans le constructeur comme le commentaire de Gili l'avait déclaré est l'utilisation des champs finaux.

Cependant, si vous initialisez des éléments dans le constructeur, la durée de vie de l'objet sera un peu plus longue, bien que je ne pense pas beaucoup car le onCreate sera appelé peu de temps après.

Bien que ce soit contre mon idéal, j'évite le constructeur pour l'initialisation des membres de l'activité et compte sur onResume() et onPause() pour les ressources que mon application a affaire. Pour onCreate() Je l'utilise habituellement pour faire le mappage de vues sur des variables locales. Bien que les annotations Android le fassent déjà pour moi, j'ai rarement une méthode onCreate() pour mon activité. Je l'utilise quand même dans le service.

Cependant, si vous regardez les membres que vous pouvez être initialiser

ils auraient une méthode « proche » que vous devez invoquer au bon moment (onResume ou OnPause)
ils feraient partie de la vue ce qui signifie qu'il doit être initialisé alors onCreate doit être appelé
ce sont des constantes qui n'ont pas besoin d'être mises dans le constructeur de toute façon, juste une finale statique ferait l'affaire. Cela inclut les constantes Paint et Path qui peuvent être initialisées par un bloc statique

Source

2013-07-19 21:46:55

Que voulez-vous dire la durée de vie de l'objet sera un peu plus long? Je quoi? Puisque si vous avez déplacé ces initialisations dans onCreate, par exemple, cela prend toujours le même temps. Il n'y a aucune différence dans la durée de vie que je peux déterminer. Pouvez-vous nous en dire un peu plus, s'il vous plaît? En tant que nouveau venu, je pourrais manquer quelque chose de crucial ici. – RichieHH

@RichieHH par plus long Archimède est juste disant que le constructeur est appelé avant onCreate() et ainsi tout ce qui y est fait aura persisté (légèrement) plus longtemps qu'autrement au moment où l'activité est détruite – pho79

Merci de n'avoir pas remarqué le commentaire de l'année dernière. Votre réponse est correcte. –

Android - Activité Constructeur vs onCreate

Répondre

Questions connexes