1
00:00:04,970 --> 00:00:10,850
OK so we've implemented the Serializable interface to pass our photo objects in a bundle. Now

2
00:00:10,860 --> 00:00:16,750
the received wisdom on the Internet is that you shouldn't use Serializable on Android because it's slow.

3
00:00:17,040 --> 00:00:21,580
Now the advice you'll generally find, is to use parcelable instead.

4
00:00:21,630 --> 00:00:24,140
Now the situation is not really that straightforward.

5
00:00:24,330 --> 00:00:30,960
In fact, Serializable can be faster than parcelable in some cases, especially when fully implemented as

6
00:00:30,960 --> 00:00:33,000
we've done in the previous video.

7
00:00:33,150 --> 00:00:35,450
I'm going to come back to that later. For now though,

8
00:00:35,490 --> 00:00:43,090
let's see how easy Android Studio makes it, to implement parcelable. So in our photo class,

9
00:00:43,350 --> 00:00:47,870
we're going to go ahead and delete everything except the toString function. If you recall that's the one

10
00:00:47,900 --> 00:00:50,700
at the top. So we're going to go down and delete that, delete those

11
00:00:53,610 --> 00:00:55,460
three methods there.

12
00:00:56,940 --> 00:01:00,260
I'm also going to delete the companion object.

13
00:01:01,200 --> 00:01:04,129
So we need a toString but everything else after it has to go,

14
00:01:04,140 --> 00:01:05,420
which you saw that I've done.

15
00:01:05,640 --> 00:01:06,550
So we end up now with

16
00:01:06,570 --> 00:01:08,870
again, a very small simple class.

17
00:01:09,030 --> 00:01:14,340
Now our class already has the Serializable interface in its declaration, but we're not getting the

18
00:01:14,360 --> 00:01:20,180
error we got earlier, because the import's still present at the top of the file, and you can see up there on line

19
00:01:20,190 --> 00:01:27,980
3. Alright so I'm going to delete that import now, and we're now getting this error appearing here. Basically

20
00:01:27,990 --> 00:01:30,250
Serializable's now highlighted in red,

21
00:01:30,300 --> 00:01:34,140
and if I hover over it, the error we're getting is "Cannot access Serializable.

22
00:01:34,230 --> 00:01:40,410
It is internal in kotlin.io". And previously in the previous video when we were working with Serializable,

23
00:01:40,680 --> 00:01:46,380
we didn't actually get the exact error, but that's because I selected the import. You saw me select the

24
00:01:46,380 --> 00:01:49,160
class, and that automatically added the import.

25
00:01:49,160 --> 00:01:54,770
But now that we're getting this error, "Cannot access Serializable. It is internal in kotlin.io". Now

26
00:01:54,780 --> 00:01:59,480
that may well change when Kotlin provides its own Serializable mechanism.

27
00:01:59,550 --> 00:02:04,660
I mentioned that earlier, and you can find a discussion about adding serialization to the language.

28
00:02:04,680 --> 00:02:14,520
I'm going to quickly show you that link.

29
00:02:14,630 --> 00:02:18,140
So as you can see as of October 2016, that's what they're working on,

30
00:02:18,410 --> 00:02:21,370
and things are moving on and it's actually now a project on GitHub.

31
00:02:28,890 --> 00:02:33,390
So it's described as highly experimental as at the time that I'm recording this, but it's worth keeping

32
00:02:33,390 --> 00:02:34,650
an eye on it anyway.

33
00:02:35,060 --> 00:02:39,630
Now in any event we're not going to worry about the error, because we've already seen how to fix it - just

34
00:02:39,630 --> 00:02:40,900
add the import manually.

35
00:02:41,220 --> 00:02:47,890
What we're going to do instead, is to use the lightbulb to choose add parcelable implementation.

36
00:02:48,060 --> 00:02:56,600
So I'm going to go back to Android Studio, and click in here. Select the light bulb,

37
00:02:56,760 --> 00:03:05,160
and you can see over here we've got the option to Add Parcelable Implementation. If I do that, Android Studio has automatically

38
00:03:05,670 --> 00:03:09,260
generated all the code we need to implement the parcelable interface.

39
00:03:09,570 --> 00:03:11,680
So what I do need to do though is delete Serializable,

40
00:03:11,790 --> 00:03:14,050
so I'm going to delete that now.

