¿Por qué debemos empezar conociéndolo?
Cada aplicación para iOS esta hecha por muchos objetos que se mandan mensajes unos a otros. La estructura de Modelo-Vista-Controlador es una manera de organizar tus objetos en tres campos.
En esta blog te introduciremos en cada campo y discutiremos como los componentes deben comunicarse entre cada uno
Las tres categorias
Las Apps de tu iphone consiste en una o mas escenas entre las que los usuarios navegan. Cada escena es manejada por un controlador de la vista. la escena podría contener botones, etiquetas y otros *widgets que Apple provee y tal vez incluso algunos widgets configurase que tu creas o modificas.
Cuando el usuario hace una selección, lleva a cabo un gesto, o toca un botón en particular, la escena cambia. El controlador de la vista actual pasa entonces suficiente información al controlador a cargo de la vista de la nueva escena y entonces ayuda a hacer la transición.
Es mas sencillo escribir y mantener tu app si organizas todos los objetos en tres categorías: modelos, vistas y controladores.
Modelo
El modelo consiste en objetos que capturan que es nuestra aplicación. Y esto es independiente de como nuestra aplicación es mostrada.
Por ejemplo si estuviéramos diseñando una aplicación que muestra datos en una tabla, nuestro modelo contendría la data que es mostrada en la vista de la tabla, pero este no conocería la manera mostraremos estos datos.
Controlador
En la programación de iOS escucharas muchas cosas acerca de los controladores de las vistas, estos son nuestros objetos controladores. Pasaras la mayoría de tu tiempo escribiendo códigos para objetos en este campo.
El controlador es el intermediario entre el modelo y la vista y es el responsable de como se muestra el modelo al usuario. De esta manera es que funciona la lógica del UI (User Interface - Interfaz de usuario). Podría determinar por ejemplo, como representar un planeta y una nave espacial orbitando dada una altura.
Vista
Usaras objetos genéricos para construir tu vista. La meta es usar los botones y las etiquetas y otros objetos que Apple ha creado para nosotros y manejarlos usando los controladores de tus vistas. Es por esto que decimos que las vistas son tus servidores de los controladores
Esto es importante para la programación en iOS. Tu vista esta hecha de sencillos objetos que hacen que están a las ordenes de su amo. No tendemos a convertir a estos objetos genéricos en subclases como veras en otros lenguajes.
En adelante solo resumir la forma en que deben comunicarse estos objetos entre otros
Lo Fundamental en la comunicación
En la configuración de nuestro MVC hay tres reglas básicas de comunicación:
1.- No tiene restricciones o limites en ciertas direcciones
2.- Prohibida entre los objetos en ciertas direcciones
3.- Se realiza de una forma estilizada en la que el objeto sabe muy poco, o nada, del objeto con el cual se esta comunicando
Tratare de explicar las dos primeras formas de comunicación
Controlando el modelo
El trabajo del controlador es mantener al modelo en la pantalla. esto significa que el controlador debe ser capaz de comunicarse con el modelo para hacerle preguntas, esta comunicación no tiene restricciones.
En código, el controlador necesita importar los archivos de cabecera para los objetos del modelo y entonces él puede enviar los mensajes para accesar a las propiedades declaradas en los archivos de cabecera
Del controlador a la vista
El controlador en cambio tiene acceso sin restricciones a la vista y este controla de igual manera las sub-vistas que la principal contiene. En otras palabras, el controlador debe tener acceso a sus servidores o sera incapaz de controlar lo que el usuario ve en pantalla.
En código, indicando que la comunicación que fluye en esta dirección luce un poco diferente que cuando importamos un archivo local como vehículo.h o planeta.h los cuales son los archivos de cabecera de un modelo, que pudiera ser tabla.h en consonancia con la explicación anterior.
En lugar de importar archivos de cabeceras para etiquetas, un botón, y así por el estilo (los cuales serian UILabel.h, UIButton.h…) importamos entonces un archivo de cabecera comprimido que se llama UIKit.h del framework o entorno de trabajo UIKit. Y ¿como hacemos esto en código?, pues colocamos la siguiente instrucción #import . Esto importa los archivos de cabecera para los UILabel, UIButton y otros componentes individuales que son parte de la vista
El Modelo y la vista
El modelo nunca habla a la vista. Una de las razones es que esto le permite al modelo ser independiente de la vista.
La vista nunca le habla al modelo y una de las razones es permitir usar vistas genéricas y componentes reusables, también porque este permite manejar el flujo de información y controlarlo a través de nuestra aplicación.
Mensajes desde la vista
Suponiendo que tenemos una interfaz con un botón, un campo de texto y una tabla. de manera más formal cuando desarrollamos Apps para Apple, podemos crear instancias para ello de las clases llamadas UIButton, UITextView y UITableView.
¿Como se supone que el botón, el cuadro de texto y la tabla se van a comunicar con el controlador cuando el usuario presione el botón, teclee un texto en el campo de texto, o seleccione una fila en la tabla?
Bueno, solamente hacemos esto en nuestra clase controladora cuando creamos nuestro nuevo proyecto. Recuerden que Apple , aun sin conocer nuestras necesidades como programadores ya han creado estas clases años atrás.
La clase de UIButton, que controlara a nuestro botón, no tiene un importe incorporado para nuestra clase.
En el desarrollo de iOS la comunicación de la vista con el controlador es ciega y estructurada. Los objetos de la vista no saben todo acerca de los controladores. Los objetos de la vista solo saben acerca de ciertos roles que el controlador esta capacitado a llevar a cabo.
Vamos a explorar dos técnicas
TARGET ACTION: Supongamos que tenemos un controlador de la vista que implementa el método que deseamos llamar cuando un usuario toca un botón. El controlador de la vista monta un objetivo sobre si mismo y este reparte una acción para el botón.
Una acción es simplemente un método que el controlador de la vista implementa.
Cuando el usuario toca el botón, el botón enviar un mensaje especificado en la acción al controlador de la vista, esto permite al botón hablar a la vista sin saber mucho acerca del controlador de la vista.
Todos lo que botones saben es que el controlador de la vista implementa el método especificado para la acción.
Para resumir, el mecanismo de la acción objetivo (TARGET ACTION), nos permite conectar nuestros objetos de la vista a un método en un objeto controlador particular. Este método es disparado o activado cuando el usuario interactúa con el objeto de la vista de una forma designada sin que el objeto de la vista sepa nada mas acerca del objeto controlador
DELEGATES: A veces la vista necesita contactar el controlador de la vista y decirle que algo ha ocurrido o algo ocurrirá, o preguntar si debería dejar que algo ocurra.
El controlador puede libremente comunicarse con la vista, entonces el controlador enviar al objeto de la vista un mensaje para configurar al objeto controlador como el objeto de la vista lo ha delegado.
Ser el delegado significa que el controlador esta de acuerdo con llevar a cabo un rol especifico, de manera mas formal, quiere decir que el controlador ha aprobado conformar un protocolo particular.
Un protocolo es una colección de métodos. Algunos de ellos serán requeridos, mientras que otros pueden ser opcionales. Al estar de acuerdo con conformar el protocolo, el controlador ha entregado a implementar todo de los métodos requeridos y este es libre de implementar cualquier otro método opcional.
Ahora cuando la vista llega a una situación donde necesita pedir a su delegado si pudiera hacer algo, este enviaría el mensaje apropiado desde el protocolo hasta el controlador.
Como en el patron de las acciones objetivos, esta relación es ciega y estructurada.
Todos los objetos de la vista saben acerca de los objetos controladores es que estos son los objetos que implementan los métodos. El objeto de la vista sabe que puede enviar de forma segura al controlador cualquiera de los mensajes requeridos in el protocolo. El objeto de la vista también puede enviar cualesquiera de los mensajes opcionales declarados en el protocolo después de primero preguntar al objeto controlador si puede implementar este método opcional.
Un campo de texto usa un delegado (delegate) Entonces el controlador de la vista puede determinar que pasa cuando por ejemplo, el usuario toca sobre un botón de regresar o limpia un campo de texto. Una tabla usa dos diferentes delegados: uno para responder a la interacción del usuario con la vista de la tabla y otro para llenar la vista de la tabla con los datos.
La vista en tabla no es dueña de los datos que muestra, mas bien le pregunta al controlador ”¿Que muestro aquí?”, entonces el controlador juega su rol en el origen de los datos y usualmente llama al modelo para ayuda. El controlador se sitúa entre el modelo y la vista para ayudar al modelo a poner sus datos en la pantalla.
Veamos como la comunicación del modelo cambia al controlador.
Transmisión desde el modelo
¿Que tal si hay cambios en el modelo que el controlador de la vista necesita representar en la pantalla?
Por ejemplo, vamos a suponer que estas mostrando artículos de noticias que recibes de una red alimentadora. Tu controlador necesita saber cuando el modelo tiene nuevos datos para actualizar la pantalla con las ultimas noticias.
El modelo no puede enviar mensajes directamente al controlador. El modelo tal vez sea repartido en tu aplicación por muchos diferentes controles y seria frágil y difícil de mantener si el modelo tuviera que saber acerca de cada controlador que depende de él.
En lugar de eso, todo controlador que esta interesado en saber cuando un aspecto del modelo ha cambiado necesita registrar que esta interesado en esa información, entonces el modelo diría algo como “hey!, estas cosas en las que estas interesado han cambiado”, así el modelo no sabrá nada acerca de los controladores.
Como en la comunicación de la vista con el controlador, esta comunicación es ciega y estructurada
Ahora intentare desarrollar una explicación sobre las dos formas en las cuales el modelo puede comunicarse con el controlador y es a través de notificaciones y valores claves de observación.
Notificaciones:
Recuerda que el modelo no sabe nada acerca del controlador, entonces no es capaz de enviar mensajes directamente al controlador diciendo “Hey!, he cambiado”.
Una solución es usar notificaciones. Cualquier controlador interesado en escuchar acerca de los cambios del modelo registra este interés con la aplicación del centro de notificaciones. Hay un solo centro de notificaciones para cada aplicación.
Entonces, cuando hay cambios en el modelo, el modelo postea una notificación en el centro de notificaciones.
El centro de notificaciones es el responsable de pasar estas noticias a todos los objetos que han registrado su interés por esta información en la notificación.
El centro de notificación acoge la información acerca de la notificación, entonces le dice a las partes interesadas el nombre de la notificación y el objeto que emitió la notificación. También pasa a lo largo de los diccionarios que pueden ser llenos con la información acerca de la notificación.
La belleza de este convenio es que los objetos que no saben nada acerca del otro pueden pasarse información posteando y registrando para recibir notificaciones.
Valores claves de observación:
Puedes implementar este mecanismo de transmisión sin usar un centro de notificaciones si el controlador puede comunicarse con el modelo. Valores claves de observación (KVO por sus siglas en ingles “Key Value Observing”) es esencialmente una notificación privada.
El objeto controlador enviar al modelo un mensaje diciendo “Estoy interesado en saber cuando esta propiedad cambie”. Dado que el KVO existió antes de las propiedades, así que seria mas tradicional decir “Estoy interesado en saber cuando el valor asociado con ciertas claves cambie”. En la practica, observare mas a menudo los valores asociados con las propiedades.
El modelo entonces necesita actualizar las propiedades de una manera observable. Para las instancias, si se usa un setter para configurar el valor de la propiedad que se esta observando, entonces la notificación privada sera enviada.
El objeto controlador recibe un mensaje que dice “Una de las propiedades en las que estas interesado ha cambiado su valor” y junto con este mensaje, el controlador recibe información que incluye cual objeto ha enviado el mensaje y cual propiedad ha cambiado.
Con el KVO el objeto del modelo es capaz de comunicar este cambio al objeto controlador sin saber nada acerca del controlador a excepción de lo que este esta interesado en escuchar acerca de este cambio en particular.
Controladores Multiples
En tanto vayas añadiendo funcionalidad a tu aplicación, serás incapaz de agrupar tus objetos en un solo campo de modelos, en un solo campo de vistas o en un solo campo de controladores.
Cada escena sera manejada por un controlador diferente. un controlador de la vista puede necesitar la ayuda de otros controladores para mostrar la data correcta en la pantalla. estos controladores necesitan comunicarse entre ellos.
Como en la comunicación entre los controladores y los objetos del modelo o de los controladores con los objetos de la vista, queremos asegurarnos que nuestros controladores no están excesivamente acoplados. La comunicación entre los controladores debe tener lugar en una sola dirección.
Usualmente si tienes una escena en la pantalla y esta esta cerca de dar paso a otra escena, el controlador a cargo de manejar la vista actual sabe (en términos de código, importar el archivo de cabecera de) el controlador de la vista de la escena que sera mostrada
Para comunicarse en otra dirección, deberías crear tu propio protocolo personalizado y así el primer controlador de la vista puede actuar como un delegado del segundo.
Nota en el diagrama que uno de los controladores no envía mensajes directamente al controlador de la otra vista. Los objetos de la vista son solo servidores de un particular controlador de vista.
Un controlador de vista puede calladamente pasar información y posiblemente control a otro controlador de vista y dejar comunicarle al esta nueva información a sus propios servidores.
Mas de un objeto controlador puede hablar al mismo objeto modelo u objetos. De hecho, quizás haya un simple grupo de núcleos de objetos modelos que todos lo de los controles pueden direccionar.
En general debes seguir las directrices y comunicarte tan fácil como te sea posible
Algunas de estas ideas no estarán del todo cara hasta que empecemos a trabajar con MVC y las posibles aplicaciones que se desarrollaran, por ahora es importante afianzar estos conceptos e investigar tanto como sea posible acerca del trabajo con esta estructura y los beneficios que te ofrece.
No hay comentarios:
Publicar un comentario