1
00:00:04,700 --> 00:00:07,040
Alright, so as I mentioned, the

2
00:00:07,040 --> 00:00:09,350
calculator's working pretty well. And I

3
00:00:09,350 --> 00:00:10,700
think it was a nice touch that there's

4
00:00:10,700 --> 00:00:12,260
no need for a Clear button to start a

5
00:00:12,260 --> 00:00:14,179
new calculation. When you want to stand

6
00:00:14,179 --> 00:00:15,469
a new calculation, you just press

7
00:00:15,469 --> 00:00:16,910
equals to finish the current one,

8
00:00:16,910 --> 00:00:18,919
then type the new number and press equals

9
00:00:18,919 --> 00:00:21,230
again. The new number is transferred

10
00:00:21,230 --> 00:00:22,730
up to the result, ready to add to it or

11
00:00:22,730 --> 00:00:24,290
multiply or what if you want to do next.

12
00:00:24,290 --> 00:00:26,720
But as I mentioned, it's not necessarily

13
00:00:26,720 --> 00:00:28,939
very intuitive. So to see what I mean,

14
00:00:28,939 --> 00:00:30,980
I'm just going to bring back the emulator,

15
00:00:30,980 --> 00:00:34,370
and if we actually type something like 6

16
00:00:34,370 --> 00:00:38,900
equals, to start afresh. So next if I

17
00:00:38,900 --> 00:00:43,700
type divide 2, click on divide 2, then

18
00:00:43,700 --> 00:00:49,040
I deduct a take, 3 and then equals, we get

19
00:00:49,040 --> 00:00:51,860
the answer 0.0. But if I want to multiply

20
00:00:51,860 --> 00:00:59,750
9 by 5 now, I enter 9 times, but because it

21
00:00:59,750 --> 00:01:01,910
tries to multiply 0 by 9, it doesn't work.

22
00:01:01,910 --> 00:01:03,710
So what I actually have to do is type

23
00:01:03,710 --> 00:01:12,859
equals 9 equals, then the multiply 5, and

24
00:01:12,859 --> 00:01:14,359
now when I press equals I'll get the

25
00:01:14,359 --> 00:01:14,929
answer

26
00:01:14,929 --> 00:01:17,450
45 - basically, when I press the next

27
00:01:17,450 --> 00:01:19,069
operator button. But again, that's not

28
00:01:19,069 --> 00:01:20,479
very intuitive, and could actually

29
00:01:20,479 --> 00:01:22,130
confuse people til they get used to it,

30
00:01:22,130 --> 00:01:24,219
but I'll come back to that later. But

31
00:01:24,219 --> 00:01:26,509
also notice that when you click on the

32
00:01:26,509 --> 00:01:29,869
result EditText, the soft keyboard

33
00:01:29,869 --> 00:01:31,850
doesn't appear because, if you recall, we

34
00:01:31,850 --> 00:01:34,340
made it not focusable. But if you want to,

35
00:01:34,340 --> 00:01:36,350
you can use the soft keyboard in the

36
00:01:36,350 --> 00:01:39,079
data entry EditText. So in here, we can

37
00:01:39,079 --> 00:01:40,459
do that and you can see the keyboard's popped

38
00:01:40,459 --> 00:01:42,529
up for us there, automatically. Now we

39
00:01:42,529 --> 00:01:44,749
could disable that as well, but if the

40
00:01:44,749 --> 00:01:46,189
user really wants to, then there's no

41
00:01:46,189 --> 00:01:48,200
good reason to stop them. And they can

42
00:01:48,200 --> 00:01:50,090
always dismiss the keyboard if they

43
00:01:50,090 --> 00:01:51,619
don't want it - if they don't want it anymore.

44
00:01:51,619 --> 00:01:53,299
So they can come down here and get rid of

45
00:01:53,299 --> 00:01:55,700
it if they want. Now remember that they

46
00:01:55,700 --> 00:01:57,829
might also be using an external keyboard,

47
00:01:57,829 --> 00:02:00,380
so don't restrict what your users can do,

48
00:02:00,380 --> 00:02:02,270
unless there's a really good reason for

