Bitacoras-2012S2
Clase 2 - MVC
Clase 2 de Interfaces de Usuarios: Eventos, binding, componentes, modelo. MVC. Arena1er Bloque:Si bien el titulo es muy prometedor, arrancamos presentando a Javi a la materia y repasando algunos temas:ExcepcionesHablamos sobre:
EjemploVimos un ejemplo con excepciones No ChequeadasHicimos tests y resumiendo hablamos de:
2do bloqueHicimos practica les dejamos un rato para que modelen el dominio y lo codifiquen empezando por el caso de uso de reparar el dominio.3er BloqueEmpezamos con la Unidad 2Model-View-ControllerLa importancia de un modelo de dominioDijimos que era muy importante tener un modelo de dominio separado de la tecnologia o lo que querramos hacer. Discutimos el por que de esta separacion y pensamos que pasaria si no la tuvieramos y mezclaramos por ejemplo logica de dominio con la presentacion, esto nos llevaria a alejarnos de nuestro problema y en vez de concentrarnos en el problema (haciendo las abstracciones que se encuentran en el) pensar en problemas inherentes de la tecnologia produciendo sistemas confusos y poco escalables, tendiendo a repetir codigo y a distribuir mal las responsabilidades. Ademas recalcamos el hecho de que hace mas dificil escribir tests unitarios. Objetos necesarios para modelar una ventanaDefinimos que vamos a construir interfaces de usuario orientadas a objetos. Para eso, introducimos nuestro ejemplo del conversor de kilometros a millas y presentamos una pantalla tentativa.Nos preguntamos qué objetos podrían conformar esa pantalla: Los obvios son los controles visuales: botones, campos de texto, ventanas. Menos obvios son los layouts, que indican cómo se organizan espacialmente los objetos. Y también tenemos que pensar en el objeto que tiene el comportamiento, por debajo de la ventana, al que vamos a llamar modelo de dominio. Relación entre la interfaz de usuario y el dominio Definimos como un objetivo la separación entre los controles visuales y el modelo de dominio. Es importante entender qué formas de relación podemos admitir entre ambos y qué formas no. Existe una relación entre ambos, no podemos pretender que no tengan "ninguna relación entre sí", eso seria engañarnos. Según nuestra definición, el dominio no puede tener referencias explícitas a la interfaz de usuario, pero sí puede:
La interfaz de usuario sí puede tener referencias al dominio y mandarle mensajes, pero no debe tomar decisiones propias del dominio. Como regla general, vamos a pensar que (casi siempre) cada ventana va a tener un único objeto que es responsable del comportamiento asociado a esa ventana. A ese objeto lo llamamos el modelo de la ventana. Múltiples ventanas pueden estar relacionados con un único modelo. EventosEl otro concepto fundamental de la forma de comunicación que vamos a utilizar es el Evento. Un evento produce una forma de interacción muy desacoplada, ya que el que informa sobre el evento conoce sólo sobre sí mismo, no sabe a quién le está informando.Los eventos permiten enterarnos de las acciones del usuario, por ejemplo podemos hacer que la UI nos avise cuando el usuario presiona un botón, y pedirle que invoque un mensaje específico. Los eventos y las configuraciones asociadas son el primer ejemplo que vemos del tercer rol fundamental en el diseño de una interfaz de usuario: el controller. Al decir esto podemos terminar nuestro dibujo de MVC. De a poco vamos a ver controllers más complejos, por ahora van a ser muy simples. BindingAhora, ¿cómo hacemos para obtener la información que el usuario ingresó en la ventana?Nuestras reglas dicen que no podemos pedírsela a la ventana, pero lo que sí podemos es escuchar algún evento que nos avise cuando cambia el valor y nos reenvíe el valor nuevo. Como este tipo de comportamiento es muy común, existe una forma especial de evento que llamamos binding. El binding puede ser unidireccional o bidireccional. Y con eso tenemos todo para construir interfaces de usuario sencillas. Todo esto lo hicimos acompañados de un ejemplo. Pasos para reproducir el ejemplo:1. Creamos un proyecto maven2. Agregamos como parentPom el que nos sugiere el arena: <parent> <groupId>uqbar</groupId> <artifactId>arena-parent</artifactId> <version>1.1</version> </parent> 3. Agregamos la dependencia del arena <dependency> <groupId>uqbar</groupId> <artifactId>arena</artifactId> <version>${arena-version}</version> </dependency> 4. Creamos nuestra clase Conversor con dos atributos: millas y kilometros y un metodo convertir sin parametros con el codigo: this.setKilometros(this.getMillas() * 1.60934); 5. Creamos la UI
Este ejemplo ya lo tienen codificado en el repo de ejemplos de la materia y esta checkouteado en sus workspaces. Tambien vimos el ejemplo de celulares y como se crearia una tabla. IMPORTANTE! Para la proxima semana tenemos la primer entrega del tp que tiene que cumplir con lo pedido para la entrega 0. Asi que a ponerse las pilas y a hacer que sea posible reparar robots! Pueden leer con mas detalles bitacoras anteriores |
Clase 1 - Intro
Por si alguin no estaba enterado, el martes 21/08 empezaron las clases de la materia, aca dejamos un mini resumen de que es lo que hicimos:
Quedo pendiente repasar:
|
1-2 of 2