android - qué - tipos de conocimiento

Una forma confiable de saber cuándo se cancela el teclado suave de Android(devolución de llamada que funciona en todos los teléfonos)

Question

Estamos trabajando en nuestra primera aplicación de Android y ha sido una experiencia muy agradable hasta el momento. Está casi completo, pero antes del lanzamiento estamos teniendo algunas consideraciones, principalmente sobre el teclado suave de Android.

Tenemos un par de campos EditText que se utilizan para ingresar números. Nos gustaría capturar el evento cuando el usuario presione enter, y hacer algunas calcuaciones y guardar en esta devolución de llamada.

El problema es que no recibimos un evento fijo ya que diferentes teléfonos tienen diferentes teclados. Algunos tienen el botón "Hecho" y nuestros teléfonos HTC tienen botones "Entrar". Intentamos utilizar imeOptions como ''hecho'', pero eso no tuvo ningún efecto en los teléfonos HTC.

También sabemos que el teclado se puede descartar presionando el botón Atrás . Así que mi pregunta es si hay una manera confiable de saber cuándo el usuario ha dejado de ingresar o si el teclado está oculto, como textFieldShouldReturn callback en iphone sdk (que siempre se activará cuando el teclado se apaga, independientemente de la tecla que lo haya provocado abajo)..

En otras palabras, ¿cómo un desarrollador de Android maneja el teclado virtual? Compruebo KeyEvent.KEYCODE_ENTER en editText onClick () evento y hago mis tareas allí. Está trabajando en mi HTC Android, pero no en mis amigos Nexus, que tiene un botón hecho en lugar de enter. No se llama onClick. ¿Cómo maneja esto un desarrollador?

EDITAR: Después de perder la mitad de mi cabello, y con la ayuda de algunos buenos amigos aquí

He intentado todas sus sugerencias, pero al final, al usar onEditorActionListener junto con el método onKeyListener hice el truco para mí. En la devolución de llamada de onEdit de onEditorActionListener revisé el código de tecla ACTION_DONE , que sí recibió una llamada en los teclados con el botón de hecho. En los teclados que tiene entrar onKey se llama. En el método onKey también busqué KEYCODE_BACK , de modo que también se puede manejar el evento de retroceso de hardware. Todavía no he descubierto un dispositivo Android con hecho e ingresado en el teclado (en serio), aún así manejé ese caso con una bandera. Gracias @Femi por sugerir onEditorActionListener y gracias a todos los amigos por su ayuda. Pero la respuesta a mi pregunta original

P: ¿Existe una forma confiable y más fácil de saber que el teclado suave de Android renuncia (devolución de llamada que funciona en todos los teléfonos)

Resp .: No, todos los métodos sugeridos aquí y todos los métodos sugeridos en otros sitios no son sencillos. Y creo que manejar un evento para la tecla de retorno del teclado es lo más básico para cualquier sistema operativo. Google, ¿estás ahí?

Answer 1

No puedo creer que Google no tenga una devolución de llamada independiente del teclado para este caso

Wow, no puedo creer eso tampoco. Tengo un problema similar en este momento. Además de IME ACTION, compruebo los cambios de foco en EditFields. Esto está bien la mayor parte del tiempo, pero no funcionará siempre.

Encontré una forma de recibir notificaciones cuando se oculta el teclado, pero todavía no es una solución completa (y no estoy seguro si es una buena idea), pero no tengo tiempo para continuar ahora mismo, así que pensé que podía dejar el comienzo de la idea aquí ...

Escriba su propio EditText (extienda EditText) y anule onCreateInputConnection . En su onCreateInputConnection devuelva su propia implementación de InputConnection (simplemente puede extender BasicInputConnection. El método "finishComposingText ()" de InputConnections siempre se invoca cuando se oculta el teclado (también cuando el usuario presiona la tecla de retroceso).

Este es el código, y tal vez alguien más tiene una idea, por qué el texto ingresado no se muestra en este campo de edición ;-)

