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

Modelo Vista Controlador

Os dejo con un breve resumen de lo que significa el patrón Modelo Vista Controlador, y que mostrará el tipo de arquitectura que se desarrollará en el Framework.
Antes de realizar todo el análisis de requisitos, creo que seria una buena idea conocer un poco mas a fondo que significa este patrón de diseño.

Los patrones de diseño dan al software un conjunto de subsistemas predefinidos, especifican reglas y reparten responsabilidades haciendo de guía en la implementación del software.

Por lo tanto, los patrones ofrecen respuestas a nivel de diseño a problemas que puedan surgir o que sean derivados del desarrollo de software. Algunos de los problemas son la falta de reusabilidad de código, la eficiencia de este, la dificultad de mantenimiento y escalabilidad de sistemas....

En nuestro caso concreto, la parte de software dentro del sistema que vamos a tratar son las interfaces de usuario gráficas (GUI), y vamos a dar una respuesta a problemas derivados de ella, sobre todo en los puntos de facilidad de desarrollo, escalabilidad, mantenimiento y separación de capas (lógica del negocio con la vista y el comportamiento de esta).

ORIGENES

Introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. El objetivo de este no es mas que, como hemos dicho previamente, mantener separadas las diversas capas del software, para la mejora en cuanto a corrección de fallos, escalabilidad y mantenimiento del código.

DESCRIPCION

La principal regla del patrón es la separación de la parte gráfica con la parte de negocio (a su vez, se podría añadir separación de la capa de negocio de la capa de almacenamiento). Así, la dependencia de código entre capas sera de un grado menor, facilitando su manipulación.

Ahora bien, como se estructura este patrón:

• Modelo: Esta sirve como representación específica de toda la información con la cual el sistema va a trabajar, y contiene la lógica de negocio, lo que nos asegurara la independencia de tenerla en la capa gráfica (se aplica las mismas reglas al mismo modelo) La lógica de datos nos puede llegar a asegurar la integridad de ellos y nos permitirá derivar nuevos datos.

• Vista: Realiza una representación del modelo en forma de interfaz gráfica. Esto sera lo que el usuario vera por pantalla.

• Controlador: Responde a eventos, invocados por el usuario y manipula el comportamiento en los cambios sobre el modelo, y también lo realizara sobre la vista (por ejemplo, cuando un modelo envíe un evento notificando una acción realizada, el controlador deberá saber que realizar al recibirlo).

Una representación del patrón seria como nos muestra la imagen inferior

Aun así, convendría una explicación mas real de como funciona el comportamiento del patrón contando desde la participación del usuario.

1. El usuario realiza una acción sobre la interfaz de usuario (pulsa un botón, por ejemplo "buscar").

2. El controlador gestiona la acción que el usuario ha ejecutado y por medio de un gestor de eventos (handler) realiza las acciones correspondientes.

3. En este caso, el controlador ha hecho una petición de búsqueda, se actualiza el modelo de forma coherente con la nueva información y se actualiza la vista con los nuevos datos.

4. La vista pide los nuevos datos al modelo para iniciarla y mostrarla.

5. El modelo notifica a los controladores asociados que su estado ha sido cambiado, por lo que estos actualizaran las vistas que tengan asociadas con el modelo.

Como se puede observar, todas estas acciones son el objetivo a implantar, permitiendo al usuario que pueda crear componentes controladores, de vista y modelo, que implementen este funcionamiento de forma tal que pueda ser abstraído de la mayor forma posible para que el desarrollador no necesite escribir código redundante en cada uno de los nuevos componentes, y solo necesite saber de unas pocas reglas que proporcionara el framework que implemente este patrón.

Si vamos al sitio de wikipedia donde se define http://es.wikipedia.org/wiki/Modelo_Vista_Controlador, podemos contar como hay varios frameworks implantados ya. El problema, es que no hay frameworks estandarizados para la creación de aplicaciones de escritorio. Por ejemplo, en Java tenemos Swing, que hace una implementación interna siguiendo parte de este modelo (internamente se separa el modelo del componente gráfico, por ejemplo un objeto JTable tiene asociado un modelo sobre el que trabajar). Pero no ofrece la posibilidad al desarrollador de que sus futuras aplicaciones utilizando Swing puedan seguir perfectamente esta arquitectura completamente. En si, el desarrollador podrá separar las diferentes capas, pero el nivel de trabajo que tendrá que hacer sera mayor y muchas veces poco eficaz, debido a que el objetivo principal de su trabajo esta orientado a desarrollar una aplicación de escritorio, no un framework que implemente este patrón (hay algún desarrollo propio, como el proyecto TikeSwing),.

He elegido la plataforma Mono y GTK# debido a que es un producto nuevo, que al estar en fase de desarrollo y expansión, el resultado del proyecto podrá tener mayor repercusión y también habrá una mayor implicación debido a la escasez de proyectos con el mismo objetivo.

Presentacion

Lo primero, quiero pedir disculpas de antemano por las faltas ortograficas. El teclado de mi ordenador esta actualmente en ingles y no me apetece nada cambiarlo ya que debo seguir utilizando este idioma para otras cosas.

El objetivo de este blog es realizar un seguimiento a traves del tiempo de todo el trabajo que haga para la elaboracion del proyecto fin de master. El proyecto fin de master consiste en realizar una implementacion del patron MVC (Modelo Vista Controlador) en la plataforma Mono, para el framework GTK#. Aunque actualmente lo llevo un poco parado, debido a que debo realizar y entregar diferentes practicas, espero que a finales de esta semana pueda tener algo mas para publicar. El contenido del siguiente post sera el objetivo que quiero conseguir con este proyecto, las lineas de planificacion del proyecto, un analisis del proyecto y los requisitos a cumplir y tambien espero publicar el sitio web que hospedara todo el proyecto (supongo que sera en Sourceforge.net) y tambien aquellos foros en los que me habre inscrito para recibir ayuda y demas.