49
00:02:02,270 --> 00:02:04,939
restricting them. Now there is one bit of

50
00:02:04,939 --> 00:02:06,229
validation that we need to perform,

51
00:02:06,229 --> 00:02:09,199
though, despite having used a numeric

52
00:02:09,199 --> 00:02:11,660
EditText widget. Now we can't enter more

53
00:02:11,660 --> 00:02:13,099
than one decimal point in the input

54
00:02:13,099 --> 00:02:15,590
widget - we've tried that previously. But

55
00:02:15,590 --> 00:02:18,260
we can enter nothing but a decimal point,

56
00:02:18,260 --> 00:02:20,180
and unfortunately, that will cause the

57
00:02:20,180 --> 00:02:21,530
program to crash at the moment when it

58
00:02:21,530 --> 00:02:24,019
tries to convert a full stop to a valid

59
00:02:24,019 --> 00:02:26,450
number. So to demonstrate that, if I type

60
00:02:26,450 --> 00:02:28,640
the button, or press the button and type

61
00:02:28,640 --> 00:02:32,239
equals, we can see we've got Calculator has

62
00:02:32,239 --> 00:02:34,819
stopped. And if you we back to Android

63
00:02:34,819 --> 00:02:38,870
Studio now and look in the logcat, and

64
00:02:38,870 --> 00:02:40,220
just scroll up and have a look there, we

65
00:02:40,220 --> 00:02:42,319
can see that we've got a NumberFormat

66
00:02:42,319 --> 00:02:44,900
Exception for input string, and then the,

67
00:02:44,900 --> 00:02:47,989
just the dot, or the period. And you can see

68
00:02:47,989 --> 00:02:49,159
that the error there, is actually

69
00:02:49,159 --> 00:02:52,519
happening on line 86, and the code for

70
00:02:52,519 --> 00:02:55,129
line 86 is this operand2 equals value

71
00:02:55,129 --> 00:02:57,920
dot toDouble. And just to confirm that,

72
00:02:57,920 --> 00:02:59,450
if I just close down the logcat

73
00:02:59,450 --> 00:03:06,049
and run this again. So now that the

74
00:03:06,049 --> 00:03:08,090
emulator's running again, if we enter a

75
00:03:08,090 --> 00:03:10,069
dot equals as the very first input,

76
00:03:10,069 --> 00:03:13,459
we'll get the same error. So dot equals,

77
00:03:13,459 --> 00:03:17,349
same error, but then looking at logcat,

78
00:03:17,349 --> 00:03:21,709
this time it's actually on line 84, on line

79
00:03:21,709 --> 00:03:24,739
84 as for operand1. Now what we could do -

80
00:03:24,739 --> 00:03:27,410
I'll just close down logcat. So, we could put

81
00:03:27,410 --> 00:03:29,359
in a test for value being just a dot,

82
00:03:29,359 --> 00:03:31,730
but if the program was changed to allow

83
00:03:31,730 --> 00:03:33,139
the input number to be negative, for

84
00:03:33,139 --> 00:03:34,849
example, it would then have to check for

85
00:03:34,849 --> 00:03:37,340
dot and minus dot, both of which would

86
00:03:37,340 --> 00:03:39,530
cause an exception. So the way I'm

87
00:03:39,530 --> 00:03:40,940
going to prevent the program crashing

88
00:03:40,940 --> 00:03:43,430
here, is to catch the NumberFormat

89
00:03:43,430 --> 00:03:46,940
Exception that's being raised. But before

90
00:03:46,940 --> 00:03:48,709
we can do that, though, we have to decide

91
00:03:48,709 --> 00:03:49,639
what action to take

92
00:03:49,639 --> 00:03:53,030
when invalid input is used. Now, we could

93
00:03:53,030 --> 00:03:55,400
interpret invalid input as 0, which sort

94
00:03:55,400 --> 00:03:57,739
of makes sense, but may not be what the

95
00:03:57,739 --> 00:03:59,959
user expects. But what we'll do here, I

96
00:03:59,959 --> 00:04:01,909
think, is change the program slightly,

97
00:04:01,909 --> 00:04:04,129
so that it performs the conversion from

