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 theonSaveInstancehandler of the parent class and pass the resulting object to the constructor of your own class. When restoring the data,getSuperStategives 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
writeParcelableas well. So if there are reasons to not use that base class, simply callingwriteParcelableto store the state of the super class should be fine.The current implementation of
AbsSavedStatedoes usenullas the class loader argument, causing the use of the default class loader. However, that line of code is marked with aFIXMEcomment, so it might change one day.