When I try my app with Android KitKat I have an error in PreferenceActivity.
Subclasses of PreferenceActivity must override isValidFragment(String) to verify that the Fragment class is valid! com.crbin1.labeltodo.ActivityPreference has not checked if fragment com.crbin1.labeltodo.StockPreferenceFragment is valid
In documentation I find the following explanation
protected boolean isValidFragment (String fragmentName)
Added in API level 19
Subclasses should override this method and verify that the given fragment is a valid type to be attached to this activity. The default implementation returns true for apps built for android:targetSdkVersion older than KITKAT. For later versions, it will throw an exception.
I don't find any example to resolve the problem.
this is my solution:
if u use extras to start preference activity - onBuildHeaders() approach will fail! (with below start intent extras - why ??? - simple because onBuildHeaders() is never called):
Intent.putExtra(PreferenceActivity.EXTRA_SHOW_FRAGMEN,Fragment.class.getName()); Intent.putExtra(PreferenceActivity.EXTRA_NO_HEADERS, true);
This is example class:
Here's my headers_preferences.xml file:
In my PreferencesActivity where the isValidFragment code occurs, I just turned it on its head:
As long as I use the AppPreferencesFragment string at the start of all my fragment names, they all validate just fine.
I found I could grab a copy of my fragment names from my header resource as it was loaded:
This way I don't need to remember to update a list of fragments buried in the code if I want to update them.
I had hoped to use
getHeaders()
and the existing list of headers directly, but it seems the activity is destroyed afteronBuildHeaders()
and recreated beforeisValidFragment()
is called.This may be because the Nexus 7 I'm testing on doesn't actually do two-pane preference activities. Hence the need for the static list member as well.
Out of pure curiosity, you can also do this as well:
Try this... this is how we check validity of fragment.
Verified with an actual 4.4 device:
(1) if your proguard.cfg file has this line (which many define anyway):
(2) than the most efficient implementation would be: