Meilleure façon d'autoriser la modification de texte sur une interface utilisateur iPhone complexe

Question

J'ai une hiérarchie de vue iOS quelque peu complexe. Un morceau de texte est un UITextField éditable. Lorsque l'utilisateur le touche, il devient le premier répondeur et est modifiable.

Voici le problème, cependant: La meilleure pratique devrait être qu'une touche n'importe où en dehors du contrôle d'édition l'amène à démissionner du premier répondeur et à terminer l'édition. Quelle est la meilleure façon d'accomplir cela?

Techniques J'ai essayé:

1. Utilisez la propriété exclusiveTouch, qui empêche l'utilisateur d'interagir avec d'autres contrôles, mais ne provoque pas de modification à la fin. Empêche également l'utilisateur d'interagir avec le bouton "Terminé" de ma barre d'outils.
2. Placez un UIView transparent sous le contrôle de champ de texte et par-dessus tout (sauf la barre d'outils), et utilisez les touches pour terminer la modification. Cela fonctionne, mais je finis par reparer le champ de texte sur cette autre vue aléatoire qui se trouve au-dessus de toute ma hiérarchie, ce qui signifie que je dois m'occuper de la disposition du champ de texte à plusieurs endroits. à l'origine, et je dois déléguer tout son comportement de sa vue «bouclier» à son conteneur d'origine, qui a toutes les logiques connexes.

Existe-t-il une solution élégante à ce problème qui me manque? Je pense que cela doit être un problème de conception commun.

Merci.

Answer 1

Mosaïque 4 vues "see-thru" autour de la vue de texte pour capturer/ignorer les touches. Ne nécessite pas de modifier ou de "soulever" la vue de texte, et peut être ajouté à la vue parente de manière assez modulaire.

Vous ne pouvez pas masquer une région sans savoir ce que ce masque couvrira et ce que le masque ne couvrira pas. Ainsi, toute solution nécessitera une portée suffisante pour rassembler ces deux limites. Vous pouvez soit faire passer le texte par le rectangle, soit désactiver le rectangle/la région de la vue, ou les deux par quelque chose entre les deux. Le contrôleur pour les choses à couvrir semble être un bon endroit pour consolider à la fois les régions ou les régions, sinon le contrôleur pour la vue du texte.

Answer 2

Si vous modifiez votre vue de base à UIControl, vous pouvez ajouter un IBAction à ce calque qui renonce à votre champ de texte en tant que premier répondeur.

De même, si vous avez plusieurs événements tactiles, assurez-vous qu'ils sont tous becomeFirstResponder lorsque vous les touchez.

J'aimerais avoir quelques détails pour qualifier mes explications xD

Answer 3

L'essentiel de la question est ce qui constitue la « meilleure pratique ». Le fait que le clavier reste à moins que l'utilisateur le rejette est délibéré. Par exemple, de nombreuses applications nécessitent que l'utilisateur puisse appuyer sur un bouton tout en continuant de travailler dans un champ de texte.

Le clavier a un bouton Retour. La "meilleure pratique" consiste à répondre à l'utilisateur en appuyant sur ce bouton en démissionnant du premier répondeur. Sinon, vous devriez laisser le clavier là, puisque c'est ce que l'utilisateur attend. Cependant, si vous insistez pour le faire à votre façon, il existe une solution simple: mettre un UITapGestureRecognizer en arrière-plan. Son gestionnaire sera déclenché si l'utilisateur appuie sur l'arrière-plan ou sur un bouton ou similaire dans l'interface. Ainsi, en supposant que vous ayez conservé un enregistrement de ce qu'est le premier répondeur, vous pouvez envoyer un premier message à l'interlocuteur principal du répondeur.