Android - Constructeur d'activité vs onCreate

88

Je comprends qu'Android Activitiesa des cycles de vie spécifiques et que cela onCreatedevrait être remplacé et utilisé pour l'initialisation, mais que se passe-t-il exactement dans le constructeur? Y a-t-il des cas où vous pourriez / devriez également remplacer le Activityconstructeur ou ne devriez-vous jamais le toucher?

Je suppose que le constructeur ne doit jamais être utilisé car les références à Activitiesne sont pas entièrement nettoyées (ce qui entrave le garbage collector) et c'est onDestroylà pour cela. Est-ce correct?

— idolâtrer
source

2

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é ... (la même chose s'applique aux fragments et c'est pourquoi chaque fragment doit implémenter un constructeur par défaut vide).

— Marian Paździoch

34

Je ne vois aucune bonne 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. En règle générale, faites simplement des choses dans onCreate.

— Cheryl Simon
source

73

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

— Gili

2

Mais OnCreate n'est pas appelé une seule fois, ai-je tort? Lorsque je change l'orientation de l'écran et le retour par la main, chaque fois que l'activité se recharge, oncreate est appelé

— fercis

2

@fercis onCreate n'est appelé qu'une seule fois par instance, je crois. Lors de la rotation de l'appareil, cette instance de l'activité est détruite et une nouvelle est créée, en appelant onCreate. Cela dit, je suis à peu près certain que vous ne pouvez pas instancier les champs finaux dans onCreate car Java ne sait pas que onCreate ne sera appelé qu'une seule fois (et en effet, vous pouvez le rappeler vous-même dans votre code - de mauvaises choses vont arriver, mais il compilera toujours) et donc la seule façon d'instancier les champs finaux serait dans le constructeur.

— Harvey Adcock

Quand l'événement OnCreate commence-t-il à s'exécuter exactement? Lorsque je définis un point d'arrêt au début de l'événement OnCreate pour que l'application s'exécute et charge l'activité à l'écran, le point d'arrêt s'active et l'application se met en pause. J'ai besoin d'un événement sur l'activité qui s'active exactement avant que l'activité ne soit initialisée et lancée.

— Mohammad Afrashteh

@Cheryl Simon, Vous avez dit que vous ne créez jamais d'activité directement, alors qui crée l'activité?

— Sreekanth Karumanaghat

7

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

Cependant, si vous initialisez des choses dans le constructeur, la durée de vie de l'objet sera un peu plus longue, bien que je ne pense pas de beaucoup car le onCreateserait 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 je compte sur onResume()et onPause()pour les ressources que mon application traite.

Car onCreate()je l'utilise généralement pour faire le mappage de vues sur des variables locales. Bien que Android-annotations le fasse déjà pour moi, j'ai rarement une onCreate()méthode pour mon activité. Je l'utilise toujours en service.

Cependant, si vous regardez les membres que vous initialisez peut-être

ils auraient une méthode "close" que vous devrez appeler au bon moment (onResume ou onPause)
ils feraient partie de la vue, ce qui signifie qu'il doit être initialisé puis onCreate doit être appelé
ce sont des constantes qui n'ont pas besoin d'être placées 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

— Archimède Trajano
source

1

Que voulez-vous dire que la durée de vie de l'objet sera un peu plus longue? Je de quelle manière? Puisque si vous avez déplacé ces initalisations dans onCreate, par exemple, cela prend toujours le même temps. Il n'y a aucune différence de durée de vie que je puisse déterminer. Pouvez-vous développer un peu plus cela, s'il vous plaît, car je pense qu'en tant que nouveau venu, il me manque peut-être quelque chose de crucial ici.

— RichieHH

2

@RichieHH par plus long Archimedes dit juste que le constructeur est appelé avant onCreate () et donc quoi que ce soit fait là-bas aura persisté (légèrement) plus longtemps qu'autrement au moment où l'activité est détruite

— pho79

6

Je suis maintenant sur un cas qui doit remplacer le constructeur. En fait, j'ai des activités qui ont la même structure. Donc au lieu de créer de nombreuses activités, je vais créer une activité "Master" et les autres hériteront de celle-ci. J'ai donc besoin de remplacer 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!

— biboMandroid
source

15

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

— Andrew G

Ainsi, simplement en transmettant différentes Valeurs à la même CLÉ dans le groupe ou l'intention lors du lancement de l'activité et en utilisant ainsi la même activité, vous pouvez déterminer ce qu'il faut afficher dans Activité en fonction de la valeur reçue. Quelle est la raison spécifique pour laquelle vous avez choisi des constructeurs? Ou bien en gardant la partie non changeante de l'activité commune et pour le reste de la partie changeante, vous auriez pu créer des fragments.

— Nayanesh Gupte

0

Vous devez remplacer le constructeur lorsque votre activité aura des paramètres personnalisés ou que vous souhaitez suivre les appels de classes héritées de.

— Pentium10
source

1

Pouvez-vous nous en dire plus? Ce que vous décrivez semble intéressant, mais c'est un peu vague. Merci!

— idolâtrer le

3

Supposons que vous deviez créer une classe Activity personnalisée qui accepte au moins 2 paramètres. Vous avez juste besoin d'utiliser le constructeur, vous ne pouvez pas le faire via onCreate et des extras. Aide-t-il?

— Pentium10

1

Il se peut que j'aie besoin d'un privé. Supposons que je souhaite créer un composant personnalisé, par exemple un sélecteur de contacts personnalisé. Pour avoir, startActivityForResultje dois inclure un constructeur privé dans mon composant personnalisé, même si cette activité ne sera jamais lancée et n'a aucun élément visible, j'utilise juste le truc pour le résultat.

— Pentium10 du

6

Je vais dire que cela n'a pas de sens pour moi @Pentium, non sans un exemple de code.

— Blundell

Je pense que l'un des avantages de faire les choses via le constructeur est d'avoir une activité "modèle" qui peut prendre des paramètres dont une classe héritée peut tirer parti. Par exemple, si vous avez deux activités qui ne diffèrent que par certaines des propriétés, par exemple R.id.cameraSurface, R.id.videoSurface, vous pouvez créer un constructeur qui prendra un paramètre appelé AbstractResourceActivity et alors vous avez CameraActivity qui est enregistré sur le manifeste qui étend AbstractResourceActivity en passant l'ID de ressource.

— Archimedes Trajano