¿Por qué los métodos de entrada de texto generalmente omiten una función de deshacer?

Estoy leyendo la documentación de recursos de mi teclado (normalmente uso MessagEase ) y veo que dicen:

Captura de pantalla de MessageEase

Tenga en cuenta que Android no proporciona Deshacer .

Sin embargo, sé que esto no es realmente cierto, al menos, no de manera aparente, porque cuando se usa un teclado físico Ctrl + Zse invoca undobien y no requiere ninguna aplicación adicional/externa, es decir, funciona de forma nativa a través de PNP genérico ( He usado variedades de telnet, BT y RF, todas las cuales funcionan). Y, sin embargo, misteriosamente, la función parece omitirse intencionalmente (descargo de responsabilidad: no tengo evidencia para respaldar esta conjetura).

De hecho, MessagEase tiene funcionalidades de entrada extendidas que incluyen controles de campo de formulario y controles de caracteres ASCII y, sin embargo, ingresar Ctrl+ Zda como resultado una notdefsalida de glifo exactamente en el mismo campo de formulario.

¿Por qué es este el caso?

EDITAR: tenga en cuenta que me refiero a conectar un teclado físico a un dispositivo Android, no estoy comparando PC vs Android UX.

Es posible implementarlo con la interfaz TextWatcher

Respuestas (1)

Esta pregunta puede obtener mejores respuestas de los desarrolladores que de la comunidad de usuarios finales.

El marco de trabajo de Android tiene una clase llamada "para administrar e interactuar con el estado de deshacer global para un documento o aplicación. Esta clase admite tanto deshacer como rehacer..." . Y la vista de Android (que se extiende y se usa comúnmente en aplicaciones para obtener la entrada de texto del usuario) admite las operaciones Deshacer y Rehacer desde Android 6 al menos. De hecho, un desarrollador de ROM puede mostrar estas opciones en el menú contextual de pulsación prolongada para cada aplicación, como vemos Copiar , Pegar y Seleccionar todo , que se muestran de forma predeterminada . Pero Deshacer/Rehacer siempre funciona si el teclado virtual o físico puede enviar eventos clave.UndoManager EditTextTextViewCTRL-ZCTRL-SHIFT-Z

Extendí el CTRL- soporte de eventos en AnySoftKeyboard para aplicaciones que no son terminales. Entonces cualquiera puede. Por qué no lo hacen es puramente una cuestión de elección. No hay limitación técnica.

Tenga en cuenta que la UndoManagerclase a partir de Android 12 está restringida, según: developer.android.com/about/versions/12/non-sdk-12#new-blocked También basado en: android.googlesource.com/platform/development/+log /refs/heads/… parece una característica bajo consideración y pausada/caída/oculta y se esperaba que los desarrolladores usaran TextWatcher para quizás implementar sus propias operaciones de deshacer/rehacer.
Las API ocultas de @MorrisonChang están ocultas para las aplicaciones, no para el marco. Por lo tanto, las restricciones que no pertenecen al SDK no se aplican a EditText/ TextView. A partir de la última confirmación, las operaciones de deshacer y rehacer se manejan por completo con estas clases de marco: android.googlesource.com/platform/frameworks/base/+/… . Pero incluso si Google elimina el soporte (que no parece ser el caso hasta ahora), extender EditTextla clase para manejar eventos clave y mantener el historial no será una gran tarea.
No estoy seguro de a qué 'desarrolladores' se refiere en su primera línea frente a su última línea, 'desarrolladores de Android framework' o 'desarrolladores de terceros'. Creo que mi punto era que la funcionalidad de deshacer/rehacer TextViewno está claramente explicada en la documentación oficial y solo se insinúa en la propiedad XML android:allowUndo . El hecho de que un desarrollador de aplicaciones de terceros necesite mirar la fuente del marco no es nuevo, pero es menos 'una cuestión de elección' que 'conciencia'.
@MorrisonChang "Creo que mi punto era que la funcionalidad de deshacer/rehacer TextViewno está claramente explicada en la documentación oficial" . Sí, ese es un punto válido. Y mi punto es que " Android no proporciona Deshacer " no suena como una excusa válida para no proporcionar una función tan pequeña. Es una cuestión de elección del desarrollador de la aplicación, aunque no tiene nada de malo.
¡Gracias por la información! ¿Podría dar más detalles cuando dijo "Pero Deshacer/Rehacer siempre funciona si el teclado virtual o físico puede enviar eventos de tecla CTRL-Z y CTRL-SHIFT-Z". Como mencioné en el OP, MessagEase puede enviar esas entradas, pero solo genera un notdefglifo.
Android's TextView/ EditTextmaneja los eventos Deshacer/Rehacer con seguridad; Proporcioné los enlaces al código fuente. "cuando se usa un teclado físico, Ctrl+Z invoca undomuy bien" . Esto definitivamente significa que su teclado virtual no está enviando el evento de tecla correcto. Cómo enviar estos eventos: Di el enlace en el último párrafo. Simplemente puede instalar el teclado ASK y probarlo usted mismo: github.com/mirfatif/AnySoftKeyboard
¿Por qué los métodos de entrada de texto generalmente omiten una función de deshacer?
RespuestasAquíPolítica de privacidad1y, 0v