1
00:00:03,900 --> 00:00:09,370
Welcome back everyone. Our Settings
Dialog's coming along well. We've only

2
00:00:09,370 --> 00:00:14,349
got three more things to implement,
before it's finished. In this video, we'll

3
00:00:14,349 --> 00:00:19,160
get it to display the values that the
user selects. I'll run the app again and

4
00:00:19,160 --> 00:00:29,020
go into settings, so we can see what
we're about to change. The text above the

5
00:00:29,020 --> 00:00:36,430
seek bar doesn't look good. It's showing
% 1d space % 2s at the end. What we want

6
00:00:36,430 --> 00:00:43,000
to say is something like, ignore timings
less than 5 seconds, or, ignore timings

7
00:00:43,000 --> 00:00:49,930
less than 10 minutes. Our seek bar has a
linear range from 0 to 24. Dealing with a

8
00:00:49,930 --> 00:00:55,149
linear range like that is easy. That's
the default behavior. We want something a

9
00:00:55,149 --> 00:01:00,460
bit more complicated. When the user drags
a slider, it will go up in 5 second

10
00:01:00,460 --> 00:01:06,080
increments. When they get to 60 seconds,
we want to show one minute instead.

11
00:01:06,080 --> 00:01:11,100
From there, we'll go up in one minute
intervals up to 10 minutes. After that,

12
00:01:11,100 --> 00:01:17,700
we'll go up in 15 minute intervals, up to
45 minutes. That may sound complicated,

13
00:01:17,700 --> 00:01:22,420
but it's surprisingly easy to do. We just
have to set up an array that represents

14
00:01:22,420 --> 00:01:28,810
the real values we want, for each of the
values from 0 to 24. An array is ideal

15
00:01:28,810 --> 00:01:35,020
for that, so let's see the code. I'll set
the seek bar to value 7, before going back

16
00:01:35,020 --> 00:01:43,329
to our code. Remember that's the 8th dot.
We're about to change the data that's

17
00:01:43,329 --> 00:01:47,590
saved, and I want to show you that this
can cause a problem, but the problem

18
00:01:47,590 --> 00:01:52,620
doesn't mean our code's not working. I'll
click OK to save the new value,

19
00:01:52,620 --> 00:01:55,580
then go back to our code.

20
00:02:01,220 --> 00:02:05,360
I'm going to paste in the array
declaration with a comment that shows

21
00:02:05,360 --> 00:02:17,480
the index position of each value.

22
00:02:53,960 --> 00:02:58,040
It's useful to have the index positions
above the values, just make sure they

23
00:02:58,049 --> 00:03:06,150
line up correctly. Okay, we're working in
seconds. The final value, 2,700 seconds,

24
00:03:06,150 --> 00:03:11,609
is 45 minutes. When we get a value from the
seek bar, we can use the value from this

25
00:03:11,609 --> 00:03:17,080
deltas array, to get the amount of time
that it represents. The change to

26
00:03:17,080 --> 00:03:28,940
SaveValues is easy. We save the value from this deltas array.

27
00:03:28,940 --> 00:03:36,900
That's straightforward. If the seek value is 7, for example, we save 35 seconds. Next, we've got a

28
00:03:36,900 --> 00:03:42,120
conversion to do, when setting the value
of the seek bar. If we read back 35 from

29
00:03:42,120 --> 00:03:47,680
the settings, we need to convert that to
7 before setting the seek bar's value.

30
00:03:47,680 --> 00:03:52,680
We're setting the seek bars initial
value on the onViewStateRestored.

31
00:03:52,680 --> 00:03:57,860
So that's where we convert the seconds back into an index.

32
00:04:13,569 --> 00:04:18,130
Arrays have a binary search function
that we can use to find the index

33
00:04:18,130 --> 00:04:22,830
position of a value. If the value exists
in the array, we get its index position,

34
00:04:22,830 --> 00:04:26,180
otherwise the function returns a
negative number.

35
00:04:26,180 --> 00:04:31,500
Note the binary search relies on the
array being sorted. Our values are in

36
00:04:31,509 --> 00:04:34,120
order, which is fine, but it wouldn't work if

37
00:04:34,120 --> 00:04:39,220
they weren't in order. All our values
have to exist. They were looked up in the

38
00:04:39,220 --> 00:04:44,080
array before being saved, but just in
case we've made a mistake somewhere, we

39
00:04:44,080 --> 00:04:48,039
throw an exception if the number of
seconds wasn't found. That's going to be

40
00:04:48,039 --> 00:04:53,500
easy to test, as you'll see in a moment.
Alright, we're just about done.

41
00:04:53,500 --> 00:04:58,949
The final step is to set the seek bar to the
correct value.

42
00:05:14,199 --> 00:05:20,119
If you remember, we set the seek bar's
maximum value in the layout. Now you can

43
00:05:20,119 --> 00:05:24,830
see where the value 24 came from. It's
the maximum index value of our deltas

44
00:05:24,830 --> 00:05:30,080
array, but it's not a good idea to rely
on setting the maximum in the layout.

45
00:05:30,080 --> 00:05:34,759
If we change our array to have more or
fewer values, then the code, either

46
00:05:34,759 --> 00:05:39,409
wouldn't use the additional values, or it
would crash with an index out of bounds

47
00:05:39,409 --> 00:05:45,169
exception. To prevent that, we set the
maximum value explicitly in our code, on

48
00:05:45,169 --> 00:05:52,300
line 16. If the deltas array changes size,
the seek bar's maximum will change too.

49
00:05:52,300 --> 00:06:01,600
Okay, let's run the app and watch a crash.

50
00:06:01,600 --> 00:06:07,519
When we've seen it crash, I'll explain why.
I'll make sure the logcat's visible, then

51
00:06:07,519 --> 00:06:11,349
clear it before going to the settings.

52
00:06:21,849 --> 00:06:27,789
And the app crashes. Don't worry, there's
nothing wrong with our code. Checking the

53
00:06:27,789 --> 00:06:34,400
logcat before the crash, we can see that
the value 7 was read in for ignoreLessThan.

54
00:06:39,360 --> 00:06:44,080
7 isn't one of the values in our
Delta's array, and our code throws an

55
00:06:44,089 --> 00:06:49,639
exception as a result. Click the link in
the stack trace to check that the

56
00:06:49,639 --> 00:06:55,339
exception was the one we threw, in on
ViewStateRestored. Our code's working

57
00:06:55,339 --> 00:06:59,509
fine. The problem happens because we're
now trying to interpret the saved data

58
00:06:59,509 --> 00:07:03,889
differently. This will happen when you're
developing your app. It's very easy to

59
00:07:03,889 --> 00:07:09,829
create invalid data when testing early
versions. The fix is easy; uninstall the

60
00:07:09,829 --> 00:07:15,979
app, delete all it's saved data and run
it again. I'll do that, and this time we

61
00:07:15,979 --> 00:07:18,669
won't get a crash.

62
00:07:39,160 --> 00:07:46,720
Alright, I'll finish by dragging the
slider to about halfway again, and set

63
00:07:46,720 --> 00:07:54,610
the first day to Tuesday. When I tap OK,
we should see the values being logged in

64
00:07:54,610 --> 00:08:01,780
logcat; 3 for Tuesday and however many
seconds I selected. In the next video,

65
00:08:01,780 --> 00:08:06,320
we'll update the display to show the
number of seconds in the dialog.

66
00:08:06,320 --> 00:08:09,140
See you in that one.

