android - 避免 EditText 焦点问题的 ListView 替代方案？

Question

情况

出于言语治疗工具的目的，需要将文本文件呈现为可编辑句子或短语的列表，如下例所示。这相对容易。

可以根据需要添加、删除或拖动彩色标志到新位置，并且可以设置为对齐字符或snap-to-word(它们最终也会显示数据)。
这是通过子类 EditText 实现的，以利用所有内置功能，如自动换行、拼写检查、文本选择等。

问题

文档中的短语或句子的数量可能很大，因此在这种情况下，在 ScrollView 中使用简单的 LinearLayout 来显示它们并不好。

为了有效地显示我的 FlaggedEditText 小部件，解决方案需要利用 View 回收，因此 ListView 是一个显而易见的考虑因素。但正如 S.O. 的数量所示。那里的问题，ListView 和 EditText 不能一起玩。
列表的要求是:

• FlaggedEditText 小部件在触摸时获得焦点(包含 FlaggedEditText 的项目也被选中)。
• 当列表中的项目被编辑时通知(包括哪个项目)。
• 标准手势，例如猛扑。

我已经尝试了许多 S.O.过去几天的问题，试图让 ListView 符合我的要求，但似乎都有自己的缺点，并导致代码乱七八糟。

问题

• 有没有人知道现有的标准 Android ListView 替代品，它们对 EditText 更友好？
• 或者，是否有人有一种干净、高效、明确的方法来使 EditText 在标准 ListView 中按需要工作？
• 最后，我正在考虑对 AdapterView 进行子类化，以制作我自己的 FlaggedEditText 特定 ListView 替代方案。但是，如果问题源于 AdapterView 而 ListView 也是一个间接子类，那么我就是在浪费时间。有人走过这条路吗？

---

编辑

Jim 在下方的出色回应，以及 Romain Guy 和 Adam Powell 在 2010 年 Google I/O 上的旧演示文稿的最近浏览 The world of ListView提出了一个可能的解决方案。

在 I/O 演讲中提醒我，他们将 View 转换为位图以进行一些优化。由于一次只能关注一个 EditText 进行编辑，我想我可以子类化 ListView 以提供一个接口(interface)，如果 ChoiceMode 是单一的，将给出所选项目的矩形和所选项目上方和下方 ListView 区域的位图。然后，这可用于临时覆盖 ListView 与垂直 LinearLayout 包含“上方”位图、 Activity FlaggedEditText 和“下方”位图。

通过这种方式，FlaggedEditText 小部件可以有效地充当 ListView 中的不可聚焦的 EditText，但是当一个 Item 是选中，与临时叠加层交互。
“上方”和“下方”位图也可以很容易地着色以暗示不活动。

额外
事实上，我刚刚意识到我可能甚至不需要界面中所选项目的矩形。 “上方”和“下方”位图以及使用与 ListView 相同的 LayoutParams 的 FlaggedEditText 应该就足够了。

Answer 1

许多答案似乎都没有描述围绕这个“问题”的核心问题以及为什么它没有“解决”。您面临的“问题”是 EditText 可以展开和/或滚动，以及您的 ListView。此外，扩展的软键盘会强制 ListView 重绘，从而导致跟踪焦点项出现问题。当某个项目获得焦点并具有动态内容时，触摸手势可能会导致用户体验困惑(例如，如果您触摸 EditText 中的某个项目，例如光标然后滑动，您是否希望光标移动？还是整个列表？)这会导致很多用户感到沮丧。

我确定您已经看过这篇文章:

Issues focusing EditTexts in a ListView (Android)

这会导致在 ListView 中正确显示元素、正确回收(重绘)问题以及正确获得焦点问题。创建一个扩展 AdapterView 的自定义类可能会奏效，但它可能仍然感觉像是一个 hack，并且可能不会像您希望的那样工作，或者需要付出很大的努力。

您将需要对自定义对象中的字体、图像和“可见”(或部分可见)项目进行大量后端测量，这些项目还负责键盘动画和双滚动(ListView 可以滚动，EditText 也可以 - 或者 EditText 会改变大小，迫使父自定义 AdapterView 确定它是否也应该滚动以及 View 是否由于从聚焦对象中添加或删除文本/图像而变得可见或不可见)。

如果您做出“EditText 永远不会大于 X 高度”这样的假设，那么您可能会让它工作，但显然这是一个非常定制的解决方案，这就是为什么它不容易已实现且不受一般支持。

此外，您还需要做出关于如何处理已滚动到屏幕之外的焦点项目的 UX 决策(您可以轻松跟踪它，但如果它滚动回到屏幕上，但它可能会打断用户对如何滑动的期望和触摸手势被处理——例如，EditText 中的光标是移动还是整个列表？如果触摸了图像，滑动是移动图像还是滚动列表？你可以假设它没有获得焦点，但是“重绘”事件可能会使其意外地失去焦点，就像当前的 ListView 实现一样。)换句话说，您可能会遇到许多意想不到的奇怪的 UX 问题...

您最好的解决方案可能是使用我在上面引用的帖子中提到的对话框弹出窗口。或者，当点击一个项目进行编辑时，您可以在 ListView 上方或下方显示一个布局。您可能会让 ListView 滚动并锁定到它 - 让它看起来就像在 ListView 中一样 - 但同样，软键盘很难做到这一点更改屏幕的可用部分 - 您可以期待“拖动”或“捕捉”效果的缓慢感觉。您将需要一个“完成”按钮...

要让您的自定义 EditText 处理此建议，您可以在 ListView 中禁用它并使其不可聚焦，然后在整个布局上放置一个空布局EditText 捕获和处理触摸/滑动/滑动事件。这种“隐形”布局可能是您真正拥有的唯一选择。

换句话说，您可能应该计划更改您的 UI/UX，而不是试图强制 Android 弄清楚如何处理这些布局的 UX 交互的几个动态的、可能冲突或不可预测的方面。