-> Launcher uses a static instance of it's loader (across
multiple activities) since activities can come and go
(configuration change, eg.) but the data model and loading
is static.
-> Currently, this is not robust to a sequence of events that
looks like onCreate(instance A), onCreate(instance B),
onDestroy(instance B) -- depending on the timing of those
calls.
-> This CL addresses a symptom of the above scenario by not
allowing an older Launcher Activity cancel the loader /
clear the callbacks for a newer Activity.
Bug
17679693
Change-Id: I8ece93e288464b0d578b9669c165b67132d997ed
@Override
public Object onRetainNonConfigurationInstance() {
// Flag the loader to stop early before switching
- mModel.stopLoader();
+ if (mModel.isCurrentCallbacks(this)) {
+ mModel.stopLoader();
+ }
if (mAppsCustomizeContent != null) {
mAppsCustomizeContent.surrender();
}
// Stop callbacks from LauncherModel
LauncherAppState app = (LauncherAppState.getInstance());
- mModel.stopLoader();
- app.setLauncher(null);
+
+ // It's possible to receive onDestroy after a new Launcher activity has
+ // been created. In this case, don't interfere with the new Launcher.
+ if (mModel.isCurrentCallbacks(this)) {
+ mModel.stopLoader();
+ app.setLauncher(null);
+ }
try {
mAppWidgetHost.stopListening();
return isLaunching;
}
+ public boolean isCurrentCallbacks(Callbacks callbacks) {
+ return (mCallbacks != null && mCallbacks.get() == callbacks);
+ }
+
public void startLoader(boolean isLaunching, int synchronousBindPage) {
startLoader(isLaunching, synchronousBindPage, LOADER_FLAG_NONE);
}