Sistema de Respuesta a Gestos

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

El sistema de respuesta a gestos gestiona el ciclo de vida de los gestos en tu aplicación. Un toque puede pasar por varias fases mientras la app determina la intención del usuario. Por ejemplo, la app necesita determinar si el toque es un desplazamiento, un deslizamiento sobre un widget o una pulsación. Esto puede cambiar incluso durante la duración de un toque. También puede haber múltiples toques simultáneos.

El sistema de respuesta a toques es necesario para permitir que los componentes negocien estas interacciones táctiles sin necesidad de conocimiento adicional sobre sus componentes padres o hijos.

Mejores Prácticas

Para que tu aplicación se sienta excelente, cada acción debe tener estos atributos:

• Retroalimentación/resaltado: mostrar al usuario qué está manejando su toque y qué sucederá al liberar el gesto

• Capacidad de cancelación: al realizar una acción, el usuario debe poder abortirla a mitad del toque deslizando su dedo fuera

Estas características hacen que los usuarios se sientan más cómodos usando una app, pues permiten experimentar e interactuar sin miedo a cometer errores.

TouchableHighlight y Touchable*

El sistema de respuesta puede ser complejo de usar. Por eso proporcionamos una implementación abstracta Touchable para elementos que deben ser "pulsables". Esto utiliza el sistema de respuesta y te permite configurar interacciones de pulsación de manera declarativa. Usa TouchableHighlight donde usarías un botón o enlace en la web.

Ciclo de Vida del Respondedor

Una vista puede convertirse en el respondedor táctil implementando los métodos de negociación correctos. Hay dos métodos para preguntar a la vista si quiere ser respondedor:

• View.props.onStartShouldSetResponder: evt => true, - ¿Quiere esta vista convertirse en respondedor al inicio de un toque?

• View.props.onMoveShouldSetResponder: evt => true, - Llamado en cada movimiento táctil sobre la Vista cuando no es respondedora: ¿quiere esta vista "reclamar" la capacidad de respuesta táctil?

Si la Vista devuelve true e intenta convertirse en respondedora, ocurrirá una de estas opciones:

• View.props.onResponderGrant: evt => {} - La Vista ahora responde a eventos táctiles. Es el momento para resaltar y mostrar al usuario qué ocurre

• View.props.onResponderReject: evt => {} - Algo más es el respondedor actual y no lo liberará

Si la vista está respondiendo, pueden llamarse estos manejadores:

• View.props.onResponderMove: evt => {} - El usuario está moviendo su dedo

• View.props.onResponderRelease: evt => {} - Se activa al final del toque (ej. "touchUp")

• View.props.onResponderTerminationRequest: evt => true - Algo más quiere ser respondedor. ¿Debe esta vista liberar al respondedor? Devolver true permite la liberación

• View.props.onResponderTerminate: evt => {} - El respondedor ha sido quitado a la Vista. Puede ser tomado por otras vistas tras llamar a onResponderTerminationRequest, o por el sistema operativo sin preguntar (ocurre con el centro de control/notificaciones en iOS)

evt es un evento táctil sintético con esta estructura:

• nativeEvent
  • changedTouches - Matriz de eventos táctiles que cambiaron desde el último evento
  • identifier - El ID del toque
  • locationX - Posición X del toque relativa al elemento
  • locationY - Posición Y del toque relativa al elemento
  • pageX - Posición X del toque relativa al elemento raíz
  • pageY - Posición Y del toque relativa al elemento raíz
  • target - ID del nodo del elemento que recibe el evento táctil
  • timestamp - Identificador temporal del toque, útil para cálculos de velocidad
  • touches - Matriz de todos los toques actuales en pantalla

Captura de manejadores ShouldSet

onStartShouldSetResponder y onMoveShouldSetResponder se invocan mediante un patrón de burbujeo, donde el nodo más profundo se llama primero. Esto significa que el componente más profundo se convertirá en respondedor cuando múltiples Views devuelvan true para los manejadores *ShouldSetResponder. Esto es deseable en la mayoría de los casos, ya que garantiza que todos los controles y botones sean utilizables.

Sin embargo, a veces un componente padre querrá asegurarse de convertirse en respondedor. Esto puede manejarse usando la fase de captura. Antes de que el sistema de respondedores suba en burbuja desde el componente más profundo, realizará una fase de captura que activa on*ShouldSetResponderCapture. Por lo tanto, si una View padre quiere evitar que el hijo se convierta en respondedor al iniciar un toque, debe tener un manejador onStartShouldSetResponderCapture que devuelva true.

• View.props.onStartShouldSetResponderCapture: evt => true,

• View.props.onMoveShouldSetResponderCapture: evt => true,

PanResponder

Para interpretación de gestos de nivel superior, consulta PanResponder.