3002007040302. Adaptando un control Java Swing a la plataforma .NET

Sin duda hoy dA�a hay dos lenguajes de desarrollo y sus plataformas asociadas que captan la mayorA�a de la atenciA?n para los programadores: Java y .Net. Cada una tiene sus puntos fuertes y ventajas. Y como lenguajes distintos, emplean terminologA�a, estructuras e instrucciones diferentes. No es raro que soluciones creadas con una ellas deban trasladarse a la otra, o que se necesite aprovechar algA?n mA?dulo o soluciA?n escrita en el otro lenguaje. Un ejemplo tA�pico, sobre el cual se basa esta explicaciA?n, serA�a trasladar un control Java Swing para su empleo en la plataforma .Net. Veamos los puntos importantes a tomar en consideraciA?n para lograrlo.

Diferencias entre los conceptos de cada lenguaje

Las diferencias mA?s obvias al pasar de Java a .NET son las que existen entre el lenguaje Java y C#. Aunque ambos lenguajes compartan conceptos muy similares, es muy importante tener en consideraciA?n ciertos aspectos de C#, ya que tienen reflejo en la manera en la que escribimos cA?digo.

La nociA?n struct, familiar para los desarrolladores de C y C++, no existe en Java. En Java todo es una clase, lo que puede resultar molesto en algunas situaciones. Al implementar interfaces de usuario y grA?ficos, a menudo se utilizan pequeA�os objetos como rectA?ngulos y puntos, que suelen tener una vida corta. Para evitar el pasar demasiado tiempo creando y desechando estos pequeA�os objetos, los programadores Java suelen utilizar cachA�s o colecciones de objetos reutilizables.

La ausencia de struct en el lenguaje Java tambiA�n fuerza a los desarrolladores a proporcionar mA�todos que permitan al usuario reutilizar esos objetos pequeA�os. Por ejemplo, en la clase java.awt.geom.AffineTransform nos encontramos con el siguiente mA�todo:


public Point2D transform(Point2D ptSrc,Point2D ptDst)


El primer parA?metro hace referencia al punto que debe ser transformado, mientras que el segundo representa el objeto que almacenarA? el resultado. Este segundo parA?metro puede ser nulo, por lo que en este caso se asigna un nuevo objeto Point2D. Una definiciA?n como esta permite al usuario de este mA�todo reutilizar el mismo objeto para almacenar el resultado, al requerir este proceso en reiteradas ocasiones, evitando asA� la creaciA?n de demasiados objetos.

En .NET preferimos emplear struct para objetos mA?s pequeA�os, de cara a un mejor rendimiento. Tendremos que anotar y cambiar los mA�todos escritos, de la misma forma que hicimos con el mA�todo transform mA?s arriba.

Otra importante construcciA?n del lenguaje heredada en Visual Basic es la declaraciA?n foreach. Aunque a simple vista no parece mA?s que una manera simplificada de enumerar los elementos de una colecciA?n, lo cierto es que las clases .NET Framework muestran gran cantidad de propiedades que son colecciones. Los programadores C# y Visual Basic .NET estA?n acostumbrados a trabajar con colecciones de objetos y enumerarlos utilizando declaraciones foreach.

Por ejemplo, para aA�adir un objeto en un JComboBox de Java podemos utilizar el siguiente cA?digo:


combo.addItem(value)


En .NET, en un objeto ComboBox, escribirA�amos:


combo.Items.Add(value)


Otra razA?n que nos conduce a emplear objetos de colecciA?n al definir un API .NET radica en que las colecciones pueden ser editadas con facilidad en Visual Studio .NET. En Java, para editar una colecciA?n de objetos en un IDE JAVA utilizamos propiedades indexadas, definidas con los siguientes getters y setters segA?n la especificaciA?n JavaBeans:


void setter(int index, PropertyType value); // indexed setter

PropertyType getter(int index); // indexed getter

void setter(PropertyType values()); // array setter

PropertyType() getter(); // array getter


Incluso, si estA? funciA?n estA? definida con la especificaciA?n JavaBeans, no parece que se use realmente en un IDE Java.