98
00:04:04,129 --> 00:04:06,560
String to Double before calling the

99
00:04:06,560 --> 00:04:08,840
performOperation method. Then if the

100
00:04:08,840 --> 00:04:10,760
conversion raises an exception, we'll

101
00:04:10,760 --> 00:04:13,280
clear the input window. So first, what we

102
00:04:13,280 --> 00:04:14,840
want to do, is change the perform

103
00:04:14,840 --> 00:04:17,329
Operation method, which I can see on the

104
00:04:17,329 --> 00:04:19,279
screen there now. Now its first parameter

105
00:04:19,279 --> 00:04:22,099
will be a Double, which is

106
00:04:22,099 --> 00:04:24,830
assigned directly to operand1 or

107
00:04:24,830 --> 00:04:27,590
operand2, without conversion. So I'm going

108
00:04:27,590 --> 00:04:32,260
to go ahead and change value to a Double,

109
00:04:32,260 --> 00:04:35,570
and then we're going to change it so it's

110
00:04:35,570 --> 00:04:38,030
assigned directly to operand1

111
00:04:38,030 --> 00:04:41,390
or operand2 without conversion, because it's

112
00:04:41,390 --> 00:04:42,980
now, I've typed Double. So we're going to

113
00:04:42,980 --> 00:04:44,570
change this, now, so operand1 equals

114
00:04:44,570 --> 00:04:49,040
value if operand1 was null. Otherwise,

115
00:04:49,040 --> 00:04:51,050
operand 2 is going to be equal just to

116
00:04:51,050 --> 00:04:53,570
value now, instead of value.toDouble, because of

117
00:04:53,570 --> 00:04:56,540
course, the definition - the type - has been

118
00:04:56,540 --> 00:04:58,270
changed from String to Double, up here.

119
00:04:58,270 --> 00:05:00,470
Alright, so the conversion from String to

120
00:05:00,470 --> 00:05:02,660
Double is then performed in the on

121
00:05:02,660 --> 00:05:05,270
Click method, and the input field cleared

122
00:05:05,270 --> 00:05:07,700
if an exception's raised. Now if there is

123
00:05:07,700 --> 00:05:09,290
an exception raised when attempting to

124
00:05:09,290 --> 00:05:11,000
convert the String into a Double, the

125
00:05:11,000 --> 00:05:12,620
performOperation method won't actually

126
00:05:12,620 --> 00:05:15,080
be called at all. So let's go back up to

127
00:05:15,080 --> 00:05:18,310
that code. So back up here in the

128
00:05:18,310 --> 00:05:20,960
opListener code, and what we want to

129
00:05:20,960 --> 00:05:23,360
do here is introduce a try/catch block.

130
00:05:23,360 --> 00:05:26,510
So after the first line here on line 65 -

131
00:05:26,510 --> 00:05:29,870
the value op, where we're defining that - we're

132
00:05:29,870 --> 00:05:32,690
going to introduce a try/block, and

133
00:05:32,690 --> 00:05:35,620
within that try/block we're going to,

134
00:05:35,620 --> 00:05:39,440
firstly copy that line, the definition of

135
00:05:39,440 --> 00:05:42,919
value. Paste that in there, and then what

136
00:05:42,919 --> 00:05:48,190
we're going to do is, also copy that line

137
00:05:48,190 --> 00:05:51,169
and paste that in there as well. Then we

138
00:05:51,169 --> 00:05:52,730
can get rid of this if test outside

139
00:05:52,730 --> 00:05:54,500
of here. We no longer need that anymore.

140
00:05:54,500 --> 00:05:57,950
And in fact, what we'll do is the try, we'll

141
00:05:57,950 --> 00:05:59,840
finish off the try with a catch. And the

142
00:05:59,840 --> 00:06:05,300
catch, it's going to be an e : There's

143
00:06:05,300 --> 00:06:07,750
going to be a NumberFormatException,

144
00:06:07,750 --> 00:06:10,400
and the code block in there will be new

145
00:06:10,400 --> 00:06:14,300
Number.setText parentheses, and then

146
00:06:14,300 --> 00:06:16,550
two double quotes to set it to an empty

