The initial reloadTextCache() operation needs to read 1k characters, and it
could be slow on low-end devices. Also, the initial load is not blocking key
strokes, so it can take a little longer.
Bug 22062102.
Change-Id: I134424e8910c0d6131c311a862bdc87eccd3af44
1. Add mechanism to detect a slow or non-resonsive InputConnection (IC)
2. When IC slowness is detected, skip certain IC calls that are known
to be expensive (e.g., getTextAfterCursor).
3. Similarly, disables learning / unlearning on a slow IC.
4. IC slowness flag is reset when starting input on a new TextView or
when a fixed amount of time has passed.
Note: These are mostly temporary workarounds. The permanent solution is
to refactor RichInputConnection so that it is less sensitive to IC
slowness in general.
Bug: 21926256
Change-Id: I383fab0516d3f3a8e0f71e5d760a8336a7730f7c
We never delete text after the cursor, so constrain the API accordingly.
Define the number of characters to read before and after.
Set them to reasonable values.
The next CL will start caching text after the cursor.
Bug 21926256.
Change-Id: Idd58daf68614de4a69344aa3c8a4323720c5d3a0
Use LOOKBACK_CHARACTER_NUM = 80 instead of the previous
EDITOR_CONTENTS_CACHE_SIZE = 1024 (which was overkill).
This speeds up many InputLogic operations.
Bug: 19987461
Change-Id: I62b6a589f87e5daab33376b3e48f1c615a66dcfb
Currently, we read 256 (max word size) * 5 (max N-gram size + 1) characters
from the input connection when building our context. This is overkill. We
don't need more than 80 characters, regardless of which decoder we use.
Bug 19987461.
Change-Id: Ie3a321cf2482adbacd8006d9d86e6601097c15ed
When the LatinIME does not have an active InputConnection, it will not try
to toggle the Emoji keyboard.
Bug 19513415.
Change-Id: I31f928cd7db1cddd771c548cd3dc42f8af64d0e2
When committing a span after a revert, the offset logic was such that it
split a surrogate unicode pair used to express an emoji.
Checking the last character of the span lets us avoid this problem.
Fix for bug 19255233.
Change-Id: I07d18d9002b5075f7925319dd05962011656c311
This CL fixes the following compiler warnings.
- Indirect access to static member
- Access to a non-accessible member of an enclosing type
- Parameter assignment
- Method can be static
- Local variable declaration hides another field or variable
- Value of local variable is not used
- Unused import
- Unused private member
- Unnecessary 'else' statement
- Unnecessary declaration of throw exception
- Redundant type arguments
- Missing '@Override' annotation
- Unused '@SuppressWarning' annotations
Bug: 18003991
Change-Id: Icfebe753e53a2cc621848f769d6a3d7ce501ebc7
With this CL, the previously used commit indicator was reverted.
Instead we use the add-to-dictionary indicator only at the moment.
This CL also fixes the indicator position in bidi context.
BUG: 17335734
Change-Id: I5f7cf173ddc30876e2b01320acaff8ba4265edf6
This is a follow up CL for API signature change in
I772c48ff18918e48a81e807b48ff907614485c09
BUG: 17320996
Change-Id: Ic8b6162bda12bf74fae79af212c5d81c400eb9e8
RichInputConnection#requestUpdateCursorAnchorInfo must make
sure to obtain the input connection before calling methods
of it.
BUG: 17299587
Change-Id: I8e0cd473a4cc32583cd47634c227d702f7c69c6c
When CursorAnchorInfo is unavailable, we shouldn't try to show
the commit indicator and set the text highlight color.
With this CL, RichInputConnection can be used to track if the
application responded that it does support CursorAnchorInfo or
not. This result will be taken into consideration when
InputLogic needs to determine whether the commit indicator
should be displayed or not.
Change-Id: I945d70eeb02a7a5f3d9b22459b23d7028508910f
This is a groundwork for subsequent CLs where we need to
add/remove background color to/from the commited text.
In this CL, we use Spanned#SPAN_COMPOSING so that we can easily
remove such a background color by calling
InputConnection#finishComposingText. To make this operation easy
and realiable, we need to track whether we have specified the
background color to the commited text or not at one place. Here
we use RichInputConnection for this purpose.
Change-Id: I5f9bc4425c5d1b80a719a20e5baf336729ec08d2
There is a bug in ICS where the input connection won't take
any writing commands after rotation until the cursor moves.
This fixes it by wiggling the cursor position once before trying
to do anything.
Bug: 16810766
Change-Id: Ib14c70bd0550420cecfa86dea501d13a1a91e296
The symptom : when text is selected and the device is rotated,
sometimes the keyboard sets the word as being composed around
the start of the selection. Upon the next rotation this ends up
with the keyboard committing some text in place of the selection.
The cause : another bug in the framework with rotation >.>
The keyboard receives a call to startInput with a wrong cursor
position, namely one that does not represent a selection. The
keyboard sets a composition according to this wrong data. When
the keyboard is rotated again, it commits the text, which takes
the place of the selection.
The solution : actually when restarting input the keyboard
realizes that the cursor position is wrong. We cancel composition
at that time.
For robustness, this change also implements two other defensive
changes : upon call to onUpdateSelection, we actually realize
that the previous values were wrong, so we also fix it at that
time, and in addition, when rotating, we finishComposingText()
instead of commitText() which is less dangerous. Implementing
this later change also allows us to let less internal variables
from InputLogic escape to LatinIME, so it's also a good change
for design.
Bug: 14140799
Change-Id: Ib10de18e53e376ac1bbc8487e13d969828483346
Tom Ouyang
Dan Zivkovic
Mohammadinamul Sheik
Jean Chalard
Ken Wakasa
Tadashi G. Takaoka
David Faden
Keisuke Kuroyanagi
Yohei Yukawa