1
00:00:03,740 --> 00:00:10,280
G'day everyone, welcome back. The save
Timing function's pretty straightforward.

2
00:00:10,280 --> 00:00:17,039
It's code that we've seen before. The
only slight complication, is that we need

3
00:00:17,039 --> 00:00:22,320
to decide whether we're saving a new
record, or updating an existing one.

4
00:00:22,320 --> 00:00:28,720
If we're saving a new record, it'll have a
duration of zero. Any timing instance

5
00:00:28,720 --> 00:00:33,500
that has a non-zero duration means that we
want to update the row, rather than add a

6
00:00:33,500 --> 00:00:39,980
new one. I'll put the saveTiming
function after timeTask.

7
00:00:45,140 --> 00:00:54,660
We'll put a log statement in just so we know it's going
on. We said before, that if we're

8
00:00:54,660 --> 00:01:00,400
inserting, then the currentTiming
duration will be zero.

9
00:01:03,840 --> 00:01:07,400
Let's add in the column data.

10
00:01:37,890 --> 00:01:43,350
When we insert a new row in the database,
we have to store the ID back into the

11
00:01:43,350 --> 00:01:47,340
timing object, otherwise, we won't be able
to update it later.

12
00:01:47,340 --> 00:01:53,620
We've seen that done before, when saving
a taskRecord in the saveTask function.

13
00:01:53,620 --> 00:01:58,840
We can improve on that code slightly. The
only column that changes when we update,

14
00:01:58,840 --> 00:02:03,300
is a duration. There's no point
adding the other two columns to the

15
00:02:03,300 --> 00:02:07,190
content values, in that case.

16
00:02:19,280 --> 00:02:27,820
Alright, I can now uncomment the calls
to saveTiming, in our timeTask function.

17
00:02:40,700 --> 00:02:46,360
We've got two errors again, because
currentTiming is a nullable type,

18
00:02:46,360 --> 00:02:52,530
and can't be cast to a non-null timing, using
a smart cast. We can fix that with the

19
00:02:52,530 --> 00:02:58,600
bangbang operator. We've just created a
new instance on the line above, in each case,

20
00:02:58,600 --> 00:03:04,300
so it's not going to be null. I
think it's safe to do that, and it's

21
00:03:04,319 --> 00:03:09,120
arguably safer than what I'm about to do
for the second error. If you're not a fan

22
00:03:09,120 --> 00:03:15,640
of bangbang - and you certainly should use
them sparingly - then another approach is,

23
00:03:15,640 --> 00:03:30,000
change the currentTiming to val newTiming, save the newTiming,

24
00:03:30,000 --> 00:03:34,760
and then assign that to the current timing.

25
00:03:39,710 --> 00:03:44,780
Personally, I don't like using bangbang
too much, but I think it's preferable in

26
00:03:44,780 --> 00:03:50,150
this case. If you forget to assign the
newTiming back to currentTiming, you'll

27
00:03:50,150 --> 00:03:54,350
have a bug. It's also easier to work out
what's happening, in the first case, on

28
00:03:54,350 --> 00:04:01,850
line 106. I'll leave both ways in the
code, for comparison. I don't suggest you

29
00:04:01,850 --> 00:04:07,250
do that in your code. Whichever method
you prefer, be consistent, especially

30
00:04:07,250 --> 00:04:12,380
inside the same function. In the next
video, we'll test the app to make sure

31
00:04:12,380 --> 00:04:16,329
this is working. I'll see you then.