ios - uitextfielddelegate

¿Por qué se cambió la propiedad de texto de UITextField a una opción en Swift 2?

Question

De acuerdo con el documento UIKit diff , en ios9 / Swift 2

var text: String! se ha convertido en var text: String?

De acuerdo con la documentación para UITextField , dice específicamente

This string is @"" by default.

No entiendo el propósito de este cambio. ¿No debería esa propiedad ser siempre una cadena vacía si el campo de texto existe? ¿En qué punto este campo devuelve una cadena vacía? Una vez que el usuario interactúa con eso? ¿Una vez que se ha agregado a la jerarquía de vista? ¿En qué punto regresa nil ?

Si el campo de texto existe en primer lugar, ¿siempre es seguro asumir que también existe la propiedad de texto? ¡Esto parece .text que va a llevar a mucho encontrar / reemplazar .text a .text!

No veo dónde se menciona en los documentos, así que tal vez alguien tenga alguna historia de fondo o ayuda sobre por qué esto cambió.

Answer 1

En resumen, (respuesta al título) no fue así.

En detalle:

Para mí tiene mucho más sentido tenerlo como una opción que no se desenvuelve forzosamente. Apple está presionando a los desarrolladores para que nunca utilicen optional! y solo tiene sentido que apliquen las mismas reglas a las API.

La razón de esto es que puede ser nulo, y no hace ninguna diferencia si se declara con ? o ! para ejecutar el código. Usando ! en realidad solo elimina las advertencias en Xcode que son realmente útiles, especialmente cuando se trata de código API. Si no te das cuenta de que en realidad es una opción, solo estás pidiendo problemas.

La comprobación de nil también es mucho más agradable ahora con el guard y puede encadenar esto con un cheque para "" así que no es realmente más trabajo.

En general, las opciones son mejores porque algo que es nulo no usa memoria. Mientras más opcionales obtenemos, más ligero podemos hacer nuestras aplicaciones. Además, ni siquiera se ve mal y no se agrega a la pirámide de la perdición.

Este ejemplo tomará ambas cadenas como argumentos, ¿quita ? en el parámetro func y Xcode estará allí para advertirte.

Olvidé responder esta parte directamente: se vuelve nula cuando la configura en cero, lo que puede hacer para guardar un poco de memoria. Simplemente no tiene sentido tener la opción de configurarlo en cero y no tener xcode advirtiéndole que lo maneje correctamente. => Esto es imposible ...

var forcedUnwrappedString : String! = ""
var optionalString : String? = ""

forcedUnwrappedString = nil
optionalString = nil

func doSomethingWithString(string : String?) -> String? {
    guard var unwrappedString = string else {
        // error handling here
        return nil
    }
    let tempString = unwrappedString + "!"

    return tempString
}

func doSomethingUnsafeWithString(string : String) -> String {

    let tempString = string
    return tempString

}

var newString = doSomethingWithString(optionalString)
var newString2 = doSomethingWithString(forcedUnwrappedString)

newString = doSomethingUnsafeWithString(optionalString!) // this will crash without a warning fro xcode
newString2 = doSomethingUnsafeWithString(forcedUnwrappedString) // this will crash without a warning fro xcode

Actualizar:

La propiedad de texto de UITextfield tiene un setter que siempre se establece en "" en caso de nil , no hay información sobre esto en ninguna parte de los documentos o en los archivos .h de UIKit.

var textField = UITextField(frame: CGRect(x: 0, y: 0, width: 0, height: 0))
var string = textField.text // string = ""
textField.text = nil
string = textField.text // string = ""

Answer 2

Como Menke se mencionó a sí mismo, en realidad es imposible establecer el text en cero. Obviamente, Apple quiere que se documente como nulable, a pesar de la implementación actual, y para mí no tiene ningún sentido, quiero decir que no tiene suficiente sentido para mí. El hecho es que definitivamente no es "incorrecto" que Apple decida eso, pero ¿es la forma elegante de hacer las cosas para todos? Obviamente no. Y si no está de acuerdo con ellos, no se preocupe, está totalmente bien que reserve sus opiniones sobre algunas de las decisiones de Apple.

Entonces, ¿cuál es el propósito de este cambio? Tal vez comenzaron una regla interna que dice que nunca se deben anular las propiedades de los componentes de UIKits por motivos de consistencia. Quizás piensan que, en teoría, es posible liberar la propiedad del texto debido a la presión de la memoria en algún caso extremo. Sean lo que sean, no creo que sean válidos, sin embargo, debemos obedecer. Sin embargo, esto no me convierte en fanboy.

Answer 3

Una forma sencilla de solucionar este problema es crear una extensión para UITextField y usarla en lugar de la propiedad .text.

extension UITextField {
    var unwrappedText: String {
        return self.text ?? ""
     }
}

Ahora puedes decir textfield.unwrappedText sin preocuparte por los opcionales. (Por supuesto, esto es solo para leer el valor).

Answer 4

También puedes usar este truco con carácter Unicode:

extension UITextField {
    var teхt: String { //"х" is U+0445 unicode character
        return self.text ?? ""
    }
}