147
00:06:16,550 --> 00:06:18,890
value. The other thing we need to do,

148
00:06:18,890 --> 00:06:21,340
though - and we've got this line here; val

149
00:06:21,340 --> 00:06:24,830
value equals newNumber.text.toString - we

150
00:06:24,830 --> 00:06:26,810
need to do one other thing there. We need

151
00:06:26,810 --> 00:06:28,940
to do a dot toDouble, because of course,

152
00:06:28,940 --> 00:06:30,260
we're converting the String to the

153
00:06:30,260 --> 00:06:32,810
Double, here, because we've changed the

154
00:06:32,810 --> 00:06:34,220
type in performOperation and we also

155
00:06:34,220 --> 00:06:36,530
removed the conversion that was

156
00:06:36,530 --> 00:06:38,510
originally in here, in the perform

157
00:06:38,510 --> 00:06:41,360
Operation function. Alright so now, even

158
00:06:41,360 --> 00:06:43,460
if there is an exception, the code still

159
00:06:43,460 --> 00:06:44,920
sets the pendingOperation,

160
00:06:44,920 --> 00:06:47,020
because the code will still be executing

161
00:06:47,020 --> 00:06:50,380
down here on lines 72 and 73. Because

162
00:06:50,380 --> 00:06:51,790
otherwise, the user wouldn't be able to

163
00:06:51,790 --> 00:06:53,950
change the type of operation they want

164
00:06:53,950 --> 00:06:56,200
to perform, without entering some number

165
00:06:56,200 --> 00:06:57,550
and performing the current pending

166
00:06:57,550 --> 00:06:59,830
operation. Now if you're not sure about

167
00:06:59,830 --> 00:07:03,510
that, you can move these two lines here,

168
00:07:03,510 --> 00:07:05,800
into the try block and see what happens

169
00:07:05,800 --> 00:07:07,930
if you press divide, when you really want

170
00:07:07,930 --> 00:07:10,060
it to multiply. But with the code as it

171
00:07:10,060 --> 00:07:10,750
is here,

172
00:07:10,750 --> 00:07:13,330
you just press multiply and carry on. Alright,

173
00:07:13,330 --> 00:07:15,190
I'm going to leave that code where it is,

174
00:07:15,190 --> 00:07:18,240
and let's just try running it again, and

175
00:07:18,240 --> 00:07:26,320
see if things work. So we just do now,

176
00:07:26,320 --> 00:07:30,130
a dot equals. We find now, that it's, in

177
00:07:30,130 --> 00:07:31,420
fact, not crashing anymore. So we've

178
00:07:31,420 --> 00:07:33,670
fixed that, so obviously, the try/catch is

179
00:07:33,670 --> 00:07:35,380
working. But we should still be able to

180
00:07:35,380 --> 00:07:38,290
do something else like seven equals, and

181
00:07:38,290 --> 00:07:42,940
if we put the ten plus, and you can see that's

182
00:07:42,940 --> 00:07:45,100
working and it's doing it; dot equals

183
00:07:45,100 --> 00:07:46,560
again, and that's still working nicely.

184
00:07:46,560 --> 00:07:48,940
Alright, so now we've fixed the crash,

185
00:07:48,940 --> 00:07:51,610
and we're now no longer causing the

186
00:07:51,610 --> 00:07:53,920
app to crash if a decimal point is

187
00:07:53,920 --> 00:07:56,560
entered by itself. Now the last thing I'd

188
00:07:56,560 --> 00:07:57,880
like to discuss before I finish this

189
00:07:57,880 --> 00:08:00,130
video, are the warnings - and we'll just go

190
00:08:00,130 --> 00:08:02,710
back to Android Studio - that are

191
00:08:02,710 --> 00:08:04,210
sometimes showing in the right-hand

192
00:08:04,210 --> 00:08:05,980
margin. And as I mentioned in the last

193
00:08:05,980 --> 00:08:08,020
section, it's always a good idea to keep

194
00:08:08,020 --> 00:08:09,640
an eye on these and pay attention to

195
00:08:09,640 --> 00:08:11,770
what they're saying. Now support for