41
00:03:14,750 --> 00:03:20,310
So one reason, I guess, for preferring Serializable is the added complexity of parcelable, but this

42
00:03:20,310 --> 00:03:26,550
is pretty cool. Android Studio did generate everything we need automatically, and you can see that's created

43
00:03:26,580 --> 00:03:28,080
various functions there,

44
00:03:28,350 --> 00:03:33,090
to make it a lot easier for us to actually get this to work, and automatically dealing with the various

45
00:03:33,180 --> 00:03:34,640
properties as well.

46
00:03:34,780 --> 00:03:37,970
Now I'm not going to go into great detail about parcelable.

47
00:03:38,130 --> 00:03:43,200
You can see that there's a write to parcelable function, that writes our photo properties to a parcel,

48
00:03:43,260 --> 00:03:45,270
and a constructor that reads them back again,

49
00:03:45,520 --> 00:03:48,030
constructor up here on line 13.

50
00:03:48,210 --> 00:03:54,910
There's also a companion object, you can see further on down, that implements the parcelable creator interface.

51
00:03:55,200 --> 00:04:01,550
So what should be clear though, is that you can see that parcelable is more complicated than serializable.

52
00:04:01,670 --> 00:04:07,500
Now it's certainly a lot more complicated than the very basic Serializable implementation that we started

53
00:04:07,500 --> 00:04:08,460
off with.

54
00:04:08,460 --> 00:04:12,020
So let's actually see it working before talking more about it.

55
00:04:12,540 --> 00:04:18,000
And you saw that the code generated left Serializable in there, but I've actually since removed that

56
00:04:18,000 --> 00:04:18,740
now.

57
00:04:18,990 --> 00:04:24,730
Now we do need to make a small change to our photo details activity in the onCreate function.

58
00:04:26,380 --> 00:04:31,140
So what we're going to do is go back to that. We're going to comment out line 15 day because we're no longer

59
00:04:31,150 --> 00:04:38,860
using Serializable, and instead what we're going to do is type val photo equals intent dot extras

60
00:04:39,120 --> 00:04:43,260
dot getParcelable.

61
00:04:43,510 --> 00:04:46,500
There we want to select in a diamond opereator, Photo,

62
00:04:47,180 --> 00:04:54,440
then parentheses photo underscore transfer as Photo.

63
00:04:55,870 --> 00:04:57,230
So it's only a small change.

64
00:04:57,290 --> 00:05:00,710
We use getParcelable instead of getSerializable.

65
00:05:00,710 --> 00:05:04,570
That's not surprising obviously, considering the change we made to the photo class.

66
00:05:04,580 --> 00:05:10,820
Now you may get a suggestion from Android Studio, that you can remove explicit type arguments after

67
00:05:10,820 --> 00:05:12,440
that call to get

68
00:05:12,440 --> 00:05:18,700
Parcelable. You can see there if I hover over it, "Remove explicit type arguments".

69
00:05:18,710 --> 00:05:24,100
Now I'm recording this with Version 1.1.61 of the Kotlin plugin, but Jetbrains have now released

70
00:05:24,100 --> 00:05:26,960
version 1.2.0. Now that version,

71
00:05:26,960 --> 00:05:32,940
1.2.0 is able to in further type, without explicitly specifying photo here. So in other words,

72
00:05:32,930 --> 00:05:33,580
this part here.

73
00:05:36,150 --> 00:05:39,220
Now Android Studio hasn't yet updated to that version of Kotlin,

74
00:05:39,360 --> 00:05:43,300
but when it does you'll be able to remove that portion of the code.

75
00:05:43,670 --> 00:05:45,480
Alright so the real test at this point is,

76
00:05:45,480 --> 00:05:46,670
does this work.

77
00:05:46,680 --> 00:05:48,330
So let's actually try running it.

78
00:05:53,480 --> 00:05:54,750
So once the app's started

79
00:05:54,760 --> 00:05:58,840
we're going to long tap a thumbnail, and see whether our full photograph is displayed.

80
00:06:03,710 --> 00:06:06,000
Alright so I'm going to long tap an image now,

81
00:06:08,180 --> 00:06:12,340
and we can see it successfully displays the full photograph.

82
00:06:12,380 --> 00:06:17,350
So at this point you can now choose which interface you want to use when passing objects around in bundles.

