Question

I had the following (minor but nagging!) problem: I’ve got a PreferenceActivity with a XML preference hierarchy definition with “sub PreferenceScreens“, i. e. several PreferenceScreens under the top level PreferenceScreen, and when the user clicks them, a sub hierarchy of other preferences is being displayed.

If I have displayed such a sub PreferenceScreen and the orientation is being changed from portrait to landscape or vice versa, the main PreferenceScreen is displayed afterwards. Which means: The preference hierarchy state was not being restored properly. I would expect the sub PreferenceScreen to be displayed after the orientation change, just as before the orientation change.

Now I found out that the problem can be solved by assigning any random key (e. g. “dummy”) to the sub PreferenceScreen. Which does not make any sense! Why would a PreferenceScreen ever need a key (except as a workaround for the above problem)?

My actual question: Is this behaviour a bug in the framework class(es)? If not: Can someone explain me how that makes sense?

My example code:

HelloAndroid.java:

public class HelloAndroid extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        Button view = new Button(this);
        view.setText("Start Preference");
        final Context ctx = this;
        view.setOnClickListener(new View.OnClickListener() {
            public void onClick(View v) {
                startActivity(new Intent(ctx, HelloPreferenceActivity.class));
            }
        });
        this.setContentView(view);
    }

HelloPreferenceActivity.java:

public class HelloPreferenceActivity extends PreferenceActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        addPreferencesFromResource(R.xml.preferences);
    }
}

preference.xml:

<?xml version="1.0" encoding="utf-8"?>
<PreferenceScreen xmlns:android="http://schemas.android.com/apk/res/android">
    <CheckBoxPreference android:key="examplePref"
        android:title="ExamplePref">
    </CheckBoxPreference>
    <PreferenceScreen android:title="SubScreen..."
        android:key="dummy"> <!-- works with, does not work without this key -->
        <CheckBoxPreference android:key="exPrefSubScreen"
            android:title="ExPrefSubScreen">
        </CheckBoxPreference>
    </PreferenceScreen>
</PreferenceScreen>

Answer 1

This is by design, the state of Preference is associated with its key. If Preference has no key then it will not be able to save/restore its state.

The similar behavior can be found in views withing layouts. If view has no id specified for it, it will not be able to restore state after configuration change.

And to back my words up, here is an example of how Preference saves its state:

void dispatchSaveInstanceState(Bundle container) {
    if (hasKey()) {
        mBaseMethodCalled = false;
        Parcelable state = onSaveInstanceState();
        if (!mBaseMethodCalled) {
            throw new IllegalStateException(
                    "Derived class did not call super.onSaveInstanceState()");
        }
        if (state != null) {
            container.putParcelable(mKey, state);
        }
    }
}

And here is how Preference tries to restore its state:

void dispatchRestoreInstanceState(Bundle container) {
    if (hasKey()) {
        Parcelable state = container.getParcelable(mKey);
        if (state != null) {
            mBaseMethodCalled = false;
            onRestoreInstanceState(state);
            if (!mBaseMethodCalled) {
                throw new IllegalStateException(
                        "Derived class did not call super.onRestoreInstanceState()");
            }
        }
    }
}