Instant Run and Serializable
When Google announced Instant Run a year or so ago, I was skeptical. The objective of faster builds is wonderful. The specific technique — runtime classloader games — struck me as a “death by 1000 paper cuts” solution. Most of the time, it probably works fine. Sometimes, it might not, due to peculiarities in the code or resources.
Xav Ducrohet points out one such peculiarity:
Many developers make a class
Serializable simply by adding
implements Serializable to the class definition. That’s sloppy, but
it works in some situations. The better approach is to also add a
— or, as
put it, “It is highly recommended to use an explicit serialVersionUID field to avoid compatibility issues.”
If you skip
serialVersionUID, the VM generates one for you,
“based on various aspects of the class”. As it turns out, the generated
serialVersionUID will be different for a version of your class
injected via Instant Run, compared with the same class packaged in your
APK. If you use
Serializable for persistence, with
and kin, objects saved when running under Instant Run may not be compatible when
you try loading them with the APK edition of your
class, and vice versa.
Hopefully this specific problem affects few developers, as hopefully few
Serializable for persistence. If you have classes in
a library that are
Serializable, please add
serialVersionUID if you
have not done so already, as while you might not be persisting instances
of your classes, users of your library might. With luck,
the tools might complain more when this is missing.
Stuck on an Android problem? Subscribers have access to live office hours chats with Mark Murphy, to help you work through your challenges!