1
00:00:05,150 --> 00:00:06,150
Welcome back.

2
00:00:06,150 --> 00:00:09,650
Shortly after we developed the changes for the videos in this section,

3
00:00:10,050 --> 00:00:11,650
Google made another change.

4
00:00:12,050 --> 00:00:15,450
In fact we've made several updates to this section

5
00:00:15,450 --> 00:00:18,810
because of changes in the time between developing the code

6
00:00:18,810 --> 00:00:20,310
and recording the videos.

7
00:00:20,970 --> 00:00:23,670
That's how quickly things change in this environment.

8
00:00:24,470 --> 00:00:29,430
I'm making this video because of a change that affects our AppDialog class.

9
00:00:30,530 --> 00:00:33,130
We've got a serious warning in AppDialog

10
00:00:37,130 --> 00:00:40,830
on line 65. This change is quite a good one

11
00:00:41,080 --> 00:00:44,970
because it means we can use the bang bang operator less often now.

12
00:00:45,370 --> 00:00:48,030
What google have done is added a

13
00:00:48,030 --> 00:00:51,930
require context method to the AndroidxFragment class.

14
00:00:52,630 --> 00:00:56,230
We've already established that the context can't be null

15
00:00:56,230 --> 00:00:57,630
at this point in our code.

16
00:00:58,130 --> 00:01:00,730
But we still had to use the bang bang operator,

17
00:01:00,730 --> 00:01:03,030
so the compiler would compile the code.

18
00:01:04,019 --> 00:01:07,020
I don't like using bang bang. I hope you don't either.

19
00:01:07,680 --> 00:01:09,980
Google have now given us an alternative.

20
00:01:10,640 --> 00:01:13,340
Click on context on line 65,

21
00:01:13,340 --> 00:01:17,440
and accept the tool tip suggestion to replace with

22
00:01:17,440 --> 00:01:19,040
requireContext.

23
00:01:20,580 --> 00:01:22,880
This removes the need to use bang bang.

24
00:01:23,240 --> 00:01:24,740
But be very careful here,

25
00:01:25,340 --> 00:01:29,440
if the context had been null at this point then our code would have crashed.

26
00:01:30,340 --> 00:01:34,340
Using context bang bang didn't prevent the code from crashing

27
00:01:34,340 --> 00:01:38,340
it was a way for us to let the compiler know that the context

28
00:01:38,340 --> 00:01:39,640
wouldn't be null.

29
00:01:39,940 --> 00:01:42,140
We were sure context couldn't be null.

30
00:01:42,740 --> 00:01:45,300
Using require context does the same thing.

31
00:01:45,800 --> 00:01:49,100
If the context is null, our code will crash.

32
00:01:49,900 --> 00:01:52,900
The RequireContext function will throw in

33
00:01:52,900 --> 00:01:56,700
illegal state exception if the context is null.

34
00:01:57,900 --> 00:02:01,560
All we've really done is replace one exception with another.

35
00:02:02,220 --> 00:02:05,220
We'll now get illegal state exception

36
00:02:05,220 --> 00:02:08,220
whereas before we would have got null pointer exception.

37
00:02:09,020 --> 00:02:13,620
Using RequiredContext doesn't somehow magically give us a context

38
00:02:13,620 --> 00:02:17,120
when one isn't available whether we can get a context or not

39
00:02:17,420 --> 00:02:20,120
depends on where we are in the fragment lifecycle,

40
00:02:20,620 --> 00:02:24,870
if the fragment isn't attached to its activity context will be null.

41
00:02:25,370 --> 00:02:28,370
Remember the context is the activity.

42
00:02:29,870 --> 00:02:33,530
RequireContext just gives us a nicer way to get a context

43
00:02:33,530 --> 00:02:35,130
while keeping the compiler happy.

44
00:02:35,900 --> 00:02:38,200
It doesn't prevent the app from crashing

45
00:02:38,500 --> 00:02:41,500
if we try to use the context before it's available.

46
00:02:42,000 --> 00:02:45,000
Control click on the RequireContext function

47
00:02:46,880 --> 00:02:49,180
to view the source code.