public class MyEditText extends EditText{
public MyEditText(Context context) {
super(context);
}
public MyEditText(Context context, AttributeSet attrs) {
super(context);
}
public MyEditText(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
}
@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
System.out.println("onCreateInputConnection, "+outAttrs.actionId);
return new MyInputConnection(this,true);
}
private class MyInputConnection extends BaseInputConnection{
public MyInputConnection(View targetView, boolean fullEditor) {
super(targetView, fullEditor);
}
@Override
public boolean finishComposingText() {
System.out.println("FINISH");
return super.finishComposingText();
}
}
}

JPM

Answer 2

¿Has intentado implementar la vista personalizada EditText, donde reemplazas a dispatchKeyEventPreIme? Al igual que en la respuesta publicada por Arnaud (haciendo referencia al botón Atrás de la intercepción desde el teclado virtual), pero en lugar de usar un diseño personalizado, utilice EditText personalizado y anule:

@Override
public boolean dispatchKeyEventPreIme(KeyEvent event) {
if(KeyEvent.KEYCODE_BACK == event.getKeyCode()) {
//this hides soft keyboard in super.dispatchKeyEventPreIme(event)
}
return super.dispatchKeyEventPreIme(event);
}

Sugerí esta solución en esta pregunta

Answer 3

¿No necesitarías realizar esos cálculos cuando el usuario esté dejando TextView en un teclado de hardware? No me enfocaría en el teclado, sino en el TextView mismo. Si es así, lo que probablemente quiera es setTransformationMethod

Tendría que implementar un método de TransformationMethod personalizado, específicamente el método getTransformation, que transforma una fuente CharSequence en otra. A continuación, puede utilizar el método onFocusChanged para aplicarlo solo cuando se pierde el foco para ese TextView.

Answer 4

Dado que parece que está capturando el evento KEYCODE_ENTER , es posible que pueda usar esto: http://developer.android.com/reference/android/widget/TextView.html#setOnEditorActionListener%28android.widget.TextView.OnEditorActionListener%29 . En teoría, esto le permitirá detectar cualquiera que sea la acción final del método de entrada (ya sea atrás, hecho, ingresar o lo que sea) y responder a ella.

Avísame si eso funciona para ti.

Answer 5

Encontré una solución en esta página SO: Interceptar el botón Atrás desde el teclado suave

La respuesta de mhradek tiene 0 votos pero parece estar funcionando.

La idea es ampliar el diseño base de su actividad para que pueda anular el método dispatchKeyEventPreIme y hacer lo que quiera con respecto al KeyEvent pasado. Tenga en cuenta que usted es responsable de administrar el teclado virtual.

Lo estoy usando y definitivamente puedo interceptar golpes de tecla (el botón de retroceso, por ejemplo) sin que el teclado suave los "comiera". Todavía tengo que jugar más con eso para ver qué es posible y qué no.

Espero que ayude.

Answer 6

Este código funciona bien para mí con HTC y el teclado predeterminado de Android:

editText.setOnEditorActionListener(new TextView.OnEditorActionListener() {
@Override
public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
// handle enter key on keyboard
if (actionId == EditorInfo.IME_ACTION_SEND ||
(event != null && event.getKeyCode() == KeyEvent.KEYCODE_ENTER && event.getAction() == KeyEvent.ACTION_DOWN)) {
if (uid != null) {
// hide keyboard
InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(v.getWindowToken(), 0);
// perform other stuff
return true;
}
}
return false;
}
});

Usando lo siguiente en el XML de editText:

android:imeOptions="actionSend"

Por supuesto, también podría usar algo más como enviar, solo asegúrese de cambiarlo tanto en el código XML como en el código Java.

Answer 7

No lo he intentado pero, al leer la documentación, parece posible.

// From an activity, you can call
if (getResources().getConfiguration().keyboardHidden == Configuration.KEYBOARDHIDDEN_YES) {
// your code here
}