TECNOLÓGICO NACIONAL DE

MÉXICO
Tecnológico Superior de Felipe Carrillo Puerto

Ingeniería en Sistemas Computacionales

Asignatura:

Desarrollo de aplicaciones para dispositivos móviles

REPORTE DE INVESTIGACIÓN

Profesora:

Guadalupe Noemí Castillo Sosa

Alumnos:

Brandon Isaac Ku Rivas

Magaly Jazmín Can Pech

Alex Armando Díaz Cab

Felipe Carrillo Puerto, Q. Roo, a 26 de octubre del 2019

ÍNDICE

INTRODUCCIÓN..................................................................................................................3

MODELO VISTA CONTROLADOR....................................................................................4

Modelo................................................................................................................................4

Controlador.........................................................................................................................5

Vistas...................................................................................................................................5

MODELO VISTA PRESENTADOR.....................................................................................5

Modelo:...............................................................................................................................6

Vista:...................................................................................................................................6

Presentador:.........................................................................................................................6

MVP en Android.................................................................................................................6

MATERIAL DESIGN............................................................................................................7

CONCLUSIONES..................................................................................................................9

FUENTES DE INFORMACIÓN..........................................................................................10
 INTRODUCCIÓN.

El presente documento contendrá los aspectos y características principales que

conforman a un MVC Y un MVP. El primer acrónimo es referente a un patrón de
diseño orientado a objetos que fue desarrollado en el centro de investigaciones de
XEROX Palo Alto a finales de los setentas, estando constituido por tres iniciales la
M que referencia a Modelo que representa a la lógica de negocios y manipulación
de los datos, el segundo acrónimo la V haciendo referencia a la Vista presencial
de los datos diseñados en una página y por último la C representando al
Controlador que es el código de navegación de la aplicación que controla el flujo
de esta, el segundo acrónimo que se abordara se podría decir que es una mejora
del Modelo Vista Controlador ya que solo el último aspecto se actualizo y en este
documento se mencionara por qué la actualización y las características de este
letra que forma parte del nuevo acrónimo MVP, siendo Modelo Vista Presentado
ahora, el presentado asimila ahora las funcionalidades del modelo hombre
haciendo uso de la lógica de presentar, este es más enfocado a las aspectos de
diseño ya que maneja conceptos en el entorno de Android abordando así el
Material Design el cual es una herramienta que ayuda a los diseñadores y
desarrolladores de aplicaciones creada por Google para ayudar a los diseñadores.
 MODELO VISTA CONTROLADOR

MVC fue descrito en el año de 1979 por trygve Reens Kaug e introducido como parte de la
versión Smalltalk-80 del lenguaje de programación Smalltalk, este modelo de arquitectura
fue diseñado para reducir esfuerzos de programación necesario en la implementación de
sistemas múltiples y sincronizados de los mismos datos.

Este modelo utiliza 3 componentes Vista, Modelos y Controladores, separando la lógica de

la aplicación de la lógica de la vista en una aplicación cabe mencionar que hace uso de
componentes gráficos básicos hasta de sistemas gráficos empresariales

Imagen 1Estructura

Una de las razones de las razones para usar MVC es que nos permite separar los
componentes de nuestra aplicación dependiendo de la responsabilidad que tienen, esto
significa que cuando hacemos un cambio en alguna parte de nuestro código, esto no afecte
otra parte de este. Por ejemplo, si modificamos nuestra Base de Datos, sólo deberíamos
modificar el modelo que se encarga de los datos y el resto de la aplicación debería
permanecer intacta. Esto respeta el principio de la responsabilidad única. Es decir, una parte
de tu código no debe de saber qué es lo que hace toda la aplicación, sólo debe de tener una
responsabilidad
Modelo
Se encarga de los datos, generalmente (pero no obligatoriamente) consultando la base de
datos. Actualizaciones, consultas, búsquedas, etc. todo eso va aquí, en el modelo.

Controlador
Se encarga de controlar, recibe las órdenes del usuario y se encarga de solicitar los datos al
modelo y de comunicárselos a la vista.

Vistas
Son la representación visual de los datos, todo lo que tenga que ver con la interfaz gráfica
va aquí. Ni el modelo ni el controlador se preocupan de cómo se verán los datos, esa
responsabilidad es únicamente de la vista.

MODELO VISTA PRESENTADOR

Es una derivación del patrón arquitectónico MVC, es utilizado mayormente para construir
interfaz de usuario, el MVP (Presentador) toma la funcionalidad del intermediario.

Surge para ayudar a realizar pruebas automáticas de la interfaz gráfica, para ello la idea es
codificar la interfaz de usuario lo mas simple posible, teniendo el menor código posible,
toda la lógica de la interfaz de usuario se hace en una clase separada (que se conoce como
Presentador), que no dependa en lo absoluto de los componentes de la interfaz gráfica y
que, por tanto, es más fácil de realizar pruebas,

La idea básica es que la clase Presentador haga de intermediario entre la vista(la interfaz
grafica de usuario) y el modelo de datos. La vista tiene métodos en los que le pasan los
datos que debe mostrar, únicamente debe meter esos datos en los componentes gráficos
(cajas de texto, checkbox, etc). También métodos get para obtener el contenido de esos
componentes
El patrón MVP es una mejora del MVC vasado en tres características:

 La vista no conoce el modelo

 El presentador es independiente de la tecnología de la interfaz de usuario
 La vista y el presentador son texteables puesto que está basada en un controlador

Modelo: Esta capa gestiona los datos. Son las clases que denominaríamos de lógica de
negocio.

Vista:  Se encarga de mostrar los datos. Aquí se encontrarían nuestros Fragmentos y

