Input-mask-ios: Símbolos fijos en la máscara.
Será genial tener la capacidad de usar símbolos fijos.
Por ejemplo, necesito la máscara para el número de teléfono: +7 (111) 111-11-11
Entonces, de acuerdo con la documentación, puedo crear una máscara para este caso: +7 ([000]) [000] - [00] - [00]
Y eso está bien. Pero necesito que el usuario no pueda borrar los dos primeros símbolos (+7). Así que cada vez que "+7" debe estar siempre visible en el campo de texto.
razalur
Todos 3 comentarios
Hola @razalur
Gracias por tu sugerencia. Volveré con comentarios un poco más tarde esta semana, ¡estad atentos!
taflanidi
en 2 mar. 2017
alguna actualización ?
TikhonovAlexander
en 4 may. 2017
@TikhonovAlexander hola. @razalur también podría estar interesado.
Gracias por recordarme esta solicitud de función. De hecho, tuvimos una breve charla con dos evangelistas de Apple acerca de tener un texto no editable dentro del campo de texto.
TL; DR: No vamos a admitir esta función.
No viola HIG directamente, aunque es una mala idea restringir el control del usuario sobre la aplicación y hacerse cargo de la toma de decisiones. Los campos de texto nativo no se comportan así, y el SDK de iOS ya tiene un componente para un texto estático: un UILabel .
No puede deshabilitar o atenuar un botón de retroceso del teclado nativo, y los símbolos no borrables generarán confusión, ya que el usuario final no podrá determinar si se trata de un comportamiento diseñado o un error. "¿Por qué exactamente mi botón Retroceso no funciona?" - y no puedes dar una pista clara.
Desde la perspectiva del diseño de nuestra biblioteca, es obvio que el desarrollador podría poner un símbolo "fijo" en el medio de la línea. Pero, ¿qué espera que suceda cuando el usuario comience a eliminar caracteres desde el principio de la línea?
Incluso surgen más preguntas cuando decide incorporar un botón UITextField Borrar.
El método de delegado correspondiente -textFieldShouldClear() no le permitirá borrar parcialmente su campo de texto, está destinado a borrar todo el texto. Anular o extender el comportamiento del botón claro es una decisión de diseño ambigua y, por lo tanto, una gran responsabilidad para nuestra biblioteca, porque tendremos que cubrir todos los casos de uso. Algunas personas (desarrolladores y usuarios ) querrán que el botón de borrar nativo borre todo el texto, alguien esperará que todos los símbolos "fijos" permanezcan después de borrarlos, y otros asumirán que solo el prefijo "fijo" debe permanecer y "fijo" los caracteres en el medio de la línea deben borrarse.
Lo único con lo que puedo ayudarlo es un consejo para pensar detenidamente en los objetivos que se proponen alcanzar.
No luche contra el SDK, ya que el SDK siempre gana.
taflanidi
en 4 may. 2017
Temas relacionados
TikhonovAlexander
·
3Comentarios
LinusGeffarth
·
4Comentarios
KompoD
·
5Comentarios
DamascenoRafael
·
4Comentarios
beltik
·
6Comentarios
Comentario más útil
@TikhonovAlexander hola. @razalur también podría estar interesado.
Gracias por recordarme esta solicitud de función. De hecho, tuvimos una breve charla con dos evangelistas de Apple acerca de tener un texto no editable dentro del campo de texto.
TL; DR: No vamos a admitir esta función.
No viola HIG directamente, aunque es una mala idea restringir el control del usuario sobre la aplicación y hacerse cargo de la toma de decisiones. Los campos de texto nativo no se comportan así, y el SDK de iOS ya tiene un componente para un texto estático: un
UILabel.No puede deshabilitar o atenuar un botón de retroceso del teclado nativo, y los símbolos no borrables generarán confusión, ya que el usuario final no podrá determinar si se trata de un comportamiento diseñado o un error. "¿Por qué exactamente mi botón Retroceso no funciona?" - y no puedes dar una pista clara.
Desde la perspectiva del diseño de nuestra biblioteca, es obvio que el desarrollador podría poner un símbolo "fijo" en el medio de la línea. Pero, ¿qué espera que suceda cuando el usuario comience a eliminar caracteres desde el principio de la línea?
Incluso surgen más preguntas cuando decide incorporar un botón
UITextFieldBorrar.El método de delegado correspondiente
-textFieldShouldClear()no le permitirá borrar parcialmente su campo de texto, está destinado a borrar todo el texto. Anular o extender el comportamiento del botón claro es una decisión de diseño ambigua y, por lo tanto, una gran responsabilidad para nuestra biblioteca, porque tendremos que cubrir todos los casos de uso. Algunas personas (desarrolladores y usuarios ) querrán que el botón de borrar nativo borre todo el texto, alguien esperará que todos los símbolos "fijos" permanezcan después de borrarlos, y otros asumirán que solo el prefijo "fijo" debe permanecer y "fijo" los caracteres en el medio de la línea deben borrarse.Lo único con lo que puedo ayudarlo es un consejo para pensar detenidamente en los objetivos que se proponen alcanzar.
No luche contra el SDK, ya que el SDK siempre gana.