48
00:02:49,580 --> 00:02:52,880
As you can see it throws an exception if the context is null.

49
00:02:53,280 --> 00:02:57,080
All we've done is appease the compiler without having to use bang bang.

50
00:02:57,480 --> 00:02:59,580
It's still our responsibility

51
00:02:59,580 --> 00:03:03,280
to ensure that we don't try to use the context if it might be null.

52
00:03:03,830 --> 00:03:07,030
I'll say that again, using RequireContext

53
00:03:07,030 --> 00:03:08,930
doesn't prevent our code from crashing.

54
00:03:09,590 --> 00:03:11,590
We'll get a more useful error message, that's all.

55
00:03:12,390 --> 00:03:16,390
As you can see in the source code, the error message will tell us that our fragment

56
00:03:16,390 --> 00:03:17,990
isn't attached to a context.

57
00:03:18,690 --> 00:03:20,290
We'll still get a crash.

58
00:03:20,290 --> 00:03:23,190
Apart from the slightly more informative error message,

59
00:03:23,190 --> 00:03:26,190
the only advantage of using required context

60
00:03:26,190 --> 00:03:28,890
is that we can avoid using the bang bang operator.

61
00:03:29,880 --> 00:03:33,080
That can be useful if your source code system runs scripts

62
00:03:33,080 --> 00:03:36,880
to validate the code you check in and tests for bang bang.

63
00:03:37,580 --> 00:03:41,880
As you saw, before I made the change, we had a strong warning.

64
00:03:42,680 --> 00:03:45,980
If you use android studio's source code integration

65
00:03:46,380 --> 00:03:49,380
that would trigger a warning when you try to check the code in.

66
00:03:50,280 --> 00:03:52,980
Okay. I don't want to label the point too much.

67
00:03:52,980 --> 00:03:56,980
I'll finish by talking about a few more required functions that Google

68
00:03:57,380 --> 00:04:00,580
have added. Have a look through this source file fragment.java

69
00:04:00,580 --> 00:04:02,780
and you'll find some more require function.

70
00:04:06,080 --> 00:04:08,780
There's a require activity for when you need to get the

71
00:04:08,780 --> 00:04:11,980
fragments activity and don't want to use the activity

72
00:04:12,480 --> 00:04:16,079
further up in this file around line 676.

73
00:04:16,079 --> 00:04:18,440
There's a RequireArguments function.

74
00:04:18,839 --> 00:04:22,040
Once again, this doesn't guarantee that arguments isn't null.

75
00:04:22,040 --> 00:04:24,040
We can't magically create arguments.

76
00:04:24,400 --> 00:04:28,390
What it does is throw an exception if you try to access the arguments

77
00:04:28,390 --> 00:04:29,490
when the arguments are null.

78
00:04:30,040 --> 00:04:32,400
That's useful in our AppDialogue class.

79
00:04:32,800 --> 00:04:35,400
I'll switch back to it and go to the bottom of the file.

80
00:04:40,200 --> 00:04:42,400
The code's commented out at the moment

81
00:04:42,400 --> 00:04:45,760
but, you can see that we use arguments bang bang

82
00:04:45,760 --> 00:04:47,760
in the OnCancel function.

83
00:04:48,660 --> 00:04:50,860
When we uncomment that function later,

84
00:04:50,860 --> 00:04:53,660
we'll also change it to use require arguments.

85
00:04:54,210 --> 00:04:57,710
I'll leave the change until then but I wanted to mention it now.

86
00:04:58,510 --> 00:05:02,310
Remember that we've already established that the arguments aren't null.

87
00:05:02,860 --> 00:05:05,560
We do that in the OnCreateDialog function.

88
00:05:06,440 --> 00:05:09,940
If there are no arguments, we throw an exception in line 90.

89
00:05:11,540 --> 00:05:16,140
All right. Now we really are ready to start improving the functionality of our app.

90
00:05:16,640 --> 00:05:18,940
And we'll start that in the next video.

91
00:05:19,490 --> 00:05:22,290
Of course, you should run the app and test it

92
00:05:22,290 --> 00:05:26,290
just to make sure that we haven't broken anything. See you in the next video.

