Últimos widgets

Visto que el tiempo se me echa encima y que no he podido ir más rápido en el desarrollo de anteriores widgets, tendré que cerrar una lista reducida y definitiva con los widgets a implementar. Éstos serán, TextView (para hacer áreas de texto extenso), Radio Button, Check Button, Label, Spinne y si aún tengo tiempo el Tree View (con vistas de poder implementar un widget usando componentes de listas, lo que es más complejo).

Primeras pruebas

De forma muy rapida, que he conseguido un hueco durante el trabajo para poder hacer esta entrada (perdonar por las faltas, pero no quiero cambiar el mapa del teclado ahora).

Este fin de semana termine de implementar el componente MGWindow, y de realizar algunas pruebas sobre el componente MGEntry (desafortunadamente no he podido empezar con los componentes MGComboBox y MGCombo, prefiero empezar a hacer pruebas ahora sobre lo existente, aun asi, espero tenerlo implementado a final de la semana). Las pruebas han resultado exitosas, considerando que he tenido que corregir algunos pequenyos bugs, pero con el tiempo que me ha tomado (alrededor de una hora) se puede considerar un exito :). Tambien quise probar el componente MGWindow, pero creo que antes lo hare con los paneles y una vez lo tenga, probare con MGWindow (mucha funcionalidad es comun, con lo que no importa mucho el orden).

