Model View View-Model en iOS

La estructura de las aplicaciones iOS está basada en el patrón de diseño MVC

sistema operativo y también del lenguaje utilizado (Swift) propone. Sin embargo, según

las características de la aplicación, existen distintas adaptaciones y alternativas que los

programadores aplican al momento de desarrollar. Es natural pensar que, por ejemplo,

un juego ​“standalone” no tendrá la misma estructura que una aplicación con fuerte

apoyo en backend y servicios Web, o una aplicación con numerosos accesos a base de

datos.

En el año 2004, un grupo de desarrollo de Microsoft trabajaba en un proyecto

denominado “Avalon”, más conocido por su nombre definitivo WPF (del inglés Windows

Presentation Foundation). El propósito de dicho proyecto era permitir el desarrollo de

aplicaciones de escritorio más completas y con un aspecto gráfico más vistoso y

complejo de lo que era posible con Windows Forms. John Gossman en 2005, en un

artículo de la MSDN (Microsoft Developer Network), mostraba al público el patrón

MVVM, Model View View-Model. En dicho artículo, MVVM se presenta como una variación del patrón MVC ajustado a WPF y a su sistema de enlace a datos. _​Este patrón

tiene por objetivo simplificar las tareas de desarrollo y mantenimiento del software, a

través de la división de ocupaciones. Resultando así, natural para cualquier desarrollador que haya trabajado previamente con alguno de los patrones que lo originan.

Los componentes principales del patrón de diseño son la Vista, el Modelo de

Vista y el Modelo. Los mismos se detallan en las siguientes secciones.

4.3.1.1.1 La Vista

La misión de la vista es representar la información a través de los elementos visuales que la componen. Las vistas en MVVM son activas, contienen comportamientos, eventos y enlaces a datos que, en cierta manera, necesitan tener conocimiento del modelo subyacente. En Xcode, los elementos visuales generalmente se ubican en archivos Storyboard y Xib, donde visualmente se ubican los elementos en la pantalla. Allí se definen los tamaños y reglas de adaptación para los distintos tamaños de todos los dispositivos que la aplicación soportará.

Cada pantalla está asociada a una clase propia del SDK básico de iOS denominada ViewController. Aquí se hace presente la intención de Apple de utilizar el patrón MVC

como standard para todas las aplicaciones. De esta forma MVVM comienza a diferenciarse y a marcar una ruptura sobre los guías de desarrollo de iOS.

Al desarrollar aplicaciones solamente utilizando MVC, resulta muy común que el ViewController contenga demasiadas líneas de código dado que las pantallas se vuelven

complejas y requieren mucha lógica de negocio detrás. Además de surgir problemas de

legibilidad y soporte, resulta muy complejo para testear y reutilizar pantallas para soportar funciones similares. Esta situación ha llevado a desarrolladores de iOS a decir que MVC se convierte en Massive-ViewController.

Para solucionar los problemas antes mencionados, MVVM declara que la clase

ViewController sólo debe contener lo necesario para actualizar la interfaz gráfica ante un cambio de lógica o ante una acción del usuario sobre la misma. También la integran las capturas de eventos, como por ejemplo, el arrastre de un elemento, la presión prolongada sobre un objeto, etc. De esta forma, contendrá únicamente lo necesario para soportar la pantalla que representa, excluyendo la lógica de negocio.

Para soportar ese encapsulamiento, generalmente se utilizan, a su vez, otros

patrones, como Delegación (Sección 4.3.1.4). En dicho escenario, el ViewController delega la obtención de datos para popular la interfaz de usuario, simplemente los solicita e inserta la información en la pantalla una vez disponible. Esto permite reutilizar un conjunto ViewController-Storyboard que, por ejemplo, conforme un listado; podría

utilizarse para listar materias o finales, simplemente cambiando la delegación de

información.