Visual Studio.NET proporciona editores predefinidos para editar colecciones de objetos, permitiendo aA�adir y quitar objetos, asA� como editar sus propiedades dentro de la colecciA?n. De esta forma, al diseA�ar un control para la plataforma .NET tendremos que exponer nuestras colecciones de objetos implementando los interfaces ICollection e IList en la medida de lo posible.

DiseA�ando controles: Visual Studio .NET frente a JavaBeans

Ya hemos observado cA?mo los lenguajes .NET introducen conceptos que afectan a la manera en la que el .NET API de nuestro control debe ser diseA�ado. Pero probablemente lo que afectarA? en mayor medida al API del control de Windows Forms es que dicho control serA? utilizado dentro de Visual Studio .NET.

Los desarrolladores que emplean nuestros controles esperan ser capaces de aA�adirlos al conjunto de herramientas de Visual Studio .NET, arrastrarlos hasta el diseA�ador de Windows Forms y usar gran parte de las caracterA�sticas del mismo con tan sA?lo modificar sus propiedades. Ellos no tienen en mente el escribir demasiado cA?digo, lo que ha de ser tenido en cuenta a la hora de diseA�ar el control.

En algunos aspectos hay muchas similitudes entre diseA�ar un control para convertirlo en un componente de primera clase de Visual Studio .NET y diseA�ar un Swing Java Bean que sea utilizado en un IDE Java. Por ejemplo, el componente debe tener un constructor vacA�o. Todas las propiedades expuestas no deben tener efectos colaterales y asA� debe ser en adelante, pero las caracterA�sticas a la hora de diseA�ar Visual Studio .NET son mA?s potentes que las de JavaBeans.

((Una de las mejoras mA?s importantes que Visual Studio .NET ofrece en comparaciA?n con JavaBeans es que se pueden editar las propiedades de un control))

Probablemente, una de las mejoras mA?s importantes que Visual Studio .NET ofrece en comparaciA?n con JavaBeans es que se pueden editar las propiedades de un control, definiA�ndolo como un objeto o una colecciA?n de objetos.

Por ejemplo, en Visual Studio .NET podemos editar tanto una colecciA?n de columnas de un DataGrid como las propiedades de una sola columna. NingA?n IDE Java proporciona una caracterA�stica similar para una Swing JTable.

Desde el momento en el que podemos ofrecer mA?s prestaciones a la hora de diseA�ar, nos encontraremos con mA?s cA?digo que desarrollar para implementar cosas como conversores del tipo, editores personalizados para propiedades o tipos, conversores para transformar las propiedades mA?s complejas en cA?digo o incluso asistentes.

Las caracterA�sticas para diseA�ar una soluciA?n de control .NET son cruciales para los desarrolladores que utilizan nuestros controles y deben ser implementadas a la vez que el propio control.

Swing MVC y ADO.NET

En Swing todos los controles se diseA�an utilizando la plantilla de diseA�o Model-View-Controller, que separa los datos propios de los datos de monitorizaciA?n del control. De todas formas, al crear un control Swing, parece obvio seguir una plantilla de este estilo. Si bien, Windows Forms no la mantiene.

Lo mA?s cercano a MVC en Windows Forms es probablemente el hecho de que varios controles (por ejemplo el control DataGrid) son capaces de conectarse a varias fuentes de datos, tales como objetos ADO .NET u objetos que implementan la interfaz iList. Nada previene a un programador de utilizar una plantilla de diseA�o MVC al diseA�ar un nuevo control en .NET.

((Si el control tiene que mostrar datos complejos, probablemente tengamos que facilitar una manera de conectar el control a ADO .NET
))

De todas formas, si el control tiene que mostrar datos complejos, probablemente tengamos que facilitar una manera de conectar el control a ADO .NET, ya que ADO .NET es la principal fuente de datos para los controles Windows Forms.

Dibujando el control

Si alguna vez ha desarrollado un control Swing que muestre grA?ficos complejos, entonces estarA? familiarizado con el API Java2D introducido desde JDK 1.2. NET. Framework ofrece el mismo tipo de funcionalidad que el comando System.Drawing.Drawing2D. El kit de herramientas de dibujo de .NET recibe el nombre de GDI+ y, aunque no cubre todas las funciones que sA� proporciona Java2D, en muchos casos con GDI+ es mA?s que suficiente.

