Project memory (SPANISH)

Memoria del proyecto GymStatus App en Java

Fecha

Concepto Descripción

###Diciembre 2014: Modelo de clases e implementación de Hibernate. Creación del modelo de clases distribuido en 4 paquetes, el .controller, .model, .view y .test.

Vista y Testing. Se crea una vista simple, el MainView, un controlador que llama a un método de test que introducirá datos de test en todas las tablas para comprobar su correcto funcionamiento y la correcta implementación de Hibernate. El modelo está basado en una interface ExerciseDAO la cual implementarán tanto la capa DAO de Fitness como Cardio, estas a su vez extenderán la clase Observable la cual aprovecharemos para actualizar la vista. El resultado es correcto, sin problemas logramos un funcionamiento estable

###Enero 2015:

Creación del panel de Insercion de ejercicio de fitness. Creamos un panel que introducirá un ejercicio, de manera dinámica un Spinner actualizará entre 1 y 5 el número de series para el ejercicio. Observamos un fallo a la hora de ajustar el tamaño de dichos textfields para número de repeticiones, también encontramos un problema si decidimos reducir dicho numero de series

###Febrero 2015: Creación del panel de listar ejercicios. Reestructuración del modelo Observamos que seria más conveniente hacer que la interface ExerciseDAO sea una clase abstracta, extendiendo esta a Observable, de esta manera esta misma se encargaría por si sola de actualizar la vista sin necesidad de reescribir métodos en las clases hijas, además de más facilidad para crear métodos protected que utilizaran las mismas como inicio o cierre de sesión en Hibernate. Cambios polimorfismo. Detectamos pequeñas mejoras realizables aprovechando la interface List, aprovechando para pasar siempre por método dicha interfaz y haciendo el casteo pertinente en la clase que necesite una implementación diferente Creamos dos modelos de tabla diferentes para cada ejercicio, implementamos polimorfismo para implementar una u otra tabla dependiendo del tipo de ejercicio sin cambiar la variable.

Cambio modelo Exercise. Descubierto un fallo en el modelo de clases que impedía en la práctica realizar varios seguimientos a un mismo ejercicio. Se corrige mediante la implementación de un nivel mas de herencia para cada tipo de ejercicio, el primer nivel (CardioExercise, FitnessExercise) tan solo salvan nombre y musculo para el caso de Fitness, el resto son manejados por el estado del ejercicio en sí.

###Marzo 2015: Implementación patrón singleton. Implementamos un singleton en el package control.settings para establecer unos parámetros de configuración. En el futuro podría ser mucho más útil al realizar la aplicación multidioma

Creación paneles Rutinas. Creamos paneles de Rutinas con la idea de establecer fechas de inicio y fin, y una tabla donde se añadan uno a uno los ejercicios. También creamos una tabla para visualizar las rutinas con idea de ver tan solo el nombre de la misma y sus fechas de inicio y fin

Re estructuración de paneles de manejo de ejercicios y su estado. Se reconfiguran todos los paneles por errores de concepto al diseñarlos. Ahora por un lado se manejan los ejercicios en si, y por otro lado su estado. Dichos paneles cambian por completo según su función, usando diversos tipos de layout, desde nulo a GridBagLayout, BorderLayout, SpringLayout y FlowLayout son implementados dependiendo del uso. Descubrimos que el SpringLayout no resulta demasiado útil en nuestro caso aunque lo dejamos implementado. estas son las diferencias entre ellos

• GridBagLayout: Similar al GridLayout establece una tabla en la que se colocan por filas y columnas, usamos este en concreto mediante una clase llamada GridBagConstraints que establece una serie de "reglas" para establecer cada control dentro del mismo.
• BorderLayout: Establece los componentes en el centro, o laterales según convenga
• SpringLayout: Establece los componentes no solo por coordenadas, sino en relación a otros componentes dentro del mismo
• FlowLayout: Muy útil cuando se combinan varios de ellos, establece los componentes uno a continuación de otro

Capa DAO. Comenzamos a hacer las primeras inserciones y obtención de ciertos datos, en los paneles de manejo de Ejercicios

Rediseñada ventana principal. Mediante el método setUndecorated() quitamos el borde de la ventana, haciendo una app más moderna. La idea es ahora mover la ventana por el escritorio mediante los cursores del teclado, aún sin implementar

Creacion de una capa Genérica DAO. Creamos una capa DAO genérica de la cual heredan todas. simplemente implementa los métodos básicos de apertura y cierre de sesión, mejorando pues mediante herencia no escribir código más de lo debido.

Creación de una clase de utilidades. Creamos en el package control una clase de utilidades ConversorUtilities que por el momento usamos para transformar las List que nos devuelve la capa DAO en Vector útiles para los JComboBox en la vista

Observable. Retiramos la herencia de la clase Observable a GenericDAO para extender la misma en el Controlador. Debe ser más útil en este caso. Aún por sacar provecho

###Abril 2015: Corrección de diversos errores. Corregimos errores de diseño en los paneles de creación de ejercicios, ya que era imposible cambiar el nombre a un ejercicio debido a que intercambiabamos el TextField por un ComboBox. Ahora cambia dinámicamente dependiendo del tipo de operación a realizar. Un panel, (CardioExercisePanel) lo hace ocultando los controles o haciéndolos visibles dependiendo de la operación, el otro (FitnessExercisePanel) los elimina o recoloca en el panel dependiendo de la operación. Dos maneras diferentes de realizar lo mismo. La primera resulta más sencilla

Implementación de controles de ventana. Implementamos que se pueda mover la ventana principal mediante los cursores de teclado, no obstante solo funciona en la principal y no se hereda hacia abajo, deberíamos arreglar esto.