Clase 2 de Interfaces de Usuarios: Eventos, binding, componentes, modelo. MVC. Arena

1er Bloque:

Si bien el titulo es muy prometedor, arrancamos presentando a Javi a la materia y repasando algunos temas:

Excepciones

Hablamos sobre:

• Cuando queremos usar una excepción.
• Caracteristicas de la excepción:
• Burbujea
• Es una clase (vale todo lo que vimos)
• Puede tener informacion
• Jerarquía
• Diferencia con call & return
• Particularmente en Java:
• 2 grandes gustos:
• Excepciones chequeadas
• Obligan a tratar la excepcion
• Son las que extienden de Exception (ej, IOException)
  
• Excepciones no chequeadas
• Las atrapa el que consume si quiere... sino sube
• Son las que extienden de RuntimeException (ej. NullPointerException)
  
• Tratamiento de Excepciones:
• Ignorarlas <-- ojo... que en el 99.99999% de los casos esto no se debe hacer, ya que no es tratar la excepción sino que sería esconderla, una mala práctica. Lo nombramos acá a modo de explícitamente notar que no está bien hacer esto.
  
• Hacer algo que corrija el problema (por lo general no nos pasa)
• Relanzar la misma excepcion  <-- ojo... que no es el mejor tratamiento, de hecho es un code smell
• Hacer algo y despues relanzarla
• Wrapearla

Ejemplo

Vimos un ejemplo con excepciones No Chequeadas
Hicimos tests y resumiendo hablamos de:

• La importancia de poner un buen nombre a los tests
• Que significa que sean unitarios
• El hecho de que siempre tiene que haber al menos un assert
• Hablamos rapidamente sobre junit 4 y como es casi lo mismo que el 3
• Debuggear
• Como los tests no corrian todos, vimos como debuggear. Las partes de la vista de debugger en el eclipse, un par de cosas que podemos hacer, que es un breakpoint ...

2do bloque

Hicimos practica les dejamos un rato para que modelen el dominio y lo codifiquen empezando por el caso de uso de reparar el dominio.

3er Bloque

Empezamos con la Unidad 2

Model-View-Controller

La importancia de un modelo de dominio
Dijimos 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 ventana

Definimos 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:

• Contestar preguntas.
• Tirar excepciones.
• Lanzar eventos.

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.

Eventos

El 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.

Binding

Ahora, ¿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 maven
    2.  Agregamos como parentPom el que nos sugiere el arena:
       
    3.  Agregamos la dependencia del arena
         
    4.  Creamos nuestra clase Conversor con dos atributos: millas y kilometros y un metodo convertir sin parametros con el codigo:

    5.  Creamos la UI

• Como esto es bien simple nos alcanza con una unica ventana, entonces creamos una ventana que extienda de MainWindow, como modelo le dijimos que iba a tener un Conversor.
• Redefinimos el createContents de forma tal que:
• tenga un textBox para que permita ingresar la cantidad de kilómetros a convertir a millas y a su vez el contenido de ese textbox este bindeado a la propiedad kilometros del  conversor
• tenga un boton que diga Convertir y como acción envie el mensaje convertir al conversor.
• tenga un label que nos informe del resultado de la conversion
  

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