Can getSupportActionBar be null right after setSupportActionBar?
Asked Answered
B

4

6

Should I null check the getSupportActionBar() method even if earlier in that method I have set the support action bar using getSupportActionBar()?

In onCreate() I have the three lines

Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
getSupportActionBar().setTitle(getIntent().getStringExtra(TITLE_KEY));

Android Studio then gives me the warning

"Method invocation may produce java.lang.NullPointerException"

Assuming that the findViewById method does return a valid ToolBar object, do I still need to null check the getSupportActionBar() method or is it safe to just ignore the warning?

Barometer answered 4/8, 2015 at 9:45 Comment(2)
Warning is not an Error. And the warning which you are talking about says "it may produce", don't say 'it must produce'.Karbala
@DhawalSodhaParmar if it was "it must produce" what would it be for then??? the getter method that always return null is uselessImpressible
P
2

My suggestion is :- Not to check for null because Warnings are not Errors

warning which you are talking about says "it may produce".It don't say 'will must produce'.

But if you want to double sure you can check for null

Paunch answered 4/8, 2015 at 9:52 Comment(0)
D
3

That may produce a NullPointer exception.

You have created a new Toolbar object, you can use toolbar.setTitle(getIntent().getStringExtra(TITLE_KEY)); to set the title. You'll need to do this before you call setSupportActionBar(toolbar);

There is no need to call getSupportActionBar(), since the actionbar that has been set is the toolbar. So you can directly use that object to edit your toolbar. That is faster than getSupportActionBar();

Diatropism answered 4/8, 2015 at 9:50 Comment(6)
The question is pertinent some stuff can't be done through ToolBar, for example setDisplayHomeAsUpEnabledPueblo
@Mood That's true, but for the things that the questioner wants to do Toolbar is fineDiatropism
Sorry @Diatropism I went over the question quickly.Pueblo
I looked at this. It turns out that doing toolbar.setTitle() after setSupportActionBar() does not work. I found this post #26487230 which talks about that as well. Unlike his example however I did work for me if I did toolbar.setTitle() before calling setSupportActionBar()Barometer
@Barometer Thanks! I've updated the answer. Please accept it if this solved your problemDiatropism
Thank you for your answer. It did help this specific case using setTitle() but as Mood pointed out, I was more asking about dealing with the getSupportActioBar method in general and I feel that NileshJarad's answer was more what I was looking for. Your answer was very useful however.Barometer
P
2

My suggestion is :- Not to check for null because Warnings are not Errors

warning which you are talking about says "it may produce".It don't say 'will must produce'.

But if you want to double sure you can check for null

Paunch answered 4/8, 2015 at 9:52 Comment(0)
P
0

To avoid having this warning you can always check if the ActionBar object is null.

ActionBar mActionBar = getSupportActionBar();

    if (mActionBar != null) {
        mActionBar.setTitle(getIntent().getStringExtra(TITLE_KEY));
    }
Pueblo answered 4/8, 2015 at 10:11 Comment(0)
N
0

No, you should not null check this. Because if the assumption fails (for example if findViewById(R.id.toolbar) starts returning null because you introduce a bug in another file in your project), you do want a NullPointerException to be thrown, so you easily find the error when you test.

In other words: In my opinion, the best approach is to fail fast.

My code looks like this, with a comment that silence the warning:

//noinspection ConstantConditions: Action bar should always be present. If not, we prefer a NullPointerException here.
getSupportActionBar().setHomeButtonEnabled(true);
getSupportActionBar().setDisplayHomeAsUpEnabled(true);
Nafis answered 12/3, 2018 at 9:7 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.