Welcome back. So how did you get on.
Most of the code is straightforward. There's just one bit that needs care.
You may have done things differently to me but here's my solution.
All the changes will be in the TaskTimerViewModel class.
I'll start by getting a reference to the DefaultSharedPreferences
and creating a variable to store the value that we should ignore.
It's very similar to the code in DurationsViewModel.
Next, we implement the OnSharedPreferenceChangeListener
to update Ignore_less_than when the preference changes.
I'll also log the new value.
We need to register the listener in the init block
and of course unregister it in OnCleared.
I'll include some logging to let us check that things are working.
Whenever we register a listener, we need to unregister again.
And of course that will do in OnCleared. All
that's pretty much the same as we did
in the DurationsViewModel class.
Where it gets interesting
is when we use the ignore LessThan value
in the SaveTiming function.
When a user starts timing a task,
we add a new row to the database.
When they stop timing, we update that row with the duration.
If we're going to ignore short durations,
we need to delete the original row that was added.
Our content provider makes that easy.
First, I'll wrap the update code in a test.
All right.
We're now only updating the row
if the duration is greater than our ignore value.
If we don't update, we have to delete the row instead.
It's not going to be easy to check what's going on,
which is why I've added logging in each case.
The logcat will let us know whether timings are being saved or not.
Okay. It's time to test it. Run the app,
and make sure the log cat's visible.
I'll start by making sure everything still works
before setting the option.
When I time a task,
then tap it again a second time,
we can see it being saved in the logcat.
Our update function returns 1, so it seems to be working.
In the settings, I'll change the value to ignore to 5 seconds.
I don't want to go too high
because we'll be sitting in silence waiting for the time to elapse.
Obviously, you should repeat these tests with a range of values.
Okay. Let's see if timings
less than five seconds are ignored.
The logcat has logged the entry from our settings listener
in the TaskTimerViewModel class.
So we know the new setting's being detected.
When I start timing a task and stop within 5 seconds,
we can see the row being deleted.
The delete function returns one
indicating that one row was deleted.
That's all looking good.
The last test I'll do is to start timing and leave it for more than 5 seconds.
If all goes well, we should see the update function returning 1
to indicate a successful update.
We'll also get a log entry from the SaveTiming function.
I'm just killing time now. 5 seconds is a long time on video.
Okay. That should do it. I'll stop the timing and check the logcat,
and that looks good.
We've got SaveTiming reporting that it saved the timing
with the duration of 23,
the update function returned 1,
indicating that one row was updated.
Obviously, you now want to perform thorough testing
to make sure everything works as it should
and the figures in the report are correct.
That's the end of this section
and all the functionality of our apps now complete.
In this section we added a new activity to the app.
That means main activity and its fragments
will be stopped when we switch to the new durations report activity.
That makes it easy to spot resources that we may be leaking.
In the next section, we'll do some final tidying up.
This is an essential step before you release your app to the play store
and it should become a habit.
I'll see you in the next section.