Collaborative structures inter-organisational networks

La arquitectura de una aplicación móvil se basa en el patrón Modelo – Vista – Controlador (MVC) aunque de una forma bastante vaga, pues según la aplicación a desarrollar puede existir o no un modelo, y éste no ha de estar fuertemente ligado a una vista y un controlador.

Para el desarrollo de DealtDay se ha intentado seguir éste patrón en la mayor medida de lo posible obteniendo como resultado estos componentes:

• Modelo: Los modelos son clases que representarán los datos a tratar. Para la aplicación se han creado los modelos correspondientes con el modelado de datos diseñado en el servidor (Figura 17). Los modelos es común tanto a Android como a iOS.

• Vistas: Las vistas componen la interfaz gráfica de la aplicación. Dichas vistas estarán formadas por unos archivos XML donde estarán definidos todos los componentes gráficos que incluirán. En el caso de Android se manipularán directamente estos archivos, mientras que en iOS podemos crear estos archivos de forma indirecta y gráfica mediante el uso de storyboards.

• Controladores: Los controladores se encargan de renderizar los datos de los modelos en las vistas, así como gestionar los eventos del sistema y la interacción del usuario. En Android contaremos con las diferentes Activities y Fragments mientras que en iOS usaremos los Controllers.

43

Figura 16: Modelo de datos en servidor.

A continuación se expondrá brevemente la arquitectura de la aplicación en cada una de las plataformas.

Android

La definición de vistas en Android se puede representar mediante el diagrama de flujo de la Figura 18. Como se puede observar, las vistas están formadas por Activities que pueden contener Fragments, dividiendo de esta forma el comportamiento deseado en diversos módulos.

Figura 17: Diagrama de la aplicación

• LoginActivity: Es el punto de entrada de la aplicación para el usuario. El usuario podrá registrarse en el sistema, recuperar su contraseña o acceder al sistema mediante el uso de sus credenciales.

45 nts anidados cada uno con una función específica independiente del sto.

os del servidor, y una vez recibidos los inyecta en los fragments ijo.

entos n los que participa el usuario y que todavía están activos.

Figura 18: Login Activity

• MainActivity: Esta es la vista principal de la aplicación. A ella se accede una vez el usuario accede logeado al sistema y desde ella se puede acceder al contenido general de los eventos, los contactos y el perfil a través del menú lateral. Como puede observarse en el diagrama, esta activity está compuesta de fragme

re

o Events Fragment: Fragment donde se localiza toda la funcionalidad relacionada con los eventos y por tanto requiere el uso del modelo de los mismos. Este fragment contiene a su vez dos fragments distintos gestionados mediante un sistema de pestañas que permite al usuario visualizarlos sin necesidad de cambiar de ventana. Además cabe mencionar que esta vista es la encargada de obtener los datos de los event

h

ƒ Current Events Fragment: Contiene el listado de los ev e

ƒ Past Events Fragment: Contiene el listado de los eventos en los que participa el usuario y que ya han finalizado.

Figuras 19 y 20: EventsFragment

o Friends Fragment: Fragment que contiene los datos de los contactos con los que está relacionado el usuario en el sistema. Presenta un comrotamiento similar al fragment de los eventos, gestionando a sus fragments internos mediante pestañas y obteniendo los datos del servidor para pasárselos a sus vistas hijas una vez se han creado.

ƒ FriendsTab1 Fragment: Muestra y gestiona los datos de los contactos confirmados del usuario.

ƒ FriendsTab2 Fragment: Muestra y gestiona los datos de las solicitudes de amistad recibidas.

ƒ FriendsTab3 Fragment: Muestra y gestiona los datos de las solicitudes de amistad enviadas.

47

o Profile Fragment: Vista que muestra y permite al usuario gestionar su contraseña y su nick.

Figuras 21y 22: Friends Fragment

• Event Detail Activity: En esta vista se puede acceder al detalle de cada uno de los eventos. Utilizando un modelo de eventos que presenta todos los detalles, permite que el usuario sea capaz de votar las posibles respuestas y ver la lista de usuarios que participan en ellos. Esta activity tiene además un comportamiento muy parecido a los fragments contenedores previamente descritos. Está compuesta por dos fragments:

o Detail Event1 Fragment: Se encarga del renderizado y gestión de las respuestas y votaciones de los usuarios.

o Detail Event2 Fragment: Se encarga de mostrar a los usuarios que participan en el evento.

Figura 24: EventDetail Activity

• FinishedEvent Activity: Incluye toda la información referente a un evento que ha finalizado, es decir, al número de votos que ha recibido cada respuesta y la lista de votantes si procede.