196
00:08:11,770 --> 00:08:14,290
Kotlin in Android is very new, and the

197
00:08:14,290 --> 00:08:16,180
lint checks are evolving all the time.

198
00:08:16,180 --> 00:08:18,160
Now I'm sort of guessing ahead a bit

199
00:08:18,160 --> 00:08:19,540
here, because I haven't got any warning

200
00:08:19,540 --> 00:08:20,920
showing - there's just this one suggestion

201
00:08:20,920 --> 00:08:23,610
here; Assignment can be lifted out of if.

202
00:08:23,610 --> 00:08:26,170
Now you may also not have any warnings -

203
00:08:26,170 --> 00:08:27,370
it depends on whether Google have

204
00:08:27,370 --> 00:08:29,770
included the checks in your version of

205
00:08:29,770 --> 00:08:32,740
Android Studio. But even without the

206
00:08:32,740 --> 00:08:34,990
checker flagging warnings, a careful

207
00:08:34,990 --> 00:08:36,549
review of the code shows something that

208
00:08:36,549 --> 00:08:39,760
we should look at - operand2. Now if we

209
00:08:39,760 --> 00:08:41,679
look through the code, the only place

210
00:08:41,679 --> 00:08:43,570
it's used is in the performOperation

211
00:08:43,570 --> 00:08:44,080
method.

212
00:08:44,080 --> 00:08:47,110
So again, operand2 - we defined

213
00:08:47,110 --> 00:08:49,780
that here originally on line 17. It's

214
00:08:49,780 --> 00:08:52,070
only really used

215
00:08:52,070 --> 00:08:55,070
in the performOperation function. Now

216
00:08:55,070 --> 00:08:56,930
Android Studio makes it easy to check

217
00:08:56,930 --> 00:08:59,450
that. We can select operand2 where

218
00:08:59,450 --> 00:09:01,580
it's declared on line 17 - I'll just go back

219
00:09:01,580 --> 00:09:03,740
up there again. So you can select that by

220
00:09:03,740 --> 00:09:06,470
double-clicking it, and a pink or purple

221
00:09:06,470 --> 00:09:09,080
tick will appear in all the places it's

222
00:09:09,080 --> 00:09:10,160
used - you can see over here to the

223
00:09:10,160 --> 00:09:12,620
right-hand side. And if I just click on

224
00:09:12,620 --> 00:09:16,040
the first one, you can see the first one

225
00:09:16,040 --> 00:09:18,980
is actually in the performOperation

226
00:09:18,980 --> 00:09:20,480
function, and all the other ones are

227
00:09:20,480 --> 00:09:21,800
below that. So in other words, that's the

228
00:09:21,800 --> 00:09:23,780
only place other than the definition,

229
00:09:23,780 --> 00:09:26,180
which I can click to go back up to, that

230
00:09:26,180 --> 00:09:29,510
it's used in this particular class. Now

231
00:09:29,510 --> 00:09:31,940
operand1 has to be a property, because

232
00:09:31,940 --> 00:09:33,740
it's used in both of our

233
00:09:33,740 --> 00:09:36,140
functions. Now operand2, though, isn't

234
00:09:36,140 --> 00:09:38,120
used anywhere outside the perform

235
00:09:38,120 --> 00:09:40,670
Operation function. Now it's a good idea

236
00:09:40,670 --> 00:09:42,950
to keep the scope of variables as narrow

237
00:09:42,950 --> 00:09:45,410
as possible, and that means not making

238
00:09:45,410 --> 00:09:47,090
them available in places where they're

239
00:09:47,090 --> 00:09:49,370
not needed. That way, they can't be

240
00:09:49,370 --> 00:09:51,560
accidentally changed by code that

241
00:09:51,560 --> 00:09:52,820
shouldn't be touching them in the first

242
00:09:52,820 --> 00:09:55,730
place. So what I'm going to do is, on line

243
00:09:55,730 --> 00:09:58,150
17, I'm going to delete that definition -

244
00:09:58,150 --> 00:10:02,000
the declaration for operand2. Now

245
00:10:02,000 --> 00:10:03,500
the first place it's used in perform

246
00:10:03,500 --> 00:10:05,780
Operation, is to give it the value of the

