Introduce ThreadedInputConnection behind a switch

content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 package org.chromium.content.browser.input;
 
 import android.annotation.TargetApi;
 import android.content.Context;
 import android.os.Build;
 import android.os.IBinder;
 import android.os.ResultReceiver;
 import android.view.View;
 import android.view.inputmethod.CursorAnchorInfo;
 import android.view.inputmethod.InputMethodManager;
 
 import org.chromium.base.Log;
 
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+
 /**
  * Wrapper around Android's InputMethodManager
  */
 public class InputMethodManagerWrapper {
     private static final String TAG = "cr_Ime";
 
     private final Context mContext;
 
     public InputMethodManagerWrapper(Context context) {
         Log.d(TAG, "Constructor");
@@ skipping 53 matching lines @@
      * @see android.view.inputmethod.InputMethodManager#updateCursorAnchorInfo(View,
      * CursorAnchorInfo)
      */
     @TargetApi(Build.VERSION_CODES.LOLLIPOP)
     public void updateCursorAnchorInfo(View view, CursorAnchorInfo cursorAnchorInfo) {
         Log.d(TAG, "updateCursorAnchorInfo");
         if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
             getInputMethodManager().updateCursorAnchorInfo(view, cursorAnchorInfo);
         }
     }
+
+    /**
+     * Notify that a user took some action with the current input method. Without this call
+     * an input method app may wait longer when the user switches methods within the app.
+     */
+    public void notifyUserAction() {
+        // On N and above, this is not needed.
+        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.M) return;
+        Log.d(TAG, "notifyUserAction");
+        InputMethodManager manager = getInputMethodManager();
+        try {
+            Method method = InputMethodManager.class.getMethod("notifyUserAction");
+            method.invoke(manager);
+        } catch (NoSuchMethodException | IllegalAccessException | IllegalArgumentException

[palmer, 2016/02/25 23:49:55]

These are all subclasses of RuntimeException, right? You could just catch that
type to make the code more general and perhaps to catch more types of errors,
should they happen. (One the other hand, maybe you'd definitely want the
application to die in that case. I don't know.)

Also, if such an exception does happen, doesn't that mean something very odd
about the platform is happening? That is, if there is an InputMethodManager that
doesn't provide a notifyUserAction method, is it a super broken IMM? Maybe log
it more verbosely, or UMA it...? I dunno, maybe it doesn't matter.

Anyway, no action required; just a thought.

[Changwan Ryu, 2016/02/26 02:41:19]

Hmm... I think it is a matter of readability and discoverability of hidden
condition vs. general stability. I personally prefer exceptions to be stated
explicitly to understand the risks better.

+                | InvocationTargetException e) {
+            Log.d(TAG, "notifyUserAction failed");
+            return;
+        }
+    }
 }