为了账号安全,请及时绑定邮箱和手机立即绑定

EditText选择模式的一些问题

标签:
Android

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

选择模式的光标

场景描述

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

当selectionStart=selectionEnd时

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

当selectionStart!=selectionEnd时

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

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

            int selectionStart = Selection.getSelectionStart(text);            int selectionEnd = Selection.getSelectionEnd(text);

我认为selectionStart代表签名的光标位置,selectionEnd代表后面的光标位置,selectionStart一定小于等于selectionEnd。
因为光标左右移动并没有参数表示是移动哪个光标,所以最初实现的时候想当然的忽略了这个点,觉得左右移动只有两种情况:

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

然而实际的情况是四种:

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

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

  • 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表示变化的光标

最终实现代码

        //处理光标左移事件
        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  ,就扔了一张图

webp


不得不说这张图还是挺有误导性的,我最初一直以为后面输入的部分的样式是来自于第一个@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 {
    ...
}



作者:sunhapper
链接:https://www.jianshu.com/p/0f68c2ff4978


点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消