Ndtyjky

I've looked through EditText.java , at line 109 , the comment below can be seen in the
getText() method:

// This can only happen during construction.

What is its purpose?

Thanks

I will expand on Andreas' answer, tailored for this particular set of classes.

EditText is a subclass of TextView. That's why it's declared as:

class EditText extends TextView (Simplified…)

The EditText constructors, look like this:

public EditText(Context context) {

    this(context, null);

}

public EditText(Context context, AttributeSet attrs) {

    this(context, attrs, com.android.internal.R.attr.editTextStyle);

}

public EditText(Context context, AttributeSet attrs, int defStyleAttr) {

    this(context, attrs, defStyleAttr, 0);

}

public EditText(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {

    super(context, attrs, defStyleAttr, defStyleRes);

}

Notice how each constructor calls the other until the last (long) one.
That one is tricky, because it calls super(…) meaning it's now calling the super class' constructor (TextView).

EditText is then just a specialized TextView as we can infer from this; TextView also declares a variable called text, which EditText uses as well of course. When you ask an EditText for the text, it simply uses the code that the TextView already has and that you discovered:

@Override

public Editable getText() {

    CharSequence text = super.getText();

    // This can only happen during construction.

    if (text == null) {

        return null;

    }



    [rest of code removed for clarity]

}

So it asks its super (the TextView) for the text; why can this text be null? To answer that, you need to go look at the TextView itself (https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/widget/TextView.java).

About 1000 lines of code later… the TextView declares its constructors; I'll paste one for simplicity but they are very simple:

public TextView(Context context) {

     this(context, null);

}

Notice they again call this(…) and chain the construction… one constructor calls the other and so forth… until the last big one for TextView is reached…

@SuppressWarnings("deprecation")

public TextView(

        Context context, @Nullable AttributeSet attrs, int defStyleAttr, int defStyleRes) {

    super(context, attrs, defStyleAttr, defStyleRes);

    // TextView is important by default, unless app developer overrode attribute.

    if (getImportantForAutofill() == IMPORTANT_FOR_AUTOFILL_AUTO) {

        setImportantForAutofill(IMPORTANT_FOR_AUTOFILL_YES);

    }

    setTextInternal("");

    [rest of code removed for clarity]

Notice something, this constructor, calls setTextInternal(""), that looks suspicious! it's setting the text to be an empty string upon construction, so it would be impossible for a TextView to have a null text after this constructor finishes (you could use reflection… but let's not go there); since EditText constructors are chained and end up always calling the TextView constructors, this method setTextInternal("") is guaranteed to be called at some point during the construction of the object in Java. (that's what Constructors are and that's a Java contract that would break 1/2 of the world if it were unreliable!).

What does this method do?

Apparently, a bunch of internal things, among other…

// Update mText and mPrecomputed

private void setTextInternal(@Nullable CharSequence text) {

    mText = text; // #### THIS IS WHERE IT SETS THE TEXT TO NON NULL ("").

    mSpannable = (text instanceof Spannable) ? (Spannable) text : null;

    mPrecomputed = (text instanceof PrecomputedText) ? (PrecomputedText) text : null;

}

If you remember that EditText#getText() called super.getText() guess what that looks like in super? (the TextView):

public CharSequence getText() {

    return mText;

}

That's right, the same mText reference/instance that setTextInternal() modified during the TextView construction.

That this is why during construction (and before setTextInternal("") is called, the field mText (that you access via getText()) can be null, but not after.

¯_(ツ)_/¯

In all honesty, I don't even know why they do this and the comment seems kinda silly, but as you have probably already guessed, these classes are thousands of lines of code and one tends to believe there must be a reason for this to exist; the best you can do is start analyzing the entire TextView class. Good luck with that. :)

The purpose of the comment is to tell any programmer that thinks the next statement is redundant, i.e. that text can never be null, that they are wrong, because it can happen during construction of the EditText object, so don't remove the statement.