I'm trying to come to grips with the onSaveInstanceState
method in class View
(not the one in class Activity
). That method does return a Parcelable
. I derived my own View
from ViewGroup
and overrode that method to save my own state. But when the state was to be saved I got an exception:
java.lang.IllegalStateException:
Derived class did not call super.onSaveInstanceState()
That is true enough, but simply calling that method doesn't seem enough to me. So how should I do this? If the method would get passed a Parcel
to write to, I could simply pass that same parcel to the super class, so things would get written sequentially. But this is a return value.
Should I include this returned object as a member of my own Parcelable
representation, and use Parcel.writeParcelable
to marshal it along with my own data if needed? Or is there some better way to handle parent invocation and chaining of parcelable objects? If so, what class loader should I use when loading the instance state of the super class?
Since zapl didn't turn his comment into an answer, I'm doing so.
The canonical way to accomplish this is by having your own class for saved data derived from
View.BaseSavedState
, which in turn is derived fromAbsSavedState
. You can call theonSaveInstance
handler of the parent class and pass the resulting object to the constructor of your own class. When restoring the data,getSuperState
gives the instance aimed at the parent class.A typical code example could look like this:
The above was adapted from this presentation by Cyril Mottier, but should also be a close match to how designers intended the use of this class in general.
Although the mentioned described above seems to be preferred, behind the scenes it does rely on
writeParcelable
as well. So if there are reasons to not use that base class, simply callingwriteParcelable
to store the state of the super class should be fine.The current implementation of
AbsSavedState
does usenull
as the class loader argument, causing the use of the default class loader. However, that line of code is marked with aFIXME
comment, so it might change one day.