Los dos sistemas son muy similares. Ambos incluyen funciones grA?ficas modernas tales como composiciA?n alpha, anti-aliasing, degradados y dibujos con cualquier tipo de forma. La diferencia entre Java y .NET serA? aquA� mas importante, si queremos programar utilizando nuestro control para personalizar parte de los grA?ficos que muestran dicho control.

((La nociA?n del propietario de los eventos de dibujo es uno de los patrones de diseA�o empleados por los controles .NET Framework en Windows Forms))

La nociA?n del propietario de los eventos de dibujo es uno de los patrones de diseA�o empleados por los controles .NET Framework en Windows Forms, que permiten al desarrollador personalizar la apariencia de su control.

Por ejemplo, System.Windows.Forms.ListBox define un DrawItem y un evento MeasureItem que puede ser manejado para crear un ListBox propio. En Java, el API Swing define una interfaz ListCellRenderer que puede ser implementada para personalizar el renderizado de una celda. Ambos sistemas sirven para el mismo propA?sito.

En el mundo .NET escogemos proporcionar la personalizaciA?n de los controles a travA�s de eventos, ya que esta nociA?n resulta familiar para los usuarios .NET y se puede acceder a ella directamente a travA�s de Visual Studio .NET. Este es otro ejemplo que nos muestra que la elecciA?n de implementaciA?n viene de la mano de la integraciA?n dentro del IDE. En nuestro control Gantt hemos optado por esta tA�cnica para permitir la personalizaciA?n de barras que representan tareas.

InternacionalizaciA?n y LocalizaciA?n

Internacionalizar el control es otro punto en el que la filosofA�a cambia, aunque las tA�cnicas sean similares. En Java situamos el texto que aparece en la interfaz de usuario en un archivo fuente que depende de la localizaciA?n y emplea un objeto ResourceBundle para cargar el texto dependiente de dicha localizaciA?n. En el sistema .NET resulta similar, aunque la informaciA?n local se almacena en un archivo fuente (.resx), compilado en una DLL especA�fica de cada localizaciA?n.

Mientras en Java usamos objetos gestores de la disposiciA?n, que se encargan de ajustar el posicionamiento de los sub-controles en el panel, en .NET, en lugar de utilizar complejos gestores de la disposiciA?n, almacenamos la posiciA?n en las DLLs dependientes de cada localizaciA?n, asA� como el tamaA�o de los controles. De esa forma, nuestra interfaz de usuario puede ser completamente diferente de un paA�s a otro.

El camino escogido por .NET parece a simple vista mucho mA?s sencillo: no hay necesidad de utilizar ni escribir cA?digo de complejos gestores de posicionamiento e implementar la creaciA?n de las DLLs mediante Visual Studio .NET. La desventaja es que con .NET hemos diseA�ado una interfaz de usuario para una fuente especA�fica.

Al final, es el usuario el que decide si cambiar la fuente, de manera que el comportamiento predeterminado de Windows Forms hace que el cuadro de diA?logo se redimensione por sA� solo e intente adaptarse a la fuente. Pero este mecanismo predeterminado no es tan preciso como el de los gestores de posicionamiento. Por otra parte, podemos optar por posicionar la interfaz de usuario mediante cA?digo, pero entonces es como si utilizA?ramos dichos gestores de posicionamiento.

((Otra diferencia entre Java y .NET es que .NET Framework define dos culturas diferentes, o localizaciones, para la interfaz de usuario))

Otra diferencia entre Java y .NET es que .NET Framework define dos culturas diferentes (o localizaciones) para nuestra interfaz de usuario: UI Culture es la cultura empleada para cargar el recurso desde la DLL dependiente de la localizaciA?n; Current Culture, por su parte, se corresponde con la regiA?n establecida en el Panel de Control de Windows.

Es importante decidir quA� cultura queremos usar. En nuestro desarrollo Gantt todas las fechas predeterminadas y los formatos de nA?meros se representan usando Current Culture. El usuario de Gantt puede contar con una versiA?n francesa de Windows y ver toda la interfaz de usuario en francA�s y, en cambio, usar el formato inglA�s para las fechas.

Ya que Visual Studio situarA? automA?ticamente la informaciA?n dependiente de la localizaciA?n en un archivo de origen (resx.), como desarrolladores del control tenemos que especificar quA� propiedad de nuestro control serA? almacenada en dicho archivo. Esto se hace fA?cilmente con tan sA?lo aA�adir el atributo a�?Localizablea�� a la propiedad de nuestro control (class System.ComponentModel.LocalizableAttribute).

Esto es algo que conviene tener en consideraciA?n ya que, si una propiedad no queda marcada como a�?localizablea�?, entonces al usuario de nuestro control le serA? muy difA�cil localizar dicho valor. Al generarse automA?ticamente tanto el archivo .resx como el cA?digo mediante el diseA�ador Visual Studio .NET Form, un usuario no puede cambiar sin mA?s el archivo .resx o el cA?digo.

((El manual de referencia siempre se genera en HTML a partir de comentarios en el cA?digo fuente, mediante la herramienta Javadoc))

DocumentaciA?n

Al crear un control profesional, tenemos que pensar en la manera en que se documentarA? nuestro control. Al ser usados los controles Java en mA?ltiples plataformas, la documentaciA?n debe poder leerse en cualquier plataforma. A menudo vemos documentaciA?n en HTML o PDF. El manual de referencia siempre se genera en HTML a partir de comentarios en el cA?digo fuente, mediante la herramienta Javadoc proporcionada en JDK. En .NET no es necesario crear documentaciA?n portable, ya que sA?lo nos dedicamos a la plataforma Windows.

Lo importante es que nuestra documentaciA?n sea incorporada dentro de Visual Studio .NET. La ayuda de Visual Studio se encuentra en HTML Help 2.0 y, a diferencia de JDK con Javadoc, la plataforma .NET no ofrece todas las herramientas necesarias para crear un manual de referencia en este formato. .NET sA?lo ofrece una herramienta que extrae los comentarios en nuestro cA?digo para producir un archivo XML adecuado para IntelliSense. Para crear un manual de referencia en HTML Help 2.0 integrada dentro de Visual Studio tendremos que emplear herramientas adicionales como NDoc (http://sourceforge.net/projects/ndoc/), que produce documentaciA?n de librerA�as de clases, de la misma forma que Microsoft, en el formato HTML Help 2.0 format.

El proceso de creaciA?n de una adecuada documentaciA?n correctamente integrada es de todas formas mucho mA?s complejo en .NET que en Java, y requiere aprender cA?mo se usa HTML Help 2.0 y cA?mo se registra en el interior de Visual Studio .NET.

((En Java, no se proporciona ningA?n sistema en JDK para proteger nuestro control con una licencia))

Licenciando nuestro control

En Java, no se proporciona ningA?n sistema en JDK para proteger nuestro control con una licencia. AsA�, uno se ve obligado a usar productos comerciales o a definir su propio sistema de licencias. En .NET el framework ofrece una forma predefinida de licenciar controles. Aunque el entorno de trabajo para licenciar controles se encuentra incluido en .NET Framework, aA?n asA� nos seguimos viendo obligados a implementar el cA?digo licenciador, el tipo de clave que usaremos y el sistema que serA? comprobado en dicha clave.

((Reescribir un control ya escrito para Swing en .NET Framework no consiste en una simple portabilidad de Java a C#))

Claramente, reescribir un control ya escrito para Swing en .NET Framework no consiste en una simple portabilidad de Java a C#. Aunque este artA�culo abarca los principales aspectos a tener en cuenta, existen muchas otras diferencias entre ambas plataformas. Por ejemplo, asuntos relacionados con la impresiA?n, el aspecto o la apariencia, e incluso la seguridad.

Si tiene pensado adaptar un control escrito en Swing a la plataforma .NET, primero ha de familiarizarse con .NET antes de comenzar a adaptar la arquitectura de su control a esta nueva plataforma.

Salvador PeA�alver, director tA�cnico de ILOG EspaA�a