Android - Activity Constructor vs onCreate

JavaAndroidGarbage CollectionAndroid ActivityOncreate

Java Problem Overview


I understand that Android Activities have specific lifecycles and that onCreate should be overridden and used for initialization, but what exactly happens in the constructor? Are there any cases when you could/should override the Activity constructor as well, or should you never touch it?

I'm assuming that the constructor should never be used because references to Activities aren't cleaned up entirely (thus hampering the garbage collector) and that onDestroy is there for that purpose. Is this correct?

Java Solutions


Solution 1 - Java

I can't think of any good reason to do anything in the constructor. You never construct an activity directly, so you can't use it to pass in parameters. Generally, just do things in onCreate.

Solution 2 - Java

A good reason for putting things in the constructor as Gili's comment had stated is the use of final fields.

However, if you initialize things in the constructor, then the lifespan of the object will be a little bit longer, though I don't think by much because the onCreate would be called shortly thereafter.

Although it's against my ideal, I do avoid the constructor for initialization of the activity members and rely on onResume() and onPause() for resources that my app is dealing with.

For onCreate() I usually use it to do view mapping to local variables. Though android-annotations already does that for me so I rarely have an onCreate() method for my Activity. I still use it in Service though.

However, if you look at the members you may be initializing

  • they would have a "close" method that you have to invoke at the proper time (onResume or onPause)

  • they would be part of the view which means it needs to be initialized then onCreate needs to be called

  • they are constants which don't need to be put in the constructor anyway, just a static final would do. This includes Paint and Path constants which can be initialized by a static block

Solution 3 - Java

I am now on a case that needs to override the constructor. In fact, I have some activities that have the same structure. So instead of creating many activities, I'll create one "Master" activity and the others will inherit this one. So I need to override the constructor of the child activity to be able to initialize some variables that will be used in the oncreate methods.

In two words, the constructor makes you simulate a "masteractivity" that can be reused by inheritance!

Solution 4 - Java

You need to override the Constructor when your activity will have custom params or you want to track calls from classes that inherited from.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionidolizeView Question on Stackoverflow
Solution 1 - JavaCheryl SimonView Answer on Stackoverflow
Solution 2 - JavaArchimedes TrajanoView Answer on Stackoverflow
Solution 3 - JavabiboMandroidView Answer on Stackoverflow
Solution 4 - JavaPentium10View Answer on Stackoverflow