83
00:06:17,570 --> 00:06:24,410
We've seen how to create a very basic serializable implementation, a fully implemented Serializable, and now

84
00:06:24,410 --> 00:06:30,430
parcelable. And were you astounded by how much faster our photographs display, now that you're using the parcelable 

85
00:06:30,440 --> 00:06:31,170
interface.

86
00:06:31,430 --> 00:06:36,030
Well we did some rough timings, and the difference comes down to one or two milliseconds.

87
00:06:36,020 --> 00:06:41,510
Now your users generally won't notice a two millisecond delay when they've tapped a thumbnail, but remember to keep

88
00:06:41,510 --> 00:06:46,310
these things in perspective, and consider whether there really is a performance problem before you try

89
00:06:46,310 --> 00:06:47,410
to fix it.

90
00:06:47,420 --> 00:06:53,710
Now in this situation, it's really not worth using anything other than the very basic Serializable implementation,

91
00:06:53,990 --> 00:06:58,700
but there will be times though, when one or two milliseconds can be significant of course.

92
00:06:58,940 --> 00:07:04,440
Serializing thousands of objects will multiply that difference into seconds rather than milliseconds,

93
00:07:04,580 --> 00:07:11,420
and users do certainly notice delays of a second or more. But be careful though, because it turns out that Serializable,

94
00:07:11,690 --> 00:07:18,530
when correctly implemented, often outperforms parcelable if the same type of object is serialized many

95
00:07:18,530 --> 00:07:19,290
times.

96
00:07:19,640 --> 00:07:24,590
So the received wisdom on the Internet is that Serializable is slower, and that the speed difference

97
00:07:24,680 --> 00:07:28,030
is significant on a mobile platform such as Android.

98
00:07:28,160 --> 00:07:34,150
But that's not necessarily true, and parcelable in fact can be slower than serializable.

99
00:07:34,160 --> 00:07:35,830
So how do you know which to use.

100
00:07:36,150 --> 00:07:38,750
Well unfortunately that's not something I can really tell you.

101
00:07:38,990 --> 00:07:45,080
The best advice I can give is to implement both interfaces, and then do some timing to see which one

102
00:07:45,080 --> 00:07:48,170
performs better with your particular objects.

103
00:07:48,230 --> 00:07:53,360
Now parcelable will often perform better than Serializable, but that really depends on how complex

104
00:07:53,360 --> 00:07:54,530
your objects are.

105
00:07:54,670 --> 00:08:01,170
Now lists of objects for example, may be serialized faster using the Serializable implementation, and

106
00:08:01,160 --> 00:08:04,180
it also depends on how complicated the objects in the list are.

107
00:08:04,430 --> 00:08:08,330
Now if performance becomes an issue, then you certainly want to try both approaches.

108
00:08:09,210 --> 00:08:13,870
Now once you've worked out the logic of using one interface, the code will look very similar for the

109
00:08:13,870 --> 00:08:14,580
other one.

110
00:08:14,890 --> 00:08:21,430
So if we compare the write to parcel function we've got at the moment, back in photo, with the previous write object

111
00:08:21,520 --> 00:08:22,890
function that we had earlier,

112
00:08:23,260 --> 00:08:27,660
and what I'll do is just paste that in, paste in a commented out version.

113
00:08:27,670 --> 00:08:28,210
There's our write

114
00:08:28,210 --> 00:08:31,090
Object function, when we're using serializable.

115
00:08:31,090 --> 00:08:35,590
You can see them both together there. Now the read object function was only slightly more complicated

116
00:08:35,890 --> 00:08:41,059
than the parcelable constructor, and that's only because it specifies the property names.

117
00:08:41,320 --> 00:08:46,340
So in other words you're not creating a huge amount of extra work by testing both approaches.

118
00:08:46,410 --> 00:08:48,170
Alright so we'll just undo that

119
00:08:48,180 --> 00:08:53,600
change there so that code's no longer in their file, and I'll stop the video here. And in the next few videos

120
00:08:53,590 --> 00:08:59,440
we're going to move on to material design, specifically what it is and how we can use it to make our apps

121
00:08:59,440 --> 00:09:03,240
look a lot cooler, and consistent with the general look and feel of Android.

122
00:09:03,260 --> 00:09:04,530
So I'll see you in the next video.