Tout d'abord, superbe bibliothèque. Facile à utiliser et fonctionne très bien :)
Maintenant, ai-je raison, si je voulais implémenter plusieurs champs de texte masqué, je devrais ajouter un objet MaskedTextFieldDelegate
pour chacun ?
Salut @LinusGeffarth !
Merci pour vos mots gentils.
Pour répondre à votre question, cela dépend du type de données que vous avez dans vos champs de texte.
Si vous avez, par exemple, plusieurs champs avec des numéros de téléphone, vous pouvez incorporer un seul objet MaskedTextFieldDelegate
pour tous car les masques seront les mêmes.
Bon, donc un objet délégué pour chaque masque.
Par curiosité : pourquoi ne l'avez-vous pas implémenté pour que le masque soit une propriété du champ de texte et que tous les champs de texte partagent le même délégué ?
pourquoi ne l'avez-vous pas implémenté pour que le masque soit une propriété du champ de texte et que tous les champs de texte partagent le même délégué ?
@LinusGeffarth , je n'appellerais pas cela une sage décision de conception.
Le champ de texte personnalisé interférerait avec d'autres champs de texte personnalisés et la hiérarchie d'héritage globale. Vous ne pourrez pas utiliser le masquage avec les champs de texte personnalisés d'autres bibliothèques ; ou sinon, vous vous retrouverez avec tous vos champs de texte ayant une propriété mask, ce qui contredit le bon sens. La même histoire se produirait avec vos UITextView
s, et c'est encore plus décevant.
En utilisant un rasoir d'Occam, la seule chose sur laquelle notre bibliothèque fonctionne, ce sont les modifications de texte. De ce point de vue, la meilleure façon d'implémenter sa fonctionnalité est de se connecter au rappel on text changed
, comme cela a été fait pour l'homologue Android.
Ce qui s'en rapproche le plus, c'est un stupide protocole UITextFieldDelegate
et la propriété delegate
; onEditingChanged
événements UITextView
.
C'est donc le moyen le plus optimal avec le moins d'entités synthétiques et le moins d'impact sur le projet de l'utilisateur.
Les SDK iOS et macOS sont déjà mal conçus, ne compliquons pas la vie de nos collègues développeurs. (- :
Si vous avez des questions connexes, veuillez les poser immédiatement ; sinon merci de fermer ce fil.
C'est logique, merci pour l'élaboration !