PreferenceFragment 是否有意从兼容包中排除？

Question

我正在寻找可以应用于 3.0 和 pre-3.0 设备的首选项。发现 PreferenceActivity 包含已弃用的方法（尽管随附的示例代码中使用了这些方法），我查看了 PreferenceFragement 和兼容性包来解决我的问题。

不过，似乎 PreferenceFragment 不在兼容包中。谁能告诉我这是不是故意的？如果是这样，我是否可以轻松定位一系列设备（即 < 3.0 和 >=3.0），或者我是否必须跳过障碍？如果不是有意排除，我们能期待新版本的兼容包吗？或者是否有另一种可以安全使用的解决方法？

原文由 James 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

发现 PreferenceActivity 包含已弃用的方法（尽管随附的示例代码中使用了这些方法）

从 Android 3.0 开始，已弃用的方法已弃用。它们在所有版本的 Android 上都很好，但方向是在 Android 3.0 及更高版本上使用 PreferenceFragment 。

谁能告诉我这是不是故意的？

我的猜测是这是工程时间的问题，但这只是一个猜测。

如果是这样，我是否可以轻松定位一系列设备（即 < 3.0 和 >=3.0），或者我是否必须跳过障碍？

我认为这是“容易”完成的。有两个单独的 PreferenceActivity 实现，一个使用首选项标头和 PreferenceFragments ，另一个使用原始方法。在您需要的时候选择正确的一个（例如，当用户单击选项菜单项时）。 这是一个演示这一点的示例项目。或者，有一个 PreferenceActivity 可以处理这两种情况，如 本示例项目 中所示。

如果不是有意排除，我们能期待新版本的兼容包吗？

当我们其他人发现时，您会发现，也就是说，它是否以及何时发货。

或者是否有另一种可以安全使用的解决方法？

看上面。

原文由 CommonsWare 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

@CommonsWare 的回答的微妙含义是 - 您的应用程序必须在兼容性 API 或内置片段 API 之间进行选择（自 SDK 11 左右）。事实上，这就是“轻松”建议所做的。换句话说，如果您想使用 PreferenceFragment，您的应用需要使用内置片段 API 并处理 PreferenceActivity 上已弃用的方法。相反，如果您的应用使用兼容很重要。 API，您将面临根本没有 PreferenceFragment 类的情况。因此，定位设备不是问题，但是当您必须选择一个或另一个 API 并因此将您的设计提交给无法预料的变通办法时，就会发生跳跃。我需要兼容。 API，因此我将创建自己的 PreferenceFragment 类并查看其工作原理。在最坏的情况下，我将只创建一个普通（片段）布局并手动将视图组件绑定到 sharedprefs ……呃。

编辑：在尝试查看 http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/preference/PreferenceFragment.java 上的代码之后？ av=h -- 创建我自己的 PreferenceFragment 不会发生。似乎在 PreferenceManager 中自由使用 package-private 而不是 ‘protected’ 是主要的障碍。这样做看起来确实没有任何安全性或真正好的动机，而且它不适合单元测试，但是哦，好吧……我想少打字……

编辑 v2：实际上它确实发生了并且有效。让代码与 Compatibility API JAR 一起工作绝对是一件令人头疼的事情。我不得不将大约 70% 的 com.android.preference 包从 SDK 复制到我的应用程序，然后在 Android 中处理通常质量一般的 Java 代码。我使用了 SDK 的 v14。谷歌工程师做我做的事情会容易得多，这与我听到一些主要 Android 工程师关于这个话题的说法相反。

顺便说一句——我说过“定位设备不是问题”吗？这完全是…如果您使用 com.android.preference，您将无法在不进行重大重构的情况下换出兼容性 API。有趣的日志！

原文由 Tenacious 发布，翻译遵循 CC BY-SA 3.0 许可协议