The new insistence on fragments instead of activities seems to make this harder. The invalidate
route didn't seem to work nor approaches using the underlying View. Thanks to halxinate's answer I have now managed to work this through. For people who are as new as I am to all this here are a few more details:
When creating the settings fragment, save a reference in your main activity, e.g.:
@Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
switch (item.getItemId()) {
case R.id.action_preferences:
if (getFragmentManager().getBackStackEntryCount() < 1) {
FragmentTransaction trans = getFragmentManager()
.beginTransaction();
// Save a reference to the settings fragment
settingsFrag = new SettingsFragment();
trans.replace(R.id.container, settingsFrag);
trans.addToBackStack(null);
trans.commit();
}
return true;
default:
return super.onOptionsItemSelected(item);
}
}
Then when you want to update the summaries of the outer PreferenceScreen
from the OnSharedPreferenceChangeListener
use this sort of thing. Note that you need to have defined a key in your preference fragment xml for the outer PreferenceScreen
(in this case android:key="prefs_root"
):
public static void setOuterSummaries(SettingsFragment sf) {
// Set the outer preferences summaries
if (sf == null)
return;
//Code to update the summaries....
// Force the parent screen summaries to update
prefScr = (PreferenceScreen) sf.findPreference("prefs_root");
if (prefScr != null)
((BaseAdapter) prefScr.getRootAdapter()).notifyDataSetChanged();
}
OnSharedPreferenceChangeListener listener = new SharedPreferences.OnSharedPreferenceChangeListener() {
public void onSharedPreferenceChanged(SharedPreferences prefs,
String key) {
Log.e("L", "Change");
setOuterSummaries(settingsFrag);
}
};
Note that you could save a reference to the BaseAdapter
instead of to the settings fragment but this approach seems safer when you think of generalizing it to a multi-fragment situation or code which dynamically creates the fragment content.