G'day everyone, welcome back. The last video finished with a challenge,
to define a callback interface and use it to successfully edit tasks.
There are often different ways to do things and your solution may look a bit different to mine,
but it should be roughly along the same lines,
I'll start by defining the interface in MainActivityFragment.
Then we'll call the activity's onTaskEdit function in onEditClick.
That's all the changes we have to make to MainActivityFragment,
but there's another change that we should make. We should make sure the activity really does implement the interface.
That causes our code to crash straight away, rather than appearing to work until the user taps a button.
If you can't even run your app without it crashing, you'll spot there's a problem straight away.
I'll demonstrate that after making the change.
We can't get a reference to the activity before onAttach,
so that's where I'll add the code.
Okay, to see how this can help to spot problems more easily, I'll run the app.
Remember that we haven't made MainActivity implement the interface yet.
As soon as the app runs, it crashes.
The message in the log is "MainActivity must implement onTaskEdit",
which makes it very easy for the programmer to work out what's wrong, and of course to fix it.
That leads nicely onto the next step in the challenge, implementing the interface in MainActivity.
We'll start by declaring that it does implement the interface.
I'll add the necessary function after onOptionsItemsSelected, before the taskEditRequest function.
Remember, control I will let Android Studio generate the stub for us,
and we can replace the TODO.
It doesn't have a lot to do, because all the work's already being performed by taskEditRequest.
You may be wondering why we didn't just rename taskEditRequest, to onTaskEdit.
That would work, but it's not a good idea
taskEditRequest accepts a nullable task type, which it has to have when we call it from the plus icon on the menu.
When we're adding a new task, we pass null for the task argument.
If we called the function that takes a nullable type from our onClickListener,
we'd lose the null type safety that Kotlin provides.
A bug in our code could result in the user adding a new task when they wanted to edit an existing one.
This way, if we do try to pass a null to onTaskEdit,
the compiler will complain, and we'll detect the problem straight away.
Ok does it work.
I'll edit task 5. I'll change the description so that it reads fifth as a word, instead of as a number,
and I'll change the sort order to 7.
Okay, we save and return to the list and we can see that task 5 has been updated.
It's got the new description and it's moved further down the list,
so the new sort order's taken effect. So that looks like it's working.
What if we change the task name? I'll edit task 1 and change the name to task 10.
Then I save, and tasks 1's now task 10.
We can tell it's the same task by the description,
and that's one of the reasons that we've been boring in our choice of names and descriptions.
At some point, you'll want to test the app with more realistic task names and descriptions,
including making sure that those max length values we used are working.
You'll also want to check the display, to see how it looks
when names that use the max length number of characters are entered.
But when you're still developing, it's much easier to verify that things are working as you expect,
if you follow some sort of pattern, like this.
We can also tell what the ID should be from the name,
our new task 10 should have an ID of 1 in the database,
and that can be useful if strange things happen, and you need to work out what's going on.
So that's the edit button working and the end of the challenge.
Remember, you may not have done things exactly the same way as I did,
but if your app works and you can successfully edit tasks, then well done.
I'll stop this video here.
In the next video, we'll look at deleting tasks when the delete button's tapped. See you then.