247
00:10:05,780 --> 00:10:09,020
value parameter. So let's just scroll down

248
00:10:09,020 --> 00:10:11,570
to that code again, and you can see there's

249
00:10:11,570 --> 00:10:12,980
the first time it's been used, currently

250
00:10:12,980 --> 00:10:13,460
on line

251
00:10:13,460 --> 00:10:16,580
87. So there's actually no need to use a

252
00:10:16,580 --> 00:10:19,670
separate variable at all. We can just

253
00:10:19,670 --> 00:10:21,680
change all the places where it's used in

254
00:10:21,680 --> 00:10:24,980
the method to use value instead - value

255
00:10:24,980 --> 00:10:28,130
being an argument to this function. So

256
00:10:28,130 --> 00:10:30,560
I'm going to go ahead and do that. So I'm

257
00:10:30,560 --> 00:10:32,410
going to delete this line completely,

258
00:10:32,410 --> 00:10:35,540
leaving the if. Now we've got these

259
00:10:35,540 --> 00:10:37,190
errors with operand2 - we just need to

260
00:10:37,190 --> 00:10:43,460
change operand2 to be value instead. So

261
00:10:43,460 --> 00:10:44,540
I'm just going to do that. I'm just going

262
00:10:44,540 --> 00:10:46,250
to literally change all of these, by

263
00:10:46,250 --> 00:10:52,520
selecting them and pasting value. Okay.

264
00:10:52,520 --> 00:10:55,040
And you can see we've got a little green

265
00:10:55,040 --> 00:10:57,260
box here now, which means there's no errors,

266
00:10:57,260 --> 00:10:59,510
as such, and we've fixed all those errors. And

267
00:10:59,510 --> 00:11:01,460
I think you'd agree, that's a lot tidier

268
00:11:01,460 --> 00:11:03,260
and it also makes the code easier to

269
00:11:03,260 --> 00:11:05,600
read. Now in fact,

270
00:11:05,600 --> 00:11:07,190
Kotlin's got another way of

271
00:11:07,190 --> 00:11:09,440
writing the code, that we've currently

272
00:11:09,440 --> 00:11:13,430
got here on line 93; the if value equals

273
00:11:13,430 --> 00:11:16,130
equals 0.0. Now these lint checks

274
00:11:16,130 --> 00:11:17,990
are changing all the time but as of the

275
00:11:17,990 --> 00:11:19,759
time I'm recording this, there

276
00:11:19,759 --> 00:11:21,470
is a suggestion that Assignment can be

277
00:11:21,470 --> 00:11:25,250
lifted out of if. So as you can see, there

278
00:11:25,250 --> 00:11:27,319
is a suggestion now; Assignment can be

279
00:11:27,319 --> 00:11:30,110
lifted out of if. And I'll just select that

280
00:11:30,110 --> 00:11:32,180
again - I'll do the Command F1 so we

281
00:11:32,180 --> 00:11:34,040
can see it on the screen there. And

282
00:11:34,040 --> 00:11:35,600
again, you notice I can click on this line

283
00:11:35,600 --> 00:11:38,540
of code, this little tick mark on the

284
00:11:38,540 --> 00:11:40,610
right-hand side - the right-hand menu, this

285
00:11:40,610 --> 00:11:42,740
little check - and it goes directly to the

286
00:11:42,740 --> 00:11:45,440
line of code. Now, what we can then

287
00:11:45,440 --> 00:11:47,620
do, is we can click on the light bulb and

288
00:11:47,620 --> 00:11:50,930
click on Lift assignment out of if, and

289
00:11:50,930 --> 00:11:52,970
you can see it's actually changed the

290
00:11:52,970 --> 00:11:54,980
code for us. So after clicking on the

291
00:11:54,980 --> 00:11:56,899
line of code, we actually get this

292
00:11:56,899 --> 00:11:59,240
different assignment. We've got the

293
00:11:59,240 --> 00:12:01,759
double quotes and the slash and then the

294
00:12:01,759 --> 00:12:04,970
dash greater than sign, operand1 equals

295
00:12:04,970 --> 00:12:08,240
if parenthesis, value equals 0.0

