1
00:00:03,810 --> 00:00:09,610
Welcome back. We've got the Timings table
in the database now, and we're ready to

2
00:00:09,610 --> 00:00:16,090
save the Timings data. When the user long-taps a task, we'll create a new Timing

3
00:00:16,090 --> 00:00:21,490
instance. When they long-tap a second
time, we'll use the Timing instance to

4
00:00:21,490 --> 00:00:25,780
provide the data to save. The app isn't
going to run a timer.

5
00:00:25,780 --> 00:00:30,700
Instead, we'll save the details when a
task starts to be timed, then update the

6
00:00:30,700 --> 00:00:35,640
duration when it's stopped.
We need a Timing class to store the data.

7
00:00:35,640 --> 00:00:41,220
Let's create that first. It'll be a basic
Kotlin class and we'll define the fields

8
00:00:41,230 --> 00:00:46,000
in the constructor. We need fields to
store the task ID, the start time and the

9
00:00:46,000 --> 00:00:49,740
timings database ID.

10
00:01:08,060 --> 00:01:14,680
If you're prompted for the date import,
we want Java dot util dot date.

11
00:01:30,180 --> 00:01:36,760
I've made a setter for the duration
field private, on line 16. That prevents

12
00:01:36,760 --> 00:01:40,810
the code from changing the duration
directly. The only way to set the

13
00:01:40,810 --> 00:01:46,600
duration is by calling our setDuration
function. Using Kotlin's normal property

14
00:01:46,600 --> 00:01:51,010
access isn't suitable, in this case,
because the calling code won't be

15
00:01:51,010 --> 00:01:56,050
providing a new value for the duration.
Instead, the duration is calculated by

16
00:01:56,050 --> 00:02:00,550
subtracting the start time from the
current time. When we create a new timing

17
00:02:00,550 --> 00:02:06,310
record, the task that's being timed and
the start time will never change.

18
00:02:06,310 --> 00:02:11,739
The timing ID will change - it starts off at 0
and gets given a value once the record's

19
00:02:11,740 --> 00:02:17,700
saved in the database. By using val for
the task ID and start time fields,

20
00:02:17,700 --> 00:02:23,700
we make sure they can't be changed, once the
timing instance is created. I've used

21
00:02:23,709 --> 00:02:29,230
default values for start time and the ID.
Unless we need to provide values for

22
00:02:29,230 --> 00:02:34,510
them, we only have to provide the task ID
when creating a new timing. The other

23
00:02:34,510 --> 00:02:39,459
fields will be initialized to the
current time, and 0. The time that we get

24
00:02:39,460 --> 00:02:44,040
from the date class is in milliseconds.
That's a bit extreme for our purposes.

25
00:02:44,040 --> 00:02:48,540
We're going to be working in seconds, not
milliseconds. That's why the values are

26
00:02:48,549 --> 00:02:55,360
divided by a thousand, in the constructor
and on line 20. Alright that's the timing

27
00:02:55,360 --> 00:03:02,380
class created. Next, we need to add some
code to our TaskTimerViewModel class

28
00:03:06,400 --> 00:03:11,340
I'll start with a variable to store the
timing.

29
00:03:18,660 --> 00:03:23,600
We'll set that to a new task instance,
when the user starts timing a task.

30
00:03:23,600 --> 00:03:30,340
I'll call the function timeTask and put it
after the deleteTask function.

31
00:04:18,660 --> 00:04:24,040
I've commented out all the calls to saveTiming because we haven't written it yet.

32
00:04:24,040 --> 00:04:29,640
Before I do, I'll go through the logic of
this timeTask function. I've used a

33
00:04:29,640 --> 00:04:35,640
local variable - timingRecord - to allow
smart casts. We know that nothing's

34
00:04:35,640 --> 00:04:38,520
altering our timing instance on another thread,

35
00:04:38,520 --> 00:04:44,080
so basically, timingRecord and currentTiming will be referring to exactly the

36
00:04:44,080 --> 00:04:49,260
same object. We start by checking to see
if we have a currentTiming instance.

37
00:04:49,260 --> 00:04:53,880
If currentTiming is null,
there's no task being timed, and we just

38
00:04:53,880 --> 00:04:59,670
create a new timing instance and save it.
That's easy. It's a bit more interesting

39
00:04:59,670 --> 00:05:05,700
if you've already got a task being timed.
If there is a task currently being timed,

40
00:05:05,700 --> 00:05:12,000
we start by updating its' duration and
saving it. Next, we have to decide whether

41
00:05:12,000 --> 00:05:16,500
we got here because the new task was
long-tapped, or if the user long-tapped

42
00:05:16,500 --> 00:05:22,760
the same task to stop it. If the task ID
is the same as the task we were timing,

43
00:05:22,760 --> 00:05:27,900
then we stop timing and we don't have to
create a new timing instance. We set

44
00:05:27,900 --> 00:05:35,550
currentTiming to null, on line 114. On
the other hand, if the task ID is

45
00:05:35,550 --> 00:05:41,370
different, then the user long-tapped a
different task. In that case, we create a

46
00:05:41,370 --> 00:05:47,550
new timing instance to save it. Note that
the new timing instances are saved as

47
00:05:47,550 --> 00:05:51,660
soon as they're created. They'll be
stored in the database, with a duration

48
00:05:51,660 --> 00:05:56,400
of zero. The user can turn their phone
off, at this point, if they have to.

49
00:05:56,400 --> 00:06:01,220
When they turn it back on again, they can stop
timing the task, and the database row

50
00:06:01,230 --> 00:06:06,240
will be updated with the correct
duration. I'll build up the full

51
00:06:06,240 --> 00:06:11,220
functionality, as we write more code.
That's how it's going to work, but we'll

52
00:06:11,220 --> 00:06:16,290
start by getting the basic saving
working. In the next video, we'll write

53
00:06:16,290 --> 00:06:21,140
that saveTiming function. I'll see you
there.