SwiftUI Fundamentals - Cap. 1: State & Binding

Antes de SwiftUI, los desarrolladores tenían UIKit para aplicaciones iOS y tvOS, AppKit para aplicaciones macOS y WatchKit para watchOS. Estos frameworks de UI estaban basados en eventos. Utilizando un paradigma de programación conocido como programación imperativa.

Como ejemplo, digamos que podríamos tener una función o conjunto de instrucciones que se llaman cuando se pulsa un botón. Otro ejemplo sería que tenemos un observador de eventos que realiza acciones una vez que se dispara el evento.

SwiftUI utiliza el paradigma de programación conocido como programación declarativa. En este caso podemos decir a nuestras aplicaciones lo que debe hacer y cómo debe ser en diferentes estados. La vista es reactiva a los cambios de estado y se actualiza por sí misma.

A continuación, veremos los diferentes property wrappers para conectar nuestra vista y código mediante estados.

@State

Cada cambio en el valor de una propiedad de @State es una señal para SwiftUI de que la jerarquía de vistas dentro de la cual se declara la propiedad necesita ser renderizada de nuevo.

  1. La vinculación a una propiedad de estado se realiza prefijando el nombre de la propiedad con el signo "$". Esto declara la variable como receptora de los cambios de estado.
  2. En el ejemplo del Texfield, a medida que el usuario escribe, la vista “Text” se actualizará automáticamente para reflejar la entrada del usuario en $userName.
  3. En el ejemplo del Toggle, los cambios se destinan a la variable receptora $wifiEnabled de tipo Boolean.
  4. Al contrario, la propiedad userName/wifiEnabled se declara sin el prefijo '$'. Esto es porque hacemos referencia al valor asignado a la propiedad state (es decir, el valor del String/Boolean que está escribiendo/editando el usuario) en lugar del puntero a la propiedad.

*Nota: Las variables @State siempre son privadas (private). Para acceder desde fuera de la vista usamos otros property wrappers a continuación.

*Nota: Las variables @State requieren definir su tipo y valor por defecto.

Digital Lover

@Binding

Utilizamos @Binding para propagar el valor de una propiedad entre diferentes vistas. Por ejemplo, pasar una variable de la vista A a B. Esto permite su interconexión de estados dando así la posibilidad de que los datos estén siempre actualizados entre todas las vistas que usen esa propiedad.

Podemos observar que la propiedad @State siempre tiene valor por defecto. En el caso de la vista hija, la variable “wifiEnabled” no tiene valor. Si intentamos crear la vista B, el constructor nos obliga indicar el puntero de la variable “wifiEnabled”. De forma indirecta, nos están diciendo que la vista B solo se puede crear si ofrecemos un puntero @State. Y a la vez, este es el motivo por el cuál no hay que definir un valor por defecto. Ya que la función de @Binding es enlazar la vista con el @State de la vista A.

*Nota: Las variables @Binding requieren definir su tipo.

*Nota: Las variables @Binding no pueden ser privadas, ya que la vista madre, tiene que acceder para notificar los cambios de estado de forma reactiva

 

 

Tags

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA