And welcome back, everyone.
We've just seen our task vanished from the RecyclerView when we swipe it.
That's normal behavior.
What we have to do is make it appear again if the user cancels the deletion.
It's easy to do.
We need to get the position of the item that was swiped
then tell the RecyclerView to put it back.
We do that by calling the adapter's
notifyItemChanged function
and passing in the position of the item that was swiped.
We'll do that in the dialogue's
onNegativeDialogResult callback.
Unfortunately, we decided not to implement that.
So we'll have to make a couple of changes to AppDialog.
Let's have a look in there at our dialog events interface
at the start of the class.
Now we've seen that interfaces are contracts,
and you shouldn't change an interface once you've published it.
If we add an OnNegativeDialogResult function
to the DialogEvents interface,
we'll break our existing classes.
Fortunately, the android JVM
now supports some Java 8 features.
Not all of them, but it does support default implementations
in interfaces.
I'll create the problem,
then we'll see how a default implementation can solve it.
Start by uncommenting the two functions we decided not to implement.
Anything that declares it implements this interface
now has to implement those two additional functions.
Rebuild the project,
and see how much havoc we've caused.
The build fails, and we've broken three classes.
You can expand the messages in the build output pane
to see that they all have the same error.
We're not implementing the OnNegativeDialogResult function.
That's not good.
We don't really want to go changing unrelated classes
just to make a change to the way we delete tasks.
This is where a default implementation can save the day.
If we provide a default implementation for the functions in an interface,
java will use that implementation
and not insist that our classes override the functions.
Our default implementations won't do anything,
we'll put an empty code block after the interface methods.
Rebuild the project again, and we no longer get the errors.
Our interface is now easier to use.
Classes can override only those functions that they need,
and don't have to provide a dummy implementation of the others.
Our original code for AppDialog was written before Java 8 became available
in the android JVM. We've now improved it,
making it easy to use while still providing the ability to respond
to any of the three ways the user may close the dialog.
Android studio versions 3.whatever
now support some of the new features added in Java 8.
Default method implementations in interfaces is supported
and that allows us to make our AppDialog class
a bit easier to use.
Before we finish with this class,
we should uncomment the call to the listener's NegativeResult function
and support the dialog being cancelled.
That's down near the end of the class, near the CreateDialog function.
I'll uncomment the OnCancel function.
We weren't using it,
but now we're notifying our listener if the dialog gets cancelled.
The import you want is android.content
.dialog interface if you're prompted.
We saw that OnCancel function in an earlier video
when we discussed making all three functions part of the interface.
Now with default implementations in java 8,
we've got the best of both worlds.
Our interface can support positive and negative results and cancel
without forcing classes to implement all three functions.
We've got a strong warning on line 116.
I mentioned this a few videos ago when we talked about RequireContext.
This is similar.
We've had to use arguments bang bang
because the compiler can't be sure that our arguments aren't null.
We know it's not null. We check that in the OnCreateDialog function,
but the compiler can't be sure.
Using the bang bang operator is how we tell the compiler that we know what we're doing.
Now there's a slightly neater way.
Click on arguments on line 116,
and accept the suggestion to replace with
require arguments instead.
I won't go into it all again, refer to the video entitled
"Another Breaking Change" earlier in this section
if you want to remind yourself what this is all about.
In the next video we'll see how to use the NegativeDialogResult
to make the task appear in the RecyclerView again.
I'll see you over there.