Vistas.

Presentador: Se sitúa entre el modelo y la vista, permitiendo conectar la interfaz gráfica

con los datos.

MVP en Android
Android no nos ofrece de forma nativa la posibilidad de desarrollar nuestras aplicaciones
bajo el patrón MVP, de hecho, viola mucho de sus principios básicos. Aun así, podemos
llevar a cabo alguna aproximación para este fin. Vamos a ver un posible ejemplo de
implementación en el que el usuario dispone de un formulario dónde puede introducir
contactos.

 El usuario introduce un contacto y pulsa el botón "añadir contacto".

 El Presentador crea el objeto Contacto con los datos introducidos por el usuario y se
lo pasa al Modelo para que lo introduzca en la base de datos.
 El Modelo inserta el contacto en la base de datos.

Si todo ha ido bien, el Presentador  limpia el formulario y refresca la lista de contactos para

que aparezca el que acaba de añadir. En caso de que se haya producido algún error, muestra
una alerta con un mensaje de error.
La comunicación entre las capas se va a llevar a cabo mediante el uso de interfaces. Para
este ejemplo necesitaremos cuatro interfaces.

 ProvidedPresenterOps: Operaciones a las cuales tiene acceso la Vista y son

implementadas por el Presentador. Permiten que la Vista se comunique con el
Presentador.
 ProvidedModelOps: Operaciones a las cuales tiene acceso el Presentador y son
implementadas por el Modelo. Permiten que el Presentador se comunique con el
Modelo.
 RequiredViewOps: Operaciones a las cuales tiene acceso el Presentador y son
implementadas por la Vista. Permiten que el Presentador se comunique con la Vista.
 RequiredPresenterOps: Operaciones a las cuales tiene acceso el Modelo y son
implementadas por el Presentador. Permiten que el Modelo se comunique con el
Presentador.
Una vez tenemos definidas las capas de nuestro MVP, necesitamos instanciarlas e
insertar las referencias necesarias, además de un mecanismo responsable de
mantener el estado del Presentador y del Modelo durante el ciclo de vida de nuestro
Fragmento o Actividad.

MATERIAL DESIGN

Es una normativa de diseño enfocado en la visualización del sistema operativo Android, en

la web y en cualquier plataforma. Fue desarrollada por Google y anuniado en la conferencia
Google I/O, este material se agrego a androd lolipop como remplazo del Holo usando en
androd 4, el material digital puede ampliar y reformar de forma inteligente. El material
tiene superficies físicas y bordes. Las texturas y las sombras que tengan sentido de lo que se
puede tocar." Google afirma que su nuevo lenguaje de diseño se basa en papel y tinta.
Diseño material puede ser utilizado en la API de nivel 21 (Android 5.0) y la más reciente o
a través de la v7 appcompat biblioteca, que se utiliza en prácticamente todos los
dispositivos Android fabricados después de 2009. Material design se extenderá
progresivamente por toda la agrupación de web de Google y productos móviles,
proporcionando una experiencia consistente a través de todas las plataformas y
aplicaciones. Google también ha lanzado de programación de aplicaciones de interfaces
(APIs) para los desarrolladores de terceras partes para incorporar el lenguaje de diseño en
sus aplicaciones.

Cabe mencionar que recibe el nombre de material design por estar basado en objetos
materiales, piezas colocadas en un espacio(lugar) y con un tiempo(movimiento)
determinado, Precisamente este diseño basado en objetos es una manera de intentar
aproximarse a la realidad, algo que en un mundo donde todo es táctil y virtual es difícil.
Material Design quiere guiarse por las leyes de la física, donde las animaciones sean
lógicas, los objetos se superpongan, pero no puedan atravesarse el uno al otro.
 CONCLUSIONES.

Algunas de las terminologías abordadas en esta investigación nos son algo

familiares ya que en alguna de las asignaturas hemos escuchado o leído sobre el
modelo vista controlado y ahora sabemos que tiene como una evolución en sus
acrónimos y en los aspectos que evalúa ahora el MVP dejándonos en claro que el
patrón de la arquitectura del modelo vista controlador, trae consigo una bastante
cantidad de ventajas que motivan a su uso e implementación en un sistema,
resaltando una de sus características, la cual consiste en la separación de las
capas del negocio y la vista para hacer más sencillo el poder hacer modificaciones
y el dar mantenimiento igualmente dejándonos en claro que los que conforman un
equipo de desarrollo de software no están inmersos a darle una leída a el Material
Design para poder saber más o ampliar el repertorio de conceptos y
conocimientos que uno pose, siendo esta investigación teórica de gran ayuda para
nosotros ya que ampliamos nuestros conocimientos.
 FUENTES DE INFORMACIÓN

 González, Y. D., & Romero, Y. F. (2012). Patrón Modelo-Vista-Controlador. Revista

Telemática, 11(1), 47-57.
 Pantoja, E. B. (2004). El patrón de diseño Modelo-Vista-Controlador (MVC) y su
implementación en Java Swing. Acta Nova, 2(4), 493.
 http://codictados.com/mvp/
 https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93presentador
 http://www.develapps.com/es/noticias/modelo-vista-presentador-mvp-en-android
 Vivas, H. L., Muñoz Abbate, H., Petroff, M., Cambarieri, M., & García Martínez, N. (2015).
Material Design-Un lenguaje Visual para el desarrollo Ágil de Software.
 Pérez, E. X. (2008). Design, fabrication and characterization of porous silicon multilayer
optical devices. Universitat Rovira i Virgili.
 Cerna, E. V. (1996). Engineering design process.