Otro punto a mencionar acerca de los Storyboards es que en estos archivos se ubican todas las reglas para el adaptado a distintas pantallas y plataformas. La variedad

de tamaños de smartphones dentro del mercado obliga a forzar el ajuste y a la

definición de un conjunto de reglas de adaptación del diseño para que una pantalla se vea correctamente en un teléfono de proporciones distintas. Lo mismo ocurre cuando se debe adaptar a una tablet o cuando el usuario rota el dispositivo (si la aplicación lo permite).

Figura 4.4 - Storyboard del menú lateral de _​Unimanager_​. 4.3.1.1.2 El Modelo de Vista

Es en este punto donde se ubica la lógica de negocio de una aplicación iOS. _​El

modelo de vista es un actor intermediario entre el modelo y la vista, contiene toda la

lógica de presentación y se comporta como una abstracción de la interfaz. La

comunicación entre la vista y el ViewModel se realiza de distintas maneras.

En iOS generalmente se ubica una variable en cada ViewController, que representa al ViewModel. Este último es el encargado de disponer cuando se debe ​, por ejemplo, realizar un request a una API o mostrar la información cacheada previamente. También es el encargado de determinar qué transición de pantallas ocurre. No siempre la pantalla A conecta con la B cuando se presiona determinado botón, puede que en un caso en particular, cuando hay cierta información guardada en la base de datos, la pantalla A presenta directamente la pantalla C. Este tipo de lógica debe ubicarse fuera del ViewController con el objetivo de posteriormente realizar tests de unidad y verificar el comportamiento de la aplicación cuando ciertos escenarios se presentan.

Por ende, cada ViewController, es decir, cada pantalla, contiene al menos una

referencia a un ViewModel el cual le provee los datos necesarios para popular la

indican que se muestra al usuario y cuando se hace. Esto facilita de manera considerable el encapsulamiento, la modificabilidad y la escalabilidad de la aplicación

En _​Unimanager​, los ViewModel se declararon en clases denominadas managers

que actúan como Singletons a través de la aplicación. NavigationManager controla la presentación de pantallas y las transiciones entre las mismas; DataManager administra la información necesaria para popular a las pantallas, decidiendo si proviene de API o caché; SessionManager contiene la información sobre el usuario logueado y administra su sesión.

4.3.1.1.3 El Modelo

En MVVM, el modelo se refiere a un modelo de dominio, que representa tanto

comportamiento como datos, es decir, una representación formal de conceptos, roles,

tipos de datos, individuos y reglas. Este es un enfoque propio de la programación

orientada a objetos _​(​Data Modelling, 2002​)​.

Alternativamente, el modelo puede representar simplemente una capa de acceso

a datos, es decir, representa contenido.

En las aplicaciones móviles iOS que aplican MVC o MVVM, el modelo usualmente

representa los llamados a las API Rest, parsing de respuestas, operaciones a las base de

datos SQLite, tipo de datos y manejo de los mismos.

En MVC puede poseer lógica para administrar los datos y accesos a los mismos,

encapsulando las acciones a ejecutar una vez que se obtiene la información o ante un

eventual fallo. En iOS el modelo es mucho más simple. Simplemente obtiene la información y se las entrega a los ViewModel, no tiene otras tareas asociadas.

Puntualmente en​Unimanager​, el modelo está conformado por un único Singleton

que administra las llamadas a la API. La aplicación móvil no cuenta con acceso de

edición a la base de datos dado que actualmente el prototipo es de sólo lectura.

NetworkManager, dicho Singleton, obtiene las respuestas de la API, recibe los datos de

tipo JSON y los mapea a objetos definidos, retornándolos en caso de éxito. En caso de

que se registre algún tipo de problema de comunicación, provee un código de error para

justificar el fallo. Por ejemplo, mala conección a la red o finalización de la sesión de

Figura 4.5 - Funciones de NetworkManager, una clase del Modelo utilizada en ​Unimanager ​para accesos a API.