296
00:12:08,240 --> 00:12:10,699
parenthesis, and then the code block. Then

297
00:12:10,699 --> 00:12:12,949
we've got the double NaN else operand1,

298
00:12:12,949 --> 00:12:15,889
where we're dividing it by value. This

299
00:12:15,889 --> 00:12:17,810
is a lot more idiomatic Kotlin, rather

300
00:12:17,810 --> 00:12:20,420
than Java. Now you may have another

301
00:12:20,420 --> 00:12:23,300
warning, on the result, the result.set

302
00:12:23,300 --> 00:12:27,139
Text line - this line here. It's possible

303
00:12:27,139 --> 00:12:29,000
you'll see a warning - of course, that's

304
00:12:29,000 --> 00:12:30,350
right at the end of the perform

305
00:12:30,350 --> 00:12:32,720
Operation function. And it's not really a

306
00:12:32,720 --> 00:12:34,550
good idea to use toString to display

307
00:12:34,550 --> 00:12:36,550
numbers, because it doesn't really handle

308
00:12:36,550 --> 00:12:39,139
internationalization. What that means is,

309
00:12:39,139 --> 00:12:41,149
the numbers will always display with

310
00:12:41,149 --> 00:12:43,189
a decimal point - even in countries like

311
00:12:43,189 --> 00:12:45,380
France, for example, where a comma is used

312
00:12:45,380 --> 00:12:48,560
instead to separate decimals. But we're

313
00:12:48,560 --> 00:12:50,290
not really yet ready to talk about

314
00:12:50,290 --> 00:12:53,000
internationalization at this stage. So if

315
00:12:53,000 --> 00:12:54,589
you do get that warning, just ignore it

316
00:12:54,589 --> 00:12:55,040
for now.

317
00:12:55,040 --> 00:12:57,620
And let's just test the app one more

318
00:12:57,620 --> 00:13:13,220
time before we finish the video.

319
00:13:13,220 --> 00:13:15,180
Alright, that's working nicely and I'll

320
00:13:15,180 --> 00:13:16,500
just go into landscape and just check

321
00:13:16,500 --> 00:13:25,800
that's still working. That's working nicely

322
00:13:25,800 --> 00:13:28,350
as well. Alright, so you'll find the

323
00:13:28,350 --> 00:13:29,610
source code for this app in the

324
00:13:29,610 --> 00:13:31,350
resources section for this video. And

325
00:13:31,350 --> 00:13:33,120
before I put it up there, what I'm going

326
00:13:33,120 --> 00:13:35,519
to do is - I'll just go back to portrait

327
00:13:35,519 --> 00:13:38,160
mode there - back to the code, and I'm

328
00:13:38,160 --> 00:13:40,019
going to go up to the code menu and

329
00:13:40,019 --> 00:13:42,589
click on Reform, select Reformat Code.

330
00:13:42,589 --> 00:13:44,730
And you can see it didn't do much - it just

331
00:13:44,730 --> 00:13:47,279
reformatted things - and I suggest that

332
00:13:47,279 --> 00:13:49,500
you do the same with your code. Then if

333
00:13:49,500 --> 00:13:51,089
you need to use Android Studio to

334
00:13:51,089 --> 00:13:53,310
compare it to mine, the diff tools that

335
00:13:53,310 --> 00:13:54,750
we've talked about previously will have

336
00:13:54,750 --> 00:13:56,639
an easier time of it, and you should get

337
00:13:56,639 --> 00:13:59,040
better results. Now in the next video,

338
00:13:59,040 --> 00:14:00,240
we're going to fix a bug in the

339
00:14:00,240 --> 00:14:01,920
calculator app when it changes

340
00:14:01,920 --> 00:14:04,470
orientation. Well when I say we, I mean

341
00:14:04,470 --> 00:14:06,120
you, because the next video is a

342
00:14:06,120 --> 00:14:08,399
challenge. The bug is quite subtle, so

343
00:14:08,399 --> 00:14:09,930
don't worry if you don't spot it. Al

344
00:14:09,930 --> 00:14:13,940
right, so I'll see you in the next video.

