通过配置更改保留对象的静态模式

Question

I am experienced enough to know about configuration changes. I know how to save and restore the instance state of a View , Activity , Fragment or whatever, and I know that we should rely on that, rather than simply make objects static.

This question is about static ness of a field. In "pure Java" declaring an object as static serves the purpose of having it shared among instances. In the android system, declaring a static field is also a quick way to have it survive configuration changes, when our instance is recreated and its fields are cleared.

Example:

public class FooFragment extends Fragment {

    private static Object sObject;

    public void onViewCreated(View view, Bundle savedInstanceState) {
        if (savedInstanceState == null) {
            sObject = new Object();
            sObject.toString();
        } else {
            sObject.toString();
        }
    }

}

In this case, sObject can be initialized when the fragment is created , and just fetched when the fragment is recreated . Issues arise when our class is not static itself, is designed as a base class, or is an abstract class.

public abstract class BaseFragment extends Fragment {

    protected static Object sObject;
}

public class FooFragment extends BaseFragment {

    public void onViewCreated(View view, Bundle savedInstanceState) {
        if (savedInstanceState == null) {
            sObject = new Object();
            sObject.toString();
        } else {
            sObject.toString();
        }
    }
}

public class BarFragment extends BaseFragment {

    public void onViewCreated(View view, Bundle savedInstanceState) {
        if (savedInstanceState == null) {
            sObject = new Object();
            sObject.toString();
        } else {
            sObject.toString();
        }
    }
}

Now both FooFragment and BarFragment will access (and impredictably use) the same instance of sObject . That is the point of staticness, but is not what we want. We want FooFragment and BarFragment to have their own sObject ; we just want it to survive configuration changes and platform-driven recreation.

Question

How can I design the base class for this goal?

This is what I came up with, but I'm sure there's something better.

public abstract class BaseFragment extends Fragment {

    private static HashMap<String, Object> sObjects;

    public void onViewCreated(View view, Bundle savedInstanceState) {
        if (savedInstanceState == null) {
            Object o = new Object();
            sObjects.put(getClass().getName(), o);
        }
    }

    protected final Object getObject() {
        return sObjects.get(getClass().getName());
    }
}

Basically I keep a static map, indexing by child class name.

Answer 1

Basically, you are implementing a global cache. The fact that you happen to be using it for configuration changes is just a detail. Hence, you need to consider the standard stuff for global caches. For example, consider HashMap<String, WeakReference<Object>> , so if you fail to remove the object from the HashMap due to a coding bug or unhandled exception, the long-term impact will be modest.

In terms of more Android-specific considerations, nothing that goes into that cache should be configuration-dependent, such as the value of a string culled from string resources. These need to be rebuilt, as the configuration change may affect their value.

Also, nothing that goes into that cache should be dependent upon the pre-configuration-change environment, such as views owned by the former activity, to help reduce memory leaks.

While you think that retained fragments are inappropriate, you might consider looking at their implementation, or the implementation of other global caches (eg, Picasso's image cache), for other ideas of what might befall you.

Answer 2

Your method will work if you have a small app. However there are a couple of things that this can make difficult.

1. Memory footprint: Every static instance is retained even if you are not using that screen. As stated above, this is not a big deal if your application is small, but can cause issues if your application grows.

2. Testability: Testing static things is not fun :(

There may be easier ways to achieve your goals.

Option A Load from DB. Basically save as little state as possible (maybe ID of data your are looking at) and load data on orientation change.

Option B Make saving state easier with a library such as IcePick You can save primitives, or create customer converters for objects (eg Use GSON to convert object to JSON).