G'day everyone, welcome back.
We're ready to test our AppDialog class,
but first, I'll review the code that creates our dialog in the onDeleteClick function, on MainActivityFragment.
The code adds the DIALOG_ID, the DIALOG_MESSAGE,
and the caption for the DIALOG_POSITIVE_RID key of the bundle.
After setting up the args bundle, it then creates a new AppDialog instance.
The next two lines are very similar to what we did for our fragment,
and we are using a DialogFragment after all, so it's not really surprising.
AppDialog extends DialogFragment, so it's a fragment hosting the AlertDialog.
The first argument to the dot show function is a bit different.
Google's examples show how to show a dialog from an activity, but we're showing it from a fragment.
That means we pass a childFragmentManager, rather than a supportFragmentManager,
which is what Google's examples show.
That second argument to the dialog.show function is an optional tag that we can use if we need to find the fragment again.
I can't think of a reason why you'd want to do that with a dialog,
but it's just providing the same capabilities that any other fragment would have.
As we're not going to use it, we pass in null.
Okay, that should show the dialog to request confirmation, before deleting a task.
It's worth running the app at this stage. We can check that the dialog does appear,
and dismisses itself when we click one of the buttons.
We'll start by testing our exceptions,
if we try to use the AppDialog class from an activity that doesn't implement the required interface.
When I run the app and delete a task, we get an error:
ClassCastException: Fragment MainActivityFragment must implement AppDialog.DialogEvents interface.
So that's pretty good.
The app crashed, but told us exactly why.
In fact, we can copy the full interface name from the error message,
and add it to the declaration of MainActivityFragment.
We've got the usual error, because we're not implementing the required function.
I'll get Android Studio to generate the stub using Ctrl I, after the onTaskLongClick function.
Then add logging, so we can see the function is being called.
Before I run the app again, remember that we put in a check that both an ID and a message were provided in the bundle.
We should really test that.
I'll comment out the line that adds the ID to the bundle.
Then run the app again.
Once again, I get an error when we delete a task.
This time it's complaining that I've got an illegal argument exception:
DIALOG_ID and/or DIALOG_MESSAGE are not present in the bundle.
Now really, we should comment out the line that adds the message, and check that we get the same error.
Then uncomment the ID line, and test we get the error if only the message isn't present.
I'm not going to do that in this video because I'm going to run out of tasks to delete,
but you should certainly test all three combinations, to make sure that our check works in all three situations.
Hang on, I'm going to run out of tasks to delete?
But surely, the tasks will only be deleted if I confirm it by tapping the dialog's delete button.
Unfortunately not, and I'll be coming to that shortly.
First, I'll uncomment the line that's causing the problem,
and run the app again.
I'm going to delete task 10,
so make a mental note of the task name as I tap the delete button.
And there's our dialog.
It clearly states what the impact of deleting the record will be,
and offers the user options to go ahead, or cancel the operation.
Okay.
Back to my running out of tasks comment.
When you shift the focus from the dialog to the lists behind it,
notice that task 10 has gone from the list.
It's already deleted.
Now, if you're new to programming, or new to programming in a GUI environment,
you'll probably see nothing strange about that.
After all, if I switch back to look at the onDeleteClick function,
we can see it sets up the dialog, shows it, and then calls the ViewModel's delete function to delete the task.
On the other hand, if you've got experience programming for Windows, for example,
then you may have expected the code in onDeleteClick to pause after showing the dialog,
and only resume once a dialog's dismissed.
The term for the Windows behavior I've just described, is modal.
Obviously, we have to make a change.
We have to move that call to the ViewModel's delete function into onPositiveDialogResult.
Okay, we still haven't managed to confirm the deletion of tasks,
but it looks like our AppDialog class is working fine.
The next step is to get MainActivity to use it properly,
and we'll do that in the next video.
See you then.