EditText选择模式的一些问题

过年这段时间正比如较有空,并且有一个客服相关的需求,借这个机会把一年前写的支持输入表情和@mention的EditText又重构了一遍,具体见SpEditTool,重构过程当中对EditText选择模式又有了一些新的认识,在这里记录下git

选择模式的光标

场景描述

在实现响应软键盘光标移动事件以前已经实现了让光标不进入@mention字符串的逻辑(离start位置近就重置回start位置,离end位置近就重置回end位置),可是在光标只移动一格的状况下会回退到以前的光标位置,光标永远没法跨过一个@mention字符串。因此对于软键盘的光标移动时通过@mention须要特殊处理github

当selectionStart=selectionEnd时

这种状况比较好处理,无非是判断光标是否进入了@mention内部,左移的时候就把selectionStart和selectionEnd都设置到@mention的start位置,右移的时候设置到end位置bash

当selectionStart!=selectionEnd时

这种状况是使用软键盘选中一段文字时出现微信

在处理这个场景时,我最开始犯了一个错误app

int selectionStart = Selection.getSelectionStart(text);
            int selectionEnd = Selection.getSelectionEnd(text);
复制代码

我认为selectionStart表明签名的光标位置,selectionEnd表明后面的光标位置,selectionStart必定小于等于selectionEnd。 由于光标左右移动并无参数表示是移动哪一个光标,因此最初实现的时候想固然的忽略了这个点,以为左右移动只有两种状况:ide

光标 移动方向 结果
前面的光标 左移 选中前面的@mention
后面的光标 右移 选中后面的@mention

然而实际的状况是四种:ui

光标 移动方向 结果
前面的光标 左移 选中左边的@mention
前面的光标 右移 取消选中左边的@mention
后面的光标 右移 选中右边的@mention
后面的光标 左移 取消选中右边的@mention

固然这样写出来的逻辑是有问题的,在编码的过程当中发现其实selectionStart和selectionEnd的意思和本身最开始想的并不同this

  • selectionStart表示在选择过程当中不变的光标位置
  • selectionEnd表示在选择过程当中移动的位置

因此知道了selectionStart/selectionEnd和左右移动方向就能够覆盖以上的四种状况了,可是场景分类跟以前会有些区别编码

selectionEnd光标移动方向 selectionEnd>selectionStart 结果
左移 true 选中左边的@mention
左移 false 取消选中右边的@mention
右移 true 选中右边的@mention
右移 false 取消选中左边的@mention

对于Selection.setSelection(Spannable text, int start, int stop),start!=stop的状况下,start表示选择过程当中不变的光标,stop表示变化的光标spa

最终实现代码

//处理光标左移事件
        if (keyEvent.getKeyCode() == KeyEvent.KEYCODE_DPAD_LEFT
                && keyEvent.getAction() == KeyEvent.ACTION_DOWN) {

            int selectionStart = Selection.getSelectionStart(text);
            int selectionEnd = Selection.getSelectionEnd(text);
            IntegratedSpan[] integratedSpans = text.getSpans(selectionEnd, selectionEnd, IntegratedSpan.class);
            if (integratedSpans != null && integratedSpans.length > 0) {
                for (IntegratedSpan span : integratedSpans) {
                    int spanStart = text.getSpanStart(span);
                    int spanEnd = text.getSpanEnd(span);
                    //selectionEnd表示移动的光标
                    if (spanEnd == selectionEnd) {
                        Selection.setSelection(text, selectionStart, spanStart);
                        return true;
                    }
                }
            }
        }
        //处理光标右移事件
        if (keyEvent.getKeyCode() == KeyEvent.KEYCODE_DPAD_RIGHT
                && keyEvent.getAction() == KeyEvent.ACTION_DOWN) {
            int selectionStart = Selection.getSelectionStart(text);
            int selectionEnd = Selection.getSelectionEnd(text);
            IntegratedSpan[] integratedSpans = text.getSpans(selectionEnd, selectionEnd, IntegratedSpan.class);
            if (integratedSpans != null && integratedSpans.length > 0) {
                for (IntegratedSpan span : integratedSpans) {
                    int spanStart = text.getSpanStart(span);
                    int spanEnd = text.getSpanEnd(span);
                    if (spanStart == selectionEnd) {
                        Selection.setSelection(text, selectionStart, spanEnd);
                        return true;
                    }
                }
            }
        }
复制代码

两个地方的setSelection可能有些反直觉,不过仔细想想确实是取消选中和选中用的是一样的参数

选择模式下replace的问题

有个朋友在使用这个库的时候提了个Issues #7 ,就扔了一张图

不得不说这张图仍是挺有误导性的,我最初一直觉得后面输入的部分的样式是来自于第一个@mention,并且后面一长串都带了样式,让我认为是持续输入了多个字符都带了样式,这个现象挺让我费解的,由于个人demo中全部setSpan(Object what, int start, int end, int flags)的flags全都是SPAN_EXCLUSIVE_EXCLUSIVE,按道理不会出现后面输入的字符也带样式的状况,本身尝试复现也没有成功

今天一个偶然的操做让我能够弄出图上的效果,说下本身的操做路径

  • 插入两个@mention
  • 选中第二个
  • 而后调出输入法选中26键中文输入模式
  • 打一长串字母而后按回车

以上操做能够复现出Issues #7 中的问题,可是缘由却不是第一个@mention的样式影响到了后面的字符串,而是有两个@mention,第二个@mention在选中状态下被replace,样式没有消失

由于库中自定义了一个SpannableStringBuilder,因此解决方案也比较简单

@Override
    public SpannableStringBuilder replace(int start, int end, CharSequence tb, int tbstart,
            int tbend) {
         ...
        //先删除再插入,解决选择模式下span样式不正常消失的问题
        if (start != end && tbstart != tbend) {
            super.replace(start, end, "", 0, 0);
            super.insert(start, tb, tbstart, tbend);
        } else {
            super.replace(start, end, tb, tbstart, tbend);
        }
        ...
        return this;
    }
复制代码

固然有可能Issues #7的问题并非我这样操做出现的,后续有碰到一样问题的童鞋欢迎反馈

ImageSpan的replace

发现本身的东西有问题,固然得去试一试微信有没有问题,毕竟行业标杆嘛。 使人失望的是微信的@mention并无上面的问题,不过微信的单个表情在选中时打字会没有效果

反过头看本身的表情输入,通过上面的特别处理以后,选中单个表情输入文字文字却是照常输进去了,可是表情居然没删掉

调试了一下发现选中表情时调用replace(int start, int end, CharSequence tb, int tbstart, int tbend),end只比start大1,可是demo中ImageSpan对应的字符串长度应该都是4,问题就出在这里了,对一个表情,选中状况下得replace4次才能被删掉

缘由看了下代码没分析出来,不过解决方案却是简单,以前@mention已经实现了让光标不能进入内部的逻辑,将对应的Span用IntegratedSpan标记下就好了

public class IsoheightImageSpan extends ImageSpan implements IntegratedSpan {
    ...
}
复制代码

一波推广

一个高效可扩展,在EditText/TextView中输入和显示gif和@mention等图文混排内容的库

重构过程当中参考了iYaoy的思路,在此特别感谢

相关文章
相关标签/搜索