覆盖onSaveInstanceState [英] Overriding onSaveInstanceState

查看:148
本文介绍了覆盖onSaveInstanceState的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正试图了解View 中的onSaveInstanceState方法(不是Activity 中的那个).该方法确实返回 Parcelable .我从 View 派生了自己的内容: //developer.android.com/reference/android/view/ViewGroup.html"rel =" nofollow> ViewGroup 并覆盖该方法以保存我自己的状态.但是当要保存状态时,我遇到了一个例外:

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()

这是真的,但仅调用该方法对我来说似乎还不够.那我该怎么做呢?如果该方法可以通过 Parcel 写入,可以简单地将同一包裹传递给超类,因此事情将按顺序编写.但这是一个返回值.

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.

我应该将此返回的对象包含为我自己的Parcelable表示形式的成员,并使用

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?

推荐答案

由于zapl并未将他的评论转化为答案,所以我这样做了.

有没有更好的方法来处理父级调用和可包裹对象的链接?

is there some better way to handle parent invocation and chaining of parcelable objects?

完成此操作的规范方法是拥有一个自己的类,用于保存从 .您可以调用父类的onSaveInstance处理程序,并将结果对象传递给您自己的类的构造函数.恢复数据时,getSuperState给出针对父类的实例.

The canonical way to accomplish this is by having your own class for saved data derived from View.BaseSavedState, which in turn is derived from AbsSavedState. You can call the onSaveInstance 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:

static class SavedState extends View.BaseSavedState {
  // include own data members here
  public SavedState(Parcelable superState) {
    super(superState);
  }
  private SavedState(Parcel in) {
    super(in);
    // read own data here
  }
  @Override public void writeToParcel(Parcel out, int flags) {
    super.writeToParcel(out, flags);
    // write own data here
  }
  public static final Parcelable.Creator<SavedState> CREATOR =
      new Parcelable.Creator<SavedState>() {
    public SavedState createFromParcel(Parcel in) { return SavedState(in); }
    public SavedState[] newArray(int size) { return new SavedState[size]; }
  };
}

@Override public Parcelable onSaveInstanceState() {
  SavedState state = new SavedState(super.onSaveInstanceState());
  // set data members here
  return state;
}

@Override public void onRestoreInstanceState(Parcelable parcelable) {
  SavedState state = (SavedState)parcelable;
  super.onRestoreInstanceState(state.getSuperState());
  // restore from data members here
}

以上内容改编自Cyril Mottier的此演示文稿 ,但也应该与设计人员通常打算使用此类的方式紧密匹配.

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.

我应该将此返回的对象包含为我自己的Parcelable表示形式的成员,并使用

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?

尽管上述提到的内容似乎是首选,但幕后确实也依赖writeParcelable.因此,如果有理由不使用该基类,只需调用writeParcelable来存储超类的状态就可以了.

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 calling writeParcelable to store the state of the super class should be fine.

在加载超类的实例状态时应该使用什么类加载器?

what class loader should I use when loading the instance state of the super class?

当前的实现AbsSavedState 确实使用null作为类加载器参数,从而导致使用默认的类加载器.但是,该行代码带有FIXME注释,因此可能有一天会更改.

The current implementation of AbsSavedState does use null as the class loader argument, causing the use of the default class loader. However, that line of code is marked with a FIXME comment, so it might change one day.

这篇关于覆盖onSaveInstanceState的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