Cómo desconectar de forma segura a los usuarios de las aplicaciones de iOS con el tiempo de espera de inactividad

Muchas aplicaciones tienen una función que cierra la sesión automáticamente después de un cierto período de inactividad. Sin embargo, algunas de estas aplicaciones cierran la sesión en función de la inactividad de la API, mientras que otras implementan un temporizador de cierre de sesión anulando los controles de UIView. En este artículo, exploraremos una mejor manera de lograr este comportamiento utilizando el método hitTest. Y algunas aplicaciones cierran su sesión en función de la diferencia de tiempo entre el último inicio de sesión/llamada a la API y la hora actual. El problema con el último enfoque es que puede mantener su sesión constantemente activa configurando manualmente su tiempo en un dispositivo al punto de inicio de sesión.

El problema con el primer enfoque es que algunos usuarios pueden cerrar sesión incluso si solo se desplazan por el contenido y no realizan ninguna solicitud al backend. Imagine un usuario que lee los términos y condiciones de un determinado producto bancario antes de abrirlo y está desconectado. Definitivamente queremos evitar esto.

El problema con el segundo enfoque es que puede ser difícil implementar la función de cierre de sesión por inactividad en un código base existente, especialmente si la aplicación tiene un código base grande con vistas personalizadas.

Aquí es donde el método hitTest puede ser muy útil.

Respuesta corta

Podemos usar un truco con el método hitTest para prevalecer sobre los problemas enumerados.

Supongamos que ya tenemos una versión implementada de una clase que es responsable de rastrear el tiempo de actividad de un usuario.

Lo vamos a expresar con la siguiente API:

 protocol IUserActivity {  func resetInactiveTime() }

Ahora, declaremos una extensión de una UIWindow en nuestra aplicación:

 extension UIWindow { open override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? { userActivity.resetInactiveTime() return super.hitTest(point, with: event) } }

¡Y eso es! Ahora, este método se activará en cada evento interactivo que el usuario realice en una pantalla, como grabar, desplazarse y otras actividades de gestos.

También puede declarar una subclase de una UIWindow y anular un método hitTest allí.

Espera, ¿cómo funciona eso? 🤔 (Respuesta larga)

Los eventos táctiles en iOS generalmente se originan a partir de las interacciones del usuario con la pantalla táctil del dispositivo.

Cuando el usuario toca la pantalla, el hardware detecta el toque y genera un flujo de datos táctiles sin procesar que incluye información como la ubicación, la presión y la duración del toque.

Estos datos táctiles sin procesar luego son procesados por el sistema operativo y transformados en eventos táctiles de alto nivel que UIKit puede manejar. El sistema operativo determina a qué objeto UIWindow corresponde el evento táctil en función de la ubicación táctil y la jerarquía de vista, y luego envía el evento táctil al objeto UIResponder de ese objeto para su procesamiento.

Cuando ocurre un evento táctil, el sistema operativo iOS utiliza un algoritmo de prueba de aciertos para determinar a qué objeto UIView o UIWindow corresponde el evento táctil.

El algoritmo de prueba de aciertos comienza en el objeto UIWindow de nivel superior y verifica recursivamente cada subvista en la jerarquía de vistas hasta que encuentra la vista más profunda que contiene el punto de contacto. Para ello, comprueba si el punto de contacto está dentro del marco de cada subvista.

La prueba de aciertos utiliza un algoritmo transversal de pedido anticipado inverso que prioriza la profundidad. En otras palabras, el algoritmo visita primero el nodo raíz y luego recorre sus subárboles desde los índices más altos a los más bajos.

Este tipo de recorrido permite reducir el número de iteraciones de recorrido y detener el proceso de búsqueda una vez que se encuentra la primera vista descendiente más profunda que contiene el punto de contacto.

Esto es posible ya que una subvista siempre se representa delante de su supervista, y una vista hermana siempre se representa delante de sus vistas hermanas con un índice más bajo en la matriz de subvistas. Cuando varias vistas superpuestas contienen un punto específico, la vista más profunda en el subárbol más a la derecha será la vista más al frente (1) .

Como podemos ver, el algoritmo transversal siempre comienza desde el objeto UIWindow, sin importar con qué vista o control interactúe el usuario.

¡Y definitivamente podemos usar esto para nuestro propósito simplemente interceptando estos eventos en el método hitTest de la clase UIWindow!

¡Eso es todo! Déjame saber lo que piensas en los comentarios a continuación.