OK so we've implemented the Serializable interface to pass our photo objects in a bundle. Now
the received wisdom on the Internet is that you shouldn't use Serializable on Android because it's slow.
Now the advice you'll generally find, is to use parcelable instead.
Now the situation is not really that straightforward.
In fact, Serializable can be faster than parcelable in some cases, especially when fully implemented as
we've done in the previous video.
I'm going to come back to that later. For now though,
let's see how easy Android Studio makes it, to implement parcelable. So in our photo class,
we're going to go ahead and delete everything except the toString function. If you recall that's the one
at the top. So we're going to go down and delete that, delete those
three methods there.
I'm also going to delete the companion object.
So we need a toString but everything else after it has to go,
which you saw that I've done.
So we end up now with
again, a very small simple class.
Now our class already has the Serializable interface in its declaration, but we're not getting the
error we got earlier, because the import's still present at the top of the file, and you can see up there on line
3. Alright so I'm going to delete that import now, and we're now getting this error appearing here. Basically
Serializable's now highlighted in red,
and if I hover over it, the error we're getting is "Cannot access Serializable.
It is internal in kotlin.io". And previously in the previous video when we were working with Serializable,
we didn't actually get the exact error, but that's because I selected the import. You saw me select the
class, and that automatically added the import.
But now that we're getting this error, "Cannot access Serializable. It is internal in kotlin.io". Now
that may well change when Kotlin provides its own Serializable mechanism.
I mentioned that earlier, and you can find a discussion about adding serialization to the language.
I'm going to quickly show you that link.
So as you can see as of October 2016, that's what they're working on,
and things are moving on and it's actually now a project on GitHub.
So it's described as highly experimental as at the time that I'm recording this, but it's worth keeping
an eye on it anyway.
Now in any event we're not going to worry about the error, because we've already seen how to fix it - just
add the import manually.
What we're going to do instead, is to use the lightbulb to choose add parcelable implementation.
So I'm going to go back to Android Studio, and click in here. Select the light bulb,
and you can see over here we've got the option to Add Parcelable Implementation. If I do that, Android Studio has automatically
generated all the code we need to implement the parcelable interface.
So what I do need to do though is delete Serializable,
so I'm going to delete that now.
So one reason, I guess, for preferring Serializable is the added complexity of parcelable, but this
is pretty cool. Android Studio did generate everything we need automatically, and you can see that's created
various functions there,
to make it a lot easier for us to actually get this to work, and automatically dealing with the various
properties as well.
Now I'm not going to go into great detail about parcelable.
You can see that there's a write to parcelable function, that writes our photo properties to a parcel,
and a constructor that reads them back again,
constructor up here on line 13.
There's also a companion object, you can see further on down, that implements the parcelable creator interface.
So what should be clear though, is that you can see that parcelable is more complicated than serializable.
Now it's certainly a lot more complicated than the very basic Serializable implementation that we started
off with.
So let's actually see it working before talking more about it.
And you saw that the code generated left Serializable in there, but I've actually since removed that
now.
Now we do need to make a small change to our photo details activity in the onCreate function.
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
using Serializable, and instead what we're going to do is type val photo equals intent dot extras
dot getParcelable.
There we want to select in a diamond opereator, Photo,
then parentheses photo underscore transfer as Photo.
So it's only a small change.
We use getParcelable instead of getSerializable.
That's not surprising obviously, considering the change we made to the photo class.
Now you may get a suggestion from Android Studio, that you can remove explicit type arguments after
that call to get
Parcelable. You can see there if I hover over it, "Remove explicit type arguments".
Now I'm recording this with Version 1.1.61 of the Kotlin plugin, but Jetbrains have now released
version 1.2.0. Now that version,
1.2.0 is able to in further type, without explicitly specifying photo here. So in other words,
this part here.
Now Android Studio hasn't yet updated to that version of Kotlin,
but when it does you'll be able to remove that portion of the code.
Alright so the real test at this point is,
does this work.
So let's actually try running it.
So once the app's started
we're going to long tap a thumbnail, and see whether our full photograph is displayed.
Alright so I'm going to long tap an image now,
and we can see it successfully displays the full photograph.
So at this point you can now choose which interface you want to use when passing objects around in bundles.
We've seen how to create a very basic serializable implementation, a fully implemented Serializable, and now
parcelable. And were you astounded by how much faster our photographs display, now that you're using the parcelable
interface.
Well we did some rough timings, and the difference comes down to one or two milliseconds.
Now your users generally won't notice a two millisecond delay when they've tapped a thumbnail, but remember to keep
these things in perspective, and consider whether there really is a performance problem before you try
to fix it.
Now in this situation, it's really not worth using anything other than the very basic Serializable implementation,
but there will be times though, when one or two milliseconds can be significant of course.
Serializing thousands of objects will multiply that difference into seconds rather than milliseconds,
and users do certainly notice delays of a second or more. But be careful though, because it turns out that Serializable,
when correctly implemented, often outperforms parcelable if the same type of object is serialized many
times.
So the received wisdom on the Internet is that Serializable is slower, and that the speed difference
is significant on a mobile platform such as Android.
But that's not necessarily true, and parcelable in fact can be slower than serializable.
So how do you know which to use.
Well unfortunately that's not something I can really tell you.
The best advice I can give is to implement both interfaces, and then do some timing to see which one
performs better with your particular objects.
Now parcelable will often perform better than Serializable, but that really depends on how complex
your objects are.
Now lists of objects for example, may be serialized faster using the Serializable implementation, and
it also depends on how complicated the objects in the list are.
Now if performance becomes an issue, then you certainly want to try both approaches.
Now once you've worked out the logic of using one interface, the code will look very similar for the
other one.
So if we compare the write to parcel function we've got at the moment, back in photo, with the previous write object
function that we had earlier,
and what I'll do is just paste that in, paste in a commented out version.
There's our write
Object function, when we're using serializable.
You can see them both together there. Now the read object function was only slightly more complicated
than the parcelable constructor, and that's only because it specifies the property names.
So in other words you're not creating a huge amount of extra work by testing both approaches.
Alright so we'll just undo that
change there so that code's no longer in their file, and I'll stop the video here. And in the next few videos
we're going to move on to material design, specifically what it is and how we can use it to make our apps
look a lot cooler, and consistent with the general look and feel of Android.
So I'll see you in the next video.