如何使用support.v7.preference与AppCompat和潜在的缺点

Question

我正在尝试使用support.v7.preference实现AppCompat应用程序的首选项.我花了几天时间来完成它,因为support.v7.preference与原生偏好有一些显着的差异......一旦你知道这一点并不是太糟糕,但遗憾的是那里的文档很少.我以为我会分享我的发现,所以其他人不必经历同样的痛苦.

---

所以......问题:

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

以下是一些相关问题:

• 使用support.v7.preference时,首选项子屏幕无法打开
• 如何从PreferenceFragmentCompat中的Preferences子屏幕移回主屏幕？
• PreferenceFragmentCompat需要设置preferenceTheme
• 如何使用android.support.v7.preference库创建自定义首选项？

官方文件:

• http://developer.android.com/guide/topics/ui/settings.html
• http://developer.android.com/reference/android/support/v7/preference/Preference.html

Answer 1

解决方案1:原生PreferenceFragment与AppCompatActivity

在AndroidStudio中,选择" 文件">"新建项目">"> SettingsActivity".此模板使用一种解决方法来改进本机PreferenceFragment的工作方式AppCompatActivity,类似于support.v4.Fragment或support.v7.PreferenceFragmentCompat.

• Pro:您现在可以在AppCompat应用程序中使用本机首选项功能 .使用AS模板时,这是一种快速方法,您可以坚持使用现有的首选项文档和工作流程.
• Con:改装不是很直观或干净.此外,由于通常建议在可用的情况下使用支持库,因此我不确定这种方法的未来发展方向.

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

• Pro:最大化兼容性
• 骗局:要弥合很多差距.此外,这可能不适用于任何现有的preference-extensions-libs(例如.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'
}

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

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

你可能想把它分成7 +/14 +/21 +的不同风格.在写这篇文章时,很多人都抱怨这是一辆马车.有可用的非常全面的答案在这里.

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

不幸的是,support.v7.preference已经把所有与处理Fragment剥离相关的东西都搞砸了,这使它失去了许多内置功能.你现在不必仅仅维护一个XML,而是必须进行子类化和覆盖很多东西,遗憾的是,所有这些东西都没有记录.

PreferenceScreens: PreferenceScreens不再由框架管理.PreferenceScreen在您的中定义a preference.xml(如文档中所述)将显示该条目,但单击它不会执行任何操作.现在由您决定显示和导航子屏幕.无聊.

有一种方法(在此描述),添加PreferenceFragmentCompat.OnPreferenceStartScreenCallback到您的PreferenceFragmentCompat.虽然这种方法很快就实现了,但它只是交换了现有首选项片段的内容.缺点是:没有后退导航,你总是'在顶部',这对用户来说不是很直观.

在另一种方法(此处描述)中,您还必须管理后台堆栈,以实现预期的后向导航.这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.因此,您必须对两者进行子类化,然后处理创建对话框并自行显示(在此处解释).

看看PreferenceFragmentCompat.onDisplayPreferenceDialog()节目的来源,它知道如何处理2个对话框首选项(EditTextPreference,ListPreference),你将不得不使用OnPreferenceDisplayDialogCallbacks 实现自己的所有其他...一个奇迹,为什么没有处理子类的功能DialogPreference!

下面是一些实现大多数这些变通方法的代码,并将它们放在lib模块中:

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

主要意图是:

• 删除需要有扩展和小提琴Activity,并PreferenceFragment在每个应用程序/项目.preference.xml现在又是唯一需要更改/维护的每个项目文件.
• PreferenceScreens按预期处理和显示(子屏幕).
• 取消拆分DialogPreference以恢复本机行为.
• 处理并显示任何子类DialogPreference.

不要认为它足够干净,只需开箱即用,但在处理类似问题时可能会给你一些提示.如果您有任何建议,请告诉我.