Okay, let's continue where we left off in the last video.
Now that we've finished the code, all the errors have gone,
except for our OK and Cancel resource IDs that we're using as the defaults.
Rather than editing the res/value/strings.xml file,
click on ok,
then drop down from the light bulb that appears.
We want the first option, Create string value resource ok.
The resource name's filled in for us.
All we need to do is to provide the resource value, OK.
We can do the same thing for the cancel.
This time, the resource value is Cancel.
Our code's looking good, and we've checked to make sure that a bundle was passed in when
our dialog fragment was created.
We also check to see if the bundle contains an ID and a message.
The positive and negative button IDs are optional, but the dialog ID and the message aren't.
If either value is missing, getInt returns 0 and getString returns null.
We check this and throw an exception, just as we did for the null bundle.
I've made the exception messages a bit different, so it's obvious where the exception was thrown.
Remember that you won't always be running on a device that's connected to Android Studio.
You may just have a log file to try to diagnose problems from.
I haven't mentioned what happens in our onClick listeners for the two buttons.
All they do is call the appropriate callback functions,
using a safe call on dialogEvents.
The dialog will automatically dismiss itself when one of the buttons is tapped,
so we don't have to worry about calling its dismiss function.
You will have to do that if you create a custom dialog, and we'll look at that when we come
to create a settings dialog.
Okay, we're nearly done.
There's just one more case we need to deal with, and that's if the user dismisses the
dialog using the back button.
If that happens, neither of our callback functions will be called.
What will happen, is that Android will call the onCancel function in the dialog fragment
class.
It also calls the onDismiss function.
We can override the onCancel and respond to it there.
I'll get Android Studio to generate both functions for us, and I'll put them right at the end
of the class, after the onDetach function, and add the usual logging.
I'm also going to add a comment next to the super call, in onDismiss.
You could leave the call to super.onCancel in the onCancel function, but it doesn't do
anything, as you can see, by control clicking on it.
The super.onDismiss call is needed, and if you remove it, strange things happen; such
as a dialog reappearing when the device is rotated.
Control click the super.onDismiss and you'll see that it does do something.
The comment does mention that the user may see the dialog again, when they come back
to the activity.
There's no mention of this in the Android documentation that we just looked at.
Let's go back and check that, because we need to have a look at the last section anyway,
to work out how we should code these two functions.
So back in https://developer.android.com/guide/topics/ui/dialogs.html
I'll scroll right down to the bottom of the document.
It's discussing dismissing a dialog.
When the user touches any of the action buttons created with an AlertDialog.builder, the system
dismisses the dialog for you.
There are very rarely any wasted words in technical documentation, so notice that it
doesn't just say, when the user touches any of the action buttons, the system dismisses
the dialog for you.
The fact that it specifically refers to the buttons created with an AlertDialog.builder
is important.
And if you use your own buttons from a layout, when using a custom dialog, the system won't
dismiss the dialog for you.
You'll have to call the dismiss function yourself.
We'll see that when we create a settings dialog, in a later video.
Okay, if we need to perform any special actions when the dialog goes away, we'll do that in
the onDismiss function.
There's often no need to override onDismiss, and the only reason I've done it, is to log
the fact that it's been called.
So that we can check the sequence of things in the logcat.
If a dialog's dismissed, then you'll either get one of the button events called, or onCancel.
To put that another way, whenever a dialog is dismissed, for whatever reason, the onDismiss
function will be called.
It won't give you any indication of why the dialog was dismissed.
You can just respond to the fact that it has been.
There probably aren't too many situations where overriding onDismiss will be useful.
onCancel, on the other hand, is the only way to respond if the dialog's cancelled,
either by the user pressing the back button, or tapping the screen outside of the dialog.
So this function is useful.
It indicates that a user has removed your dialog, without using either of the buttons;
that they haven't made one of the choices you presented them with, in other words.
A dialog could also be cancelled by calling the Dialog class's cancel function, and in
that case, onCancel would also be called.
That's possibly less useful, because if your code's going to call the cancel function,
then it already knows that the dialog's going to be cancelled.
It can be a way to put all the cancel code in one place, though.
That's what the note on the end of the doc is saying.
onDismiss is called, even if it was dismissed as a result of being cancelled.
onCancel is only called when the dialog's cancelled by one of the three functions mentioned.
If onCancel is called, onDismiss will also be called, but the opposite isn't true.
Alright.
In our onCancel function we've overridden, we can call back our listener, using its
onDialogCancelled function.
We don't bother passing the arguments bundle back from this function, because it's unlikely
to be useful.
The bundle is still available using the getArguments function.
So if we change our mind while developing the app, it won't be the end of the world.
Notice that we don't bother checking if the dialog ID is present in the bundle or even
if there is a bundle.
That checking was performed when our dialog fragment was created, so there's no point
checking it again.
If the bundle didn't exist or didn't contain an ID, then the program would have crashed
before we could get here.
Alright, that's how you respond to the dialog being cancelled, if you wanted to.
We're not doing that, and I've got an error because our interface doesn't have an
onDialogCancelled function.
I'll comment that line out, because we're not implementing the cancel callback.
I'll stop the video here.
In the next video, we'll use this AppDialog class to allow the user to confirm the deletion
of a task record.
See you in the next one.