Wurde PreferenceFragment absichtlich aus dem Kompatibilitätspaket ausgeschlossen?

Ich möchte Einstellungen schreiben, die sowohl auf 3.0- als auch auf Geräte vor 3.0 angewendet werden können. Das entdecken PreferenceActivity veraltete Methoden enthält (obwohl diese im beigefügten Beispielcode verwendet werden), habe ich mir angesehen PreferenceFragement und das Kompatibilitätspaket, um meine Probleme zu lösen.

Es scheint aber so PreferenceFragment ist nicht im Kompatibilitätspaket. Kann mir jemand sagen ob das Absicht war? Wenn ja, kann ich problemlos auf eine Reihe von Geräten abzielen (z. B. < 3.0 und >= 3.0) oder muss ich um die Wette springen? Wenn es nicht absichtlich ausgeschlossen wurde, können wir eine neue Version des Kompatibilitätspakets erwarten? Oder gibt es eine andere Problemumgehung, die sicher zu verwenden ist?

Beifall

James

Entdecken, dass PreferenceActivity veraltete Methoden enthält (obwohl diese im begleitenden Beispielcode verwendet werden)

Die veralteten Methoden sind ab Android 3.0 veraltet. Sie sind auf allen Versionen von Android vollkommen in Ordnung, aber die Richtung ist zu verwenden PreferenceFragment auf Android 3.0 und höher.

Kann mir jemand sagen ob das Absicht war?

Meine Vermutung ist, dass es eine Frage der Entwicklungszeit ist, aber das ist nur eine Vermutung.

Wenn ja, kann ich problemlos auf eine Reihe von Geräten abzielen (z. B. < 3.0 und >= 3.0) oder muss ich um die Wette springen?

Ich halte es für “einfach”. Habe zwei getrennt PreferenceActivity Implementierungen, eine mit Präferenzheadern und PreferenceFragments, der andere mit dem ursprünglichen Ansatz. Wählen Sie an der erforderlichen Stelle die richtige aus (z. B. wenn der Benutzer auf das Optionsmenüelement klickt). Hier ist ein Beispielprojekt dies demonstrieren. Oder haben Sie eine Single PreferenceActivity das beide Fälle behandelt, wie in dieses Beispielprojekt.

Wenn es nicht absichtlich ausgeschlossen wurde, können wir eine neue Version des Kompatibilitätspakets erwarten?

Sie werden es herausfinden, wenn der Rest von uns es herausfindet, das heißt, ob und wann es versendet wird.

Oder gibt es eine andere Problemumgehung, die sicher zu verwenden ist?

Siehe oben.

Die subtile Implikation der Antwort von @CommonsWare ist, dass Ihre App zwischen der Kompatibilitäts-API oder der integrierten Fragment-API (seit SDK 11 oder so) wählen muss. Genau das hat die „einfach“-Empfehlung getan. Mit anderen Worten, wenn Sie PreferenceFragment verwenden möchten, muss Ihre App die integrierte Fragment-API verwenden und mit den veralteten Methoden auf PreferenceActivity umgehen. Umgekehrt, wenn es wichtig ist, dass Ihre App die Datei compat. API werden Sie damit konfrontiert, dass Sie überhaupt keine PreferenceFragment-Klasse haben. Das Targeting von Geräten ist also kein Problem, aber das Reifenspringen passiert, wenn Sie sich für die eine oder andere API entscheiden müssen und damit Ihr Design unvorhergesehenen Workarounds unterwerfen. Ich brauche das Kompat. API, also werde ich meine eigene PreferenceFragment-Klasse erstellen und sehen, wie das funktioniert. Im schlimmsten Fall erstelle ich einfach ein normales (Fragment-)Layout und binde die Ansichtskomponenten manuell an die Sharedprefs … ugh.

EDIT: Nach dem Ausprobieren und Betrachten des Codes bei http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/preference/PreferenceFragment.java?av=h — das Erstellen meines eigenen PreferenceFragments wird nicht passieren. Es scheint, dass die großzügige Verwendung von „package-private“ in PreferenceManager anstelle von „protected“ der Hauptblocker ist. Es sieht wirklich nicht so aus, als gäbe es eine Sicherheit oder eine wirklich gute Motivation, dies getan zu haben, und es ist nicht großartig für Komponententests, aber na ja … weniger Tippen, denke ich …

EDIT v2: Tatsächlich ist es passiert und es hat funktioniert. Es war definitiv ein Problem, den Code mit dem Kompatibilitäts-API-JAR zum Laufen zu bringen. Ich musste etwa 70 % des com.android.preference-Pakets aus dem SDK in meine App kopieren und mich dann mit typisch mittelmäßigem Java-Code in Android herumschlagen. Ich habe v14 des SDK verwendet. Es wäre für einen Goog-Ingenieur viel einfacher gewesen, das zu tun, was ich getan habe, im Gegensatz zu dem, was einige führende Android-Ingenieure zu diesem Thema sagen.

Übrigens – habe ich gesagt, dass das Targeting von Geräten kein Problem ist? Es ist absolut … wenn Sie com.android.preference verwenden, können Sie ohne größere Umgestaltung nicht mit der Kompatibilitäts-API austauschen. Lustiges Protokoll!

Aufbauend auf der Antwort von CommonsWare sowie den Beobachtungen von Tenacious habe ich eine Lösung mit einer einzelnen Nachkommenklasse entwickelt, die in der Lage ist, alle aktuellen Android-API-Versionen mit minimalem Aufwand und ohne Code- oder Ressourcenduplizierung anzusprechen. Bitte lesen Sie meine Antwort auf die verwandte Frage hier: PreferenceActivity Android 4.0 und früher

oder auf meinem Blog:
http://www.blackmoonit.com/2012/07/all_api_prefsactivity/

Getestet auf zwei Tablets mit 4.0.3 und 4.0.4 sowie einem Telefon mit 4.0.4 und 2.3.3 und einem Emulator mit 1.6.

Sehen PreferenceFragment-Compat von Machinarius. Es war einfach, bei Gradle vorbeizuschauen, und ich vergesse, dass es sogar da ist.

compile 'com.github.machinarius:preferencefragment:0.1.1'

Wichtige Aktualisierung: Der letzte Überprüfung des v7 support library hat jetzt einen Eingeborenen PreferenceFragmentCompat.

Im August 2015 veröffentlichte Google die neue Präferenzunterstützungsbibliothek v7.

Jetzt können Sie die verwenden PreferenceFragmentCompat mit jedem Activity oder AppCompatActivity

public static class PrefsFragment extends PreferenceFragmentCompat {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // Load the preferences from an XML resource
        addPreferencesFromResource(R.xml.preferences);
    }
}

Du musst einstellen preferenceTheme in deinem thema:

<style name="AppTheme" parent="@style/Theme.AppCompat.Light">
  ...
  <item name="preferenceTheme">@style/PreferenceThemeOverlay</item>
</style>

Auf diese Weise können Sie die anpassen preferenceTheme um die für jeden Einstellungstyp verwendeten Layouts zu gestalten, ohne andere Teile Ihrer Aktivität zu beeinflussen.

Die Antwort von Tenacious ist richtig, aber hier sind einige weitere Details.

Der Grund, warum Sie kein “normales Layout erstellen und die Ansichtskomponenten manuell an die Sharedprefs binden können”, liegt darin, dass es einige überraschende Auslassungen in der android.preferences-API gibt. PreferenceActivity und PreferenceFragment haben beide Zugriff auf kritische, nicht öffentliche PreferenceManager-Methoden, ohne die Sie keine eigene Benutzeroberfläche für Einstellungen implementieren können.

Um insbesondere eine Preference-Hierarchie aus einer XML-Datei zu erstellen, müssen Sie einen PreferenceManager verwenden, aber alle Konstruktoren von PreferenceManager sind entweder paketprivat oder verborgen. Die Methode zum Anhängen der Preference onClick-Listener an Ihre Aktivität ist ebenfalls paketprivat.

Und Sie können dies nicht umgehen, indem Sie Ihre Implementierung heimlich in das android.preferences-Paket einfügen, da nicht öffentliche Methoden in Android-APIs tatsächlich aus dem SDK weggelassen werden. Mit ein wenig Kreativität, die Reflexion und dynamische Proxys beinhaltet, können Sie sie immer noch erreichen. Die einzige Alternative, wie Tenacious sagt, besteht darin, das gesamte android.preference-Paket zu forken, einschließlich mindestens 15 Klassen, 5 Layouts und einer ähnlichen Anzahl von style.xml- und attrs.xml-Elementen.

Um die ursprüngliche Frage zu beantworten, der Grund, warum Google PreferenceFragment nicht in das Kompatibilitätspaket aufgenommen hat, ist, dass sie genau die gleichen Schwierigkeiten gehabt hätten wie Tenacious und ich. Selbst Google kann nicht in der Zeit zurückgehen und diese Methoden auf den alten Plattformen veröffentlichen (obwohl ich hoffe, dass sie dies in zukünftigen Versionen tun).

Mein App-Ziel ist API +14, aber aufgrund der Verwendung der Support-Bibliothek für eine ausgefallene Navigation konnte ich die nicht verwenden android.app.Fragment und verwenden musste android.support.v4.app.Fragment, aber ich musste auch haben PreferenceFragment an Ort und Stelle ohne große Änderungen am Code dahinter.

Also meine einfache Lösung, um beide Welten der Support-Bibliothek und zu haben PreferenceFragment:

private android.support.v4.app.Fragment fragment;
private android.app.Fragment nativeFragment = null;

private void selectItem(int position) {
    fragment = null;
    boolean useNativeFragment = false;
    switch (position) {
    case 0:
        fragment = new SampleSupprtFragment1();
        break;
    case 1:
        fragment = new SampleSupprtFragment2();
        break;
    case 2:
        nativeFragment = new SettingsFragment();
        useNativeFragment = true;
        break;
    }
    if (useNativeFragment) {
        android.app.FragmentManager fragmentManager = getFragmentManager();
        fragmentManager.beginTransaction()
            .replace(R.id.content_frame, nativeFragment).commit();
    } else {
        if (nativeFragment != null) {
            getFragmentManager().beginTransaction().remove(nativeFragment)
                .commit();
            nativeFragment = null;
        }
        FragmentManager fragmentManager = getSupportFragmentManager();
        fragmentManager.beginTransaction()
            .replace(R.id.content_frame, fragment).commit();
    }
}