The entire original question was based on a mistake. You can NEVER assign the value of a final static FIELD constant in the constructor. If you could, you would have the value of the static FIELD changing every time a new instance of the class was created. Not very final!
I can instead do what I have been doing (and possibly creating memory leaks, I have a lot to learn), which is to use a static (but not final) field to point to the most recent instance of my Activity (see the code sample below). As the comment below that talks of memory leaks points out, I almost certainly have been creating memory leaks by keeping references to my older Activity objects around.
So the answers to my original question really comes down to: this is not a good thing to do because handing other objects references to my current Activity object allows them to keep the system from ever garbage collecting my old Activity objects!
Anyway, here is the code referred to in my original question, the answers and comments are still here so the rest of this is kept for reference to those.
public class MyActivity extends Activity {
public final static MyActivity uI;
public static MyActivity mostRecentUI;
private MyActivity() { // this is the constructor
// In my original post I had:
// uI = this;
// but this is illegal code. `final static anything;` cannot be assigned a
// value in the constructor, because it could be assigned a different value
// each time the class is instantiated!
// Instead the best I can do is
mostRecentUIobject = this;
// and this name better describes what this static variable contains
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
Added 4/15: @dmon goes as far as to comment that the constructor won’t be run. It will, and anybody with any doubt can run this test activity:
public class TestActivityConstructor extends Activity {
static long refTime = System.currentTimeMillis();
static String staticExecution = "Static never executed\n";
static String constructorExecution = "Constructor never executed\n";
static String onCreateExecution = "onCreate never executed\n";
static {
staticExecution = "Static Execution at " + (System.currentTimeMillis() - refTime) + " ms\n";
}
public TestActivityConstructor() {
constructorExecution = "Constructor Execution at " + (System.currentTimeMillis() - refTime) + "ms \n";
}
@Override
public void onCreate(Bundle savedInstanceState) {
onCreateExecution = "onCreate Execution at " + (System.currentTimeMillis() - refTime) + "ms \n";
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
((TextView) findViewById(R.id.TV)).setText(staticExecution + constructorExecution + onCreateExecution);
}
}
Obviously, you need a trivial layout.xml with a textview called TV. No permissions needed. You can even have fun rotating your android to see the app recreated showing that both the constructor and the onCreate are re-run every time the screen is rotated, but that the static assignments are NOT redone when the Activity is recreated.
To basically answer the main part of your question title…
No.
I’m assuming you’re coming to Android from a previous Java stand-point but one thing to understand about Android is that the
Activityclass is one of a few special case classes which should be left to work as they’re designed to.Don’t concern yourself with the concept of constructors when it comes to the
Activityclass just follow the design methodologies and application fundamentals which work quite adequately.If you have a specific requirement which doesn’t work within the Android framework then post a question with example code and somebody will explain how to fix it.
EDIT: In light of your update to your question…
Seriously…don’t do that. There are perfectly adequate, functional and safe mechanisms which can be used to easily handle any situation with minimal code without ‘breaking’ the model in the way you’re attempting to do things.
To repeat what I said above in my original answer – the Android
Activityclass is a special case. Instances ofActivityand their methods/fields are not meant to be accessed directly by any other external class.You’ll be doing yourself a favour and save a lot of headaches if you simply accept the fundamentals of the Android framework. Coding Android apps may well involve Java but not all ‘generic’ Java concepts apply, in particular to some of the core components such as
Activity.