• CreateEventActivity: Es la activity encargada de la gestión de la creación de eventos. Contiene dos fragments aunque a diferencia de lo visto hasta este punto, el usuario no puede navegar entre ellos libremente, sino que está condicionado a unos requisitos para poder pasar de uno a otro. Estos requisitos vienen determinados por las imposiciones necesarias para poder crear un evento que el usuario debe satisfacer insertando los datos correctos.

Para lograr el funcionamiento correcto de la funcionalidad, esta activity sirve como medio común de los fragments para almacenar la información recogida en cada uno de ellos y es en realidad la encargada de interactuar con el servidor.

o CreateEventFragment1: Controla que el usuario introduce los datos básicos del evento, siendo estos el título, la fecha de creación y el número de votos permitidos.

o CreateEventFragment1: Controla que el usuario añade al menos tantas respuestas como el número de votos que ha establecido. Como puede verse, es necesario compartir esa información obtenida en el fragment anterior, de modo que se produce una comunicación con la activity en el que está contenido éste modulo, almacenando y obteniendo de ella los datos ya que es el único punto de conexión existente entre ambos fragments.

49

iOS

Para detallar la arquitectura empleada en iOS se incluye el storyboard resultante de la aplicación donde se puede ver claramente el flujo de la aplicación.

Figura 26: Storyboard de la aplicación

Las vistas y los controlados utilizados son los siguientes:

• Navigation Controller: Estos controladores propios de la SDK permiten el uso de la barra de navegación en la aplicación y gestiona la navegación entre las vistas apiladas en la memoria, de modo que el usuario pueda retroceder.

• RevealViewController: Es el controlador que nos permite crear el menú lateral de la aplicación. Tiene la peculiaridad de que ha de ser el elemento raíz de nuestra aplicación y necesita contar al menos con dos controladores más asociados, uno para el menú y otro para la vista que se vaya a mostrar. Para que

el usuario acceda a la pantalla de login al iniciar la aplicación, se ha establecido el PerfilController como la vista principal del este controlador.

o MenuController: Define el menú lateral de la aplicación y su funcionalidad.

Figura 27: Menú lateral en iOS

• ViewController: Controlador que gestiona tanto el registro como la recuperación de contraseñas y acceso de los usuarios a la aplicación. Dado que es la primera pantalla a la que accederá el usuario, no se ha incluido en ella una controlador para habilitar la navegación.

51

• EventTabBarController: Este controlador será el encargado de gestionar la vista principal de los eventos. Hereda de un TabBarController para poder crear una vista con pestañas y ver los dos tipos distintos de eventos por separado sin necesidad de cambiar de pantalla. Además, este será el controlador que obtenga los eventos del servidor y se encargará de pasárselos a los dos controladores que contendrá en las pestañas.

o CurrentEventItemController: Encargado de mostrar todos los eventos activos en los que participa el usuario.

o PastEventItemController: Encargado de mostrar todos los eventos finalizados en los que participa el usuario.

Figuras 29 y 30: EventTabBarController

• PageController: Es un controlador que hereda de UIPageViewController, permitiendo así la visualización de varias vistas en una misma ventana con la particularidad de que para navegar entre ellas se usa el gesto de deslizar el dedo

en pantalla. Este controlador se usa para mostrar los detalles de un evento, y contiene a los siguientes controladores:

o EventDetailAnswerController: Se encarga del renderizado y gestión de las respuestas y votaciones de los usuarios.

o EventDeatilInviteController: Se encarga de mostrara la lista con los participantes del evento.

Además desde estos controladores se puede acceder a los siguientes:

ƒ VotersViewController: Muestra las personas que han votado determinada respuesta.

ƒ InviteController: Permite invitar a los usuarios a un determinado evento.

Figura 31: PageController

• FriendsTabBarController: Al igual que el EventTabController, éste es un controlador que hereda de un TabBarController para poder mostrar la

información de los contactos en pestañas y también se encarga de obtener los datos del servidor para establecérselo a los controladores que contiene.

o FriendsItemController: Muestra y gestiona los datos de los contactos confirmados del usuario.

o ReceivedRequestViewController: Muestra y gestiona los datos de las solicitudes de amistad recibidas.

o SentRequestItemController: Muestra y gestiona los datos de as solicitudes de amistad enviadas por el usuario.

Figuras 32 y 33: FriendsTabBarController

• PerfilController: Vista que muestra y permite al usuario gestionar sus datos de perfil.

Figure 34: PerfilController

• NewEventViewController: Es el controlador encargado de la gestión de la creación de nuevos eventos. A diferencia de la versión de Android, donde esta funcionalidad está divida en dos módulos, éste controlador se encarga de la totalidad de la funcionalidad ocultando y mostrando los elementos necesarios.

55

• NewAnswerController: Es el controlador que gestiona la creación y adición de una nueva respuesta en un evento.

56