过年这段时间正比如较有空,并且有一个客服相关的需求,借这个机会把一年前写的支持输入表情和@mention的EditText又重构了一遍,具体见SpEditTool,重构过程当中对EditText选择模式又有了一些新的认识,在这里记录下git
在实现响应软键盘光标移动事件以前已经实现了让光标不进入@mention字符串的逻辑(离start位置近就重置回start位置,离end位置近就重置回end位置),可是在光标只移动一格的状况下会回退到以前的光标位置,光标永远没法跨过一个@mention字符串。因此对于软键盘的光标移动时通过@mention须要特殊处理github
这种状况比较好处理,无非是判断光标是否进入了@mention内部,左移的时候就把selectionStart和selectionEnd都设置到@mention的start位置,右移的时候设置到end位置bash
这种状况是使用软键盘选中一段文字时出现微信
在处理这个场景时,我最开始犯了一个错误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和左右移动方向就能够覆盖以上的四种状况了,可是场景分类跟以前会有些区别编码
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可能有些反直觉,不过仔细想想确实是取消选中和选中用的是一样的参数
有个朋友在使用这个库的时候提了个Issues #7 ,就扔了一张图
不得不说这张图仍是挺有误导性的,我最初一直觉得后面输入的部分的样式是来自于第一个@mention,并且后面一长串都带了样式,让我认为是持续输入了多个字符都带了样式,这个现象挺让我费解的,由于个人demo中全部setSpan(Object what, int start, int end, int flags)
的flags全都是SPAN_EXCLUSIVE_EXCLUSIVE
,按道理不会出现后面输入的字符也带样式的状况,本身尝试复现也没有成功
今天一个偶然的操做让我能够弄出图上的效果,说下本身的操做路径
以上操做能够复现出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的问题并非我这样操做出现的,后续有碰到一样问题的童鞋欢迎反馈
发现本身的东西有问题,固然得去试一试微信有没有问题,毕竟行业标杆嘛。 使人失望的是微信的@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 {
...
}
复制代码
重构过程当中参考了iYaoy的思路,在此特别感谢