Previously, a logbuffer only held an n-gram. Data went in and out of it, FIFO, until privacy
conditions were met (i.e. data not collected too frequently), and then an n-gram was saved.
E.g., if n=2, and only 10% of data is collected, then 18 words went through the logbuffer before
it captured the next 2 words.
However, if a user then went back and edited the n-gram, these edits were not captured.
This change changes the logbuffer size to temporarily hold data about words that are not recorded,
so that if the user backs up over them, the edits to an n-gram that we do eventually capture are
stored. If the example above, instead of a logbuffer holding 2 words, it holds 20. The system
waits until all the words not needed for the n-gram have been gathered (i.e. the buffer is full),
so the user has adequate time to edit, before shifting out the n-gram. The buffer is still flushed
when the user closes the IME. See the comment for MainLogBuffer for an explanation.
multi-project commit with I45317bc95eeb859adc1b35b24d0478f2df1a67f3
Change-Id: I4ffd95d08c6437dcf650d866ef9e24b6af512334
- Now includes all historical data stored in a motionEvent
- Simpler API, refactored to move extraction code to JsonUtils
Change-Id: I52d9756ddbeaa14d1704787da59bf1aad18f0335
- Default keypress volume is set to 0.2f in resource.
- Default keypress vibration duration is set to 10 msec in resource.
Bug: 7055329
Change-Id: I83bd6288d171d9787d52e2b02e4e5305f1435681
It's useless to setAutoCorrection(getTypedWord()). Every time the
contents of the word composer are altered, the auto-correction is
reset, and at use time if it's null then the typed word is used
anyway.
Change-Id: I0870657a1ab3f456f376995b27e70703f7a5d23a
Essentially this does activate auto-correction with a hardware
keyboard, although a lot of things are still left to implement.
No proximity is used yet which means only missing and excessive
letters are considered. Dead keys are not handled. No combiner
is supported. No suggestions are displayed. Resuming suggestions
does not work correctly with a hardware key (because the view
holds a temporary hardware event 'onKeyPreIme' and the event
from the IME won't be handled until this is handled which won't
happen until after the IME said that it did handle the event).
Bug: 5037589
Change-Id: Idcb5c7b26d56717ed772d53c062362807f11cdae
In this test, it's impossible that start < 0 so the test is useless.
I'm not sure what the cursor test was for, but it's very old code, and
it seems the assumption was either misled or doesn't hold any more:
testing for the absolute cursor position against the length of the
word against the cursor makes no sense.
The net result of this was that when the cursor index got large
enough, resuming suggestion would not work any more.
Bug: 7586467
Change-Id: I3462082374fe9579bec7698f4d424de6ff5f2ded