[IL79] Some refactoring

Bug: 8636060
Change-Id: I931c553f68a1f15d22711a661dbffd4e5d421979
main
Jean Chalard 2014-01-24 14:03:08 +09:00
parent 10460441db
commit f59487379e
2 changed files with 18 additions and 20 deletions

View File

@ -912,8 +912,14 @@ public class LatinIME extends InputMethodService implements KeyboardActionListen
composingSpanEnd, mInputLogic.mConnection);
}
if (mInputLogic.onUpdateSelection(mSettings.getCurrent(), oldSelStart, oldSelEnd,
newSelStart, newSelEnd, composingSpanStart, composingSpanEnd)) {
// If the keyboard is not visible, we don't need to do all the housekeeping work, as it
// will be reset when the keyboard shows up anyway.
// TODO: revisit this when LatinIME supports hardware keyboards.
// NOTE: the test harness subclasses LatinIME and overrides isInputViewShown().
// TODO: find a better way to simulate actual execution.
if (isInputViewShown() &&
mInputLogic.onUpdateSelection(mSettings.getCurrent(), oldSelStart, oldSelEnd,
newSelStart, newSelEnd, composingSpanStart, composingSpanEnd)) {
mKeyboardSwitcher.updateShiftState();
}

View File

@ -195,24 +195,7 @@ public final class InputLogic {
final int oldSelStart, final int oldSelEnd,
final int newSelStart, final int newSelEnd,
final int composingSpanStart, final int composingSpanEnd) {
final boolean selectionChanged = oldSelStart != newSelStart || oldSelEnd != newSelEnd;
// if composingSpanStart and composingSpanEnd are -1, it means there is no composing
// span in the view - we can use that to narrow down whether the cursor was moved
// by us or not. If we are composing a word but there is no composing span, then
// we know for sure the cursor moved while we were composing and we should reset
// the state. TODO: rescind this policy: the framework never removes the composing
// span on its own accord while editing. This test is useless.
final boolean noComposingSpan = composingSpanStart == -1 && composingSpanEnd == -1;
// If the keyboard is not visible, we don't need to do all the housekeeping work, as it
// will be reset when the keyboard shows up anyway.
// TODO: revisit this when LatinIME supports hardware keyboards.
// NOTE: the test harness subclasses LatinIME and overrides isInputViewShown().
// TODO: find a better way to simulate actual execution.
// TODO: remove the #isInputViewShown() call from here.
if (mLatinIME.isInputViewShown() && !mConnection.isBelatedExpectedUpdate(oldSelStart,
newSelStart, oldSelEnd, newSelEnd)) {
if (!mConnection.isBelatedExpectedUpdate(oldSelStart, newSelStart, oldSelEnd, newSelEnd)) {
// TODO: the following is probably better done in resetEntireInputState().
// it should only happen when the cursor moved, and the very purpose of the
// test below is to narrow down whether this happened or not. Likewise with
@ -221,6 +204,15 @@ public final class InputLogic {
// state-related special processing to kick in.
mSpaceState = SpaceState.NONE;
// if composingSpanStart and composingSpanEnd are -1, it means there is no composing
// span in the view - we can use that to narrow down whether the cursor was moved
// by us or not. If we are composing a word but there is no composing span, then
// we know for sure the cursor moved while we were composing and we should reset
// the state. TODO: rescind this policy: the framework never removes the composing
// span on its own accord while editing. This test is useless.
final boolean noComposingSpan = composingSpanStart == -1 && composingSpanEnd == -1;
final boolean selectionChanged = oldSelStart != newSelStart || oldSelEnd != newSelEnd;
// TODO: is it still necessary to test for composingSpan related stuff?
final boolean selectionChangedOrSafeToReset = selectionChanged
|| (!mWordComposer.isComposingWord()) || noComposingSpan;