Android - Activity Constructor vs onCreate

Question

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?

Solution 1

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

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

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!

Comments

[idolize]

Can you elaborate on this more? What you describe sounds interesting, but it is a little vague. Thanks!

[Pentium10]

Suppose you need to create a custom Activity class that takes 2 or more params. You just need to use the Constructor, you can't do that via the onCreate and extras. Does it help?

[Pentium10]

It might that I need a private one. Suppose I want to create a custom component for example a customized contact picker. In order to have startActivityForResult I must include a private constructor in my custom component, even if that activity will never be launched and has no visibile elements, I just use the for result stuff of it.

[Blundell]

I'm going to say, that doesn't make sense to me @Pentium, not without a code example.

[Gili]

onCreate() prevents you from using final fields.

[Andrew G]

I know this is old but what is the benefit here over just implementing the super field instantiation in it onCreate(). You'll be calling super.onCreate() from the child anyway.

[Archimedes Trajano]

I think one advantage of doing things via constructor is to have a "template" activity which can take in parameters that an inherited class can take advantage of. For example if you have two activities which only differ in some of the properties e.g. R.id.cameraSurface, R.id.videoSurface then you can create a constructor that will take in a parameter call it AbstractResourceActivity and then you have CameraActivity which is registered on the manifest that extends AbstractResourceActivity passing in the resource ID.

[RichieHH]

What do you mean the lifespan of the object will be a little bit longer? I what way? Since if you moved these initalisations into the onCreate, for example, that still takes the same time. There is no difference in lifespan that I can determine. Can you expand on this a little more please as I feel, as a relative newcomer, I might be missing something crucial here.

[Nayanesh Gupte]

So just by passing diffrent Values to same KEY in bundle or intent while launching activity and thus using same Activity you can determine what to show in Activity depending on value received. What is the specific reason you went for construtors? Or else keeping the non-changing part of Activity common and for rest of the changing part you could have created Fragments.

[fercis]

But OnCreate is not called only once, am I wrong? When I change screen orientation and back by my hand, each time the activity reloads, oncreate is called

[pho79]

@RichieHH by longer Archimedes is just saying that the constructor gets called before onCreate() and so whatever is done there will have persisted (slightly) longer than otherwise by the time the activity is destroyed

[Harvey Adcock]

@fercis onCreate is called only once per instance I believe. When rotating the device, that instance of the Activity is destroyed and a new one is created, calling onCreate. That said, I'm pretty certain you can't instantiate final fields in onCreate because Java doesn't know onCreate is only going to be called once (and indeed, you could call it again yourself in your code - bad things will happen, but it'll still compile) and so the only way to instantiate final fields would be in the constructor.

[Mohammad Afrashteh]

When does OnCreate event start to run exactly? When I set a breakpoint at beginning of OnCreate event so app run and loads activity to screen then breakpoint activates and the app goes to pause. I need an event about the activity that activates exactly before activity initialized and launched.

[Sreekanth Karumanaghat]

@Cheryl Simon, You told you never create an activity directly, then who creates the activity?