android - 如何在AppCompat中使用support.v7.preference和潜在的缺点

Question

我试图使用support.v7.preference来实现AppCompat应用程序的首选项。我花了几天的时间来弄弄它，因为support.v7.preference与 native 首选项有一些显着的区别……一旦知道，这还不错，但是不幸的是，那里几乎没有文档。我以为我会分享我的发现，这样其他人就不必经历同样的痛苦。

所以...问题:

如何最好地实现AppCompat应用程序的首选项(PreferenceFragment和AppCompatAcitivity不兼容)？

以下是几个相关的问题:

Preference sub-screen not opening when using support.v7.preference

How to move back from Preferences subscreen to main screen in PreferenceFragmentCompat?

PreferenceFragmentCompat requires preferenceTheme to be set

How do I create custom preferences using android.support.v7.preference library?

官方文档在这里:

http://developer.android.com/guide/topics/ui/settings.html

http://developer.android.com/reference/android/support/v7/preference/Preference.html

Answer 1

解决方案1:带有PreferenceFragment的 native AppCompatActivity
在AndroidStudio中，选择"file">“新建项目”>“...> SettingsActivity”。该模板使用一种变通方法，将本地PreferenceFragment改型为可与AppCompatActivity或support.v4.Fragment一起使用support.v7.PreferenceFragmentCompat。

Pro:您现在可以在AppCompat应用程序。使用AS模板时，这是一种快速的方法，您可以坚持使用现有的Preference文档和工作流程。

骗局: retrofit 不是很直观或干净。另外，由于通常建议在可用的情况下使用支持库，因此我不确定这种方法的适用性。

解决方案2: support.v7.preference.PreferenceFragmentCompat和 AppCompatActivity

Pro:最大化兼容性

骗子:差距很大。同样，这可能不适用于任何现有的preferences-extensions-lib(例如ColorPicker或FontPreferences)。

如果您选择不使用解决方案1(我仍然不确定两者中哪一个更适合将来使用)，那么在使用 support.v7.preference时会有一些缺点。

下面提到使用解决方案2的重要缺点。

依赖项:

dependencies {
    ...
    compile 'com.android.support:appcompat-v7:23.1.1'
    compile 'com.android.support:preference-v7:23.1.1'
    compile 'com.android.support:support-v4:23.1.1'
}

主题:
您需要在styles.xml中定义一个 preferenceTheme，否则运行您的应用程序将引发异常。

<!-- Base application theme. -->
<style name="AppTheme" parent="Theme.AppCompat.Light">
    <!-- Customize your theme here. -->
    <item name="preferenceTheme">@style/PreferenceThemeOverlay</item>
</style>

您可能想将其拆分为7 +/14 +/21 +的不同样式。在撰写本文时，许多人提示这是 buggy 。有一个非常全面的答案 here。

行为更改:使用 native 首选项的非常简单:您需要做的就是定义/维护 preferences.xml并在 addPreferencesFromResource(R.xml.preferences)中使用 PreferenceFragment。可以通过对 DialogPreference进行子类化来轻松完成自定义首选项，然后在 preferences.xml ... bam中对其进行引用即可。

不幸的是， support.v7.preference删除了与处理 Fragment相关的所有内容，从而使其失去了很多内置功能。现在，您不仅要维护XML，还必须对它们进行子类化和覆盖，但不幸的是，所有这些都没有文档记录。

PreferenceScreens:框架不再管理 PreferenceScreens。在 PreferenceScreen中定义 preference.xml(如 docs中所述)将显示该条目，但是单击该条目将无济于事。现在由您决定显示和导航子屏幕。无聊的。

有一种方法(介绍了 here)，将 PreferenceFragmentCompat.OnPreferenceStartScreenCallback添加到 PreferenceFragmentCompat中。虽然此方法可以快速实现，但它只是交换现有首选项片段的内容。缺点是:没有后退导航，您总是在“顶部”，这对用户而言不是很直观。

在另一种方法中(描述为 here)，您还必须管理后退堆栈，以便按预期实现后退导航。这将 preferenceScreen.getKey()用作每个新创建/显示的片段的根。

这样做时，您也可能会偶然发现默认情况下 PreferenceFragments是透明的，并且奇怪地叠加在一起。人们倾向于覆盖 PreferenceFragmentCompat.onViewCreated()以添加类似内容

// Set the default white background in the view so as to avoid transparency
view.setBackgroundColor(ContextCompat.getColor(getContext(), R.color.background_material_light));

自定义DialogPreference:设置您自己的首选项也从琐碎变为无聊。 DialogPreference现在具有处理实际对话框的所有内容，已删除。该位现在位于 PreferenceDialogFragmentCompat中。因此，您必须对这两个子类都进行子类化，然后处理创建对话框并自己显示它(解释为 here)。

查看 PreferenceFragmentCompat.onDisplayPreferenceDialog()的源代码表明，它知道如何精确地处理2个对话框首选项( EditTextPreference， ListPreference)，您需要使用 OnPreferenceDisplayDialogCallback s实现自己的所有其他事情。类的 DialogPreference!

以下是一些代码，这些代码实现了大多数解决方法，并将它们包装在lib模块中:

https://github.com/mstummer/extended-preferences-compat.git

主要意图是:

无需在每个应用程序/项目中扩展和摆弄Activity和PreferenceFragment。 preference.xml现在再次成为每个项目中唯一要更改/维护的文件。

按预期方式处理和显示PreferenceScreens(子屏幕)。

取消拆分DialogPreference可恢复 native 行为。

处理并显示DialogPreference的任何子类。

不要认为它干净得可以立即使用，但是在处理类似问题时可能会给您一些提示。试一下，如果您有任何建议，请告诉我。