De nombreuses applications ont une fonctionnalité qui vous déconnecte automatiquement après une certaine période d'inactivité. Cependant, certaines de ces applications vous déconnectent en fonction de l'inactivité de l'API, tandis que d'autres implémentent un minuteur de déconnexion en remplaçant les contrôles UIView. Dans cet article, nous allons explorer une meilleure façon d'obtenir ce comportement en utilisant la méthode hitTest. Et certaines applications vous déconnectent en fonction de la différence de temps entre la dernière connexion / appel API et l'heure actuelle. Le problème avec la dernière approche est que vous pouvez garder votre session constamment active en réglant manuellement votre heure sur un appareil au moment de la connexion. Le problème avec la première approche est que certains utilisateurs peuvent être déconnectés même s'ils ne font que faire défiler le contenu et ne font aucune demande au backend. Imaginez un utilisateur qui lit les termes et conditions d'un certain produit bancaire avant de l'ouvrir et il est déconnecté. Nous voulons absolument éviter cela. Le problème avec la deuxième approche est qu'il peut être difficile d'implémenter la fonction de déconnexion en cas d'inactivité dans une base de code existante, en particulier si l'application a une grande base de code avec des vues personnalisées. C'est là que la méthode hitTest peut être très utile. Réponse courte Nous pouvons utiliser un hack avec la méthode hitTest afin de prévaloir des problèmes répertoriés. Supposons que nous ayons déjà une version implémentée d'une classe responsable du suivi du temps d'activité d'un utilisateur. Nous allons l'exprimer avec l'API suivante : protocol IUserActivity { func resetInactiveTime() } Maintenant, déclarons une extension d'une UIWindow dans notre application : extension UIWindow { open override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? { userActivity.resetInactiveTime() return super.hitTest(point, with: event) } } Et c'est tout! Désormais, cette méthode sera déclenchée à chaque événement interactif effectué par l'utilisateur sur un écran, tel que l'enregistrement, le défilement et d'autres activités gestuelles. Vous pouvez également déclarer une sous-classe d'une UIWindow et y remplacer une méthode hitTest. Attendez, comment ça marche ?🤔 (Réponse longue) Les événements tactiles dans proviennent généralement des interactions de l'utilisateur avec l'écran tactile de l'appareil. iOS Lorsque l'utilisateur touche l'écran, le matériel détecte le toucher et génère un flux de données tactiles brutes qui comprend des informations telles que l'emplacement, la pression et la durée du toucher. Ces données tactiles brutes sont ensuite traitées par le système d'exploitation et transformées en événements tactiles de haut niveau pouvant être gérés par UIKit. Le système d'exploitation détermine à quel objet UIWindow l'événement tactile correspond en fonction de l'emplacement tactile et de la hiérarchie de la vue, puis envoie l'événement tactile à l'objet UIResponder de cet objet pour traitement. Lorsqu'un événement tactile se produit, le système d'exploitation iOS utilise un algorithme de test d'atteinte pour déterminer à quel objet UIView ou UIWindow l'événement tactile correspond. L'algorithme de test d'atteinte commence à l'objet UIWindow de niveau supérieur et vérifie de manière récursive chaque sous-vue dans la hiérarchie des vues jusqu'à ce qu'il trouve la vue la plus profonde contenant le point de contact. Pour ce faire, il vérifie si le point de contact se trouve à l'intérieur du cadre de chaque sous-vue. Le hit-test utilise un algorithme de parcours de pré-ordre inverse en profondeur d'abord. En d'autres termes, l'algorithme visite d'abord le nœud racine, puis traverse ses sous-arbres des index supérieurs aux index inférieurs. Ce type de parcours permet de réduire le nombre d'itérations de parcours et d'arrêter le processus de recherche une fois que la première vue descendante la plus profonde contenant le point de contact est trouvée. Ceci est possible car une sous-vue est toujours rendue devant sa supervue, et une vue sœur est toujours rendue devant ses vues sœurs avec un index inférieur dans le tableau des sous-vues. Lorsque plusieurs vues superposées contiennent un point spécifique, la vue la plus profonde dans le sous-arbre le plus à droite sera la vue la plus en avant . (1) Comme nous pouvons le voir, l'algorithme de traversée commence toujours à partir de l'objet UIWindow, quelle que soit la vue ou le contrôle avec lequel l'utilisateur interagit. Et nous pouvons certainement l'utiliser à nos fins simplement en interceptant ces événements dans la méthode hitTest de la classe UIWindow ! C'est ça! Faites-moi savoir ce que vous pensez dans les commentaires ci-dessous.
