Welcome back.
Shortly after we developed the changes for the videos in this section,
Google made another change.
In fact we've made several updates to this section
because of changes in the time between developing the code
and recording the videos.
That's how quickly things change in this environment.
I'm making this video because of a change that affects our AppDialog class.
We've got a serious warning in AppDialog
on line 65. This change is quite a good one
because it means we can use the bang bang operator less often now.
What google have done is added a
require context method to the AndroidxFragment class.
We've already established that the context can't be null
at this point in our code.
But we still had to use the bang bang operator,
so the compiler would compile the code.
I don't like using bang bang. I hope you don't either.
Google have now given us an alternative.
Click on context on line 65,
and accept the tool tip suggestion to replace with
requireContext.
This removes the need to use bang bang.
But be very careful here,
if the context had been null at this point then our code would have crashed.
Using context bang bang didn't prevent the code from crashing
it was a way for us to let the compiler know that the context
wouldn't be null.
We were sure context couldn't be null.
Using require context does the same thing.
If the context is null, our code will crash.
The RequireContext function will throw in
illegal state exception if the context is null.
All we've really done is replace one exception with another.
We'll now get illegal state exception
whereas before we would have got null pointer exception.
Using RequiredContext doesn't somehow magically give us a context
when one isn't available whether we can get a context or not
depends on where we are in the fragment lifecycle,
if the fragment isn't attached to its activity context will be null.
Remember the context is the activity.
RequireContext just gives us a nicer way to get a context
while keeping the compiler happy.
It doesn't prevent the app from crashing
if we try to use the context before it's available.
Control click on the RequireContext function
to view the source code.
As you can see it throws an exception if the context is null.
All we've done is appease the compiler without having to use bang bang.
It's still our responsibility
to ensure that we don't try to use the context if it might be null.
I'll say that again, using RequireContext
doesn't prevent our code from crashing.
We'll get a more useful error message, that's all.
As you can see in the source code, the error message will tell us that our fragment
isn't attached to a context.
We'll still get a crash.
Apart from the slightly more informative error message,
the only advantage of using required context
is that we can avoid using the bang bang operator.
That can be useful if your source code system runs scripts
to validate the code you check in and tests for bang bang.
As you saw, before I made the change, we had a strong warning.
If you use android studio's source code integration
that would trigger a warning when you try to check the code in.
Okay. I don't want to label the point too much.
I'll finish by talking about a few more required functions that Google
have added. Have a look through this source file fragment.java
and you'll find some more require function.
There's a require activity for when you need to get the
fragments activity and don't want to use the activity
further up in this file around line 676.
There's a RequireArguments function.
Once again, this doesn't guarantee that arguments isn't null.
We can't magically create arguments.
What it does is throw an exception if you try to access the arguments
when the arguments are null.
That's useful in our AppDialogue class.
I'll switch back to it and go to the bottom of the file.
The code's commented out at the moment
but, you can see that we use arguments bang bang
in the OnCancel function.
When we uncomment that function later,
we'll also change it to use require arguments.
I'll leave the change until then but I wanted to mention it now.
Remember that we've already established that the arguments aren't null.
We do that in the OnCreateDialog function.
If there are no arguments, we throw an exception in line 90.
All right. Now we really are ready to start improving the functionality of our app.
And we'll start that in the next video.
Of course, you should run the app and test it
just to make sure that we haven't broken anything. See you in the next video.