Algunas conclusiones: Que pobre es MonoDevelop. A pesar de tener ya un desarrollo encima de seis anyos, el IDE es muy muy pobre y pesado. El trabajo realizado me podria haber tomado un 60% menos de tiempo con otro IDE (Eclipse, por ejemplo) que tenga a Mono plenamente integrado (No, el plugin para desarrollar C# en Eclipse no me sirve. Solo es un plugin de sintaxis de codigo).
He visto que se puede generar codigo en Java y que sea compilado para generar bytecode capaz de correr en Mono, asi como usar las librerias Gtk en Java. Podria ser una consideracion a tomar en cuenta en caso de que antes de Semana Santa haya desviaciones de tiempo y no sea posible seguir adelante, aunque mi objetivo es desarrollarlo en C# (por el simple hecho de que quiero profundizar en este lenguaje).
Segundo, sobre C#, he estado leyendo en foros que no tiene covarianza (espero traducirlo bien) de tipos. Supongo que los que vengan del mundo Java, como yo, les sonara.
Cuando implementas una Interface, puedes cambiar el tipo de retorno de uno de los metodos implementados por un tipo de clase derivado del tipo definido en el metodo del interface. Pues en C# no es posible, por decision de seguridad, hay error de compilacion. He tenido que hacer un "apanyo", pero no es ni mucho menos bonito, legible, y por supuesto practico (aunque para mi framework lo es) en terminos globales.

Actualizacion: he encontrado un plugin para Eclipse: Improve C#. Parece que esta bien en cuanto a la sintaxis y ejecucion, aunque echo en falta un plugin para correr pruebas de unidad con NUnit. Esta tarde lo probare, aunque no creo que utilice Eclipse. Debido a malas experiencias previas, prefiero desarrollar todo en un mismo IDE.

Perfilando la primera parte

Buenas a todos.

Después de varios meses con sobresaltos y algún que otro problema, ya voy consiguiendo algo palpable.

Después de haber estado desarrollando el framework durante febrero, ya tengo concluido las clases que componen el núcleo, algunas clases para el tratamiento de errores y validación, y también he implementado FixedContainer, HBox, VBox, LayoutContainer y también he implementado el componente GTK Button y Entry. Como anotación de relevancia, he añadido en todas las clases el prefijo MG, para así distinguirlos de las clases extendidas del framework GTK. Aún tengo planeado realizar alguna otra implantación durante este fin de semana (como Window, ComboBox y Combo).

Una vez realizadas, podré empezar una serie de pruebas (en verdad he ido probando varios componentes durante la implementación, aunque de forma muy trivial), realizando pruebas unitarias, y pruebas de integración de todos los componentes dentro de una pequeña GUI realizada para estos menesteres. Las pruebas en las que estoy interesado son, por orden de prioridad, la respuesta de los componentes a una actualización de la vista (reflejar cambios del modelo en la vista), viceversa (actualización del modelo con datos extraídos de la vista), llamada y comportamiento de los componentes hijos dentro de los widgets que correspondan a instancias del framework, cumplimento de las normas de validación (bien por expresión regular o bien por métodos encontrados en una instancia de un tercer objeto).

Una vez hecho esto, espero que termine antes de Semana Santa, podré realizar posibles cambios en el diseño, o continuar mejorando el sistema de eventos internos del framework ante cambios en modelo y/o componentes. Después de Semana Santa, una vez acabados estos pasos anteriormente descritos, espero seguir haciendo más componentes y llegar a finales de abril con una serie de nuevos componentes.

Este fin de semana, una vez vaya acabando los componentes previstos al comienzo del post, volveré a publicar otro nuevo post con novedades y anécdotas.

Especificaciones de requisitos

Lamento haber estado tanto tiempo sin escribir, pero todo ha sido derivado por problemas de agenda. Sí, ya sé que seguramente podría haber sacado 20 minutos para actualizar un poco esto.

Esta entrada está referida a los requisitos que he obtenido que, a mi parecer, debería tener el framework para poder ser efectivo. Como principales objetivos de los que parto para reunir las especificaciones son los siguientes:

1. Encapsulación del código para su mejor mantenimiento y futuros desarrollos que puedan derivar de código ya escrito.
2. Dar capacidad al desarrollador de ahorro de tiempo. El desarrollador por lo tanto, tiene que escribir menos lineas de código que lo haría con un desarrollo normal. Hay que tener en consideración el punto anterior.

A partir de aquí, derivan los siguientes requisitos. Puede que sea un breve número, pero debido a la abstracción que esto requiere, prefiero que sean genéricos y también lo suficientemente abstractos para que una vez en la etapa de desarrollo se puedan ir desglosando o añadiendo nuevos. Por supuesto, espero que las siguientes etapas no sean tan abstractas, aunque como se ha dicho, prefiero que el desarrollo sea lo suficientemente dinámico para cambiar requisitos y diseño (también espero que ésto no sea muy frecuente :P).

1. Crear una serie de clases que permitan implementar con facilidad nuevos componentes de interfaz de usuario. El objetivo se centraría en poder crear una buena estructura de las clases que componen el proyecto, para que pueda facilitarse el trabajo al desarrollador a la hora de utilizarlas para sus proyectos personales y poder a su vez, reutilizarlos en otros proyectos sin causar errores críticos en el funcionamiento.

2. Abstracción de dependencias con otras librerías que pueda ser usada en el sistema (por ejemplo, si el modelo son objetos de persistencia). Lo mas normal es que la simpleza de los diversos componentes del framework pueda hacer que se puedan utilizar elementos de otras librerías y frameworks tanto en la parte del modelo como en la vista.

3. El modelo debe notificar a los controladores que dependan activamente de el. Con lo cual se podrá mantener en tiempo real el reflejo de las estructuras de datos del modelo sin que haya un gran consumo de recursos que afecten la aplicación. Por ejemplo, al crear un nuevo elemento, se guardaría en la base de datos, pero no se debería volver a pedir toda la información referente a el a la base de datos otra vez.

4. El controlador deberá implementar un sistema eficaz, que gestione todas las peticiones que haga el usuario en la vista (un handler) y realizar las acciones pertinentes. En caso de que el modelo se modifique y se quiera realizar un actualizado, este deberá notificar a los controladores que su información ha sido cambiada, para así realizar una actualización de la vista. Este requisito esta enfocado a la realización de algún sistema, bien por asociación del nombre de componente con el evento. Por ejemplo, botón “btnBuscar”, la notación que tendríamos seria que al recibir el evento, se tendría que invocar un método llamado “btnBuscarPressed”. Por supuesto, esto no es regla la regla de como debería ser implementado, pero nos acercaría a que esta especificación de como debería de simplificar el trabajo del desarrollador.

5. Los controladores deben tener mecanismos que permitan al desarrollador, actualizar la vista, actualizar solo uno de los componentes de la vista (puede estar formados por varios componentes). Se debería de implementar alguna serie de reglas para definir el comportamiento de las vistas. Debería ser posible mediante la definición de los tipos de evento lanzados y que el controlador pueda decidir la acción a llevar. Esto implicaría que al modificar el modelo, no se debería modificar directamente la vista, sino a partir del controlador.

6. Los componentes GTK# deberán ser adaptados a este framework, por lo tanto, deberán ser extendidos todos los componentes GTK que se usaran en el. Al igual que se definió en el primer punto, Los componentes deberán ser redefinidos para implementar la funcionalidad del framework y hacer que puedan ser fácilmente utilizados en el desarrollo. Por supuesto, en caso de poder realizar alguna modificación en el comportamiento (por ejemplo, simplificación de la inserción de objetos en un componente Combo Box) del componente, seria ideal hacerlo, aunque deberíamos poder dejar al desarrollador la capacidad de poder realizar operaciones con el componente directamente (es decir, manipulación directa de los componentes GTK#).

7. Se debe tener un control sobre los datos, tal que permita al desarrollador recuperar datos del modelo cambiados en sucesivas fases. Este requisito estaría lejos de la idea inicial y podría ser implementado en un futuro, en caso de tener tiempo. La idea seria poder realizar una cola con los diversos estados de los datos que el modelo ha ido teniendo a lo largo del periodo (puede estar limitado) de ejecución de la aplicación.

Ya tengo desarrollado los casos de uso y estoy a punto de terminar el diseño, aunque esperaré a terminar este último punto antes de publicar otros dos posts, referidos a cada una de las etapas descritas respectivamente.