Swing (Java)
Swing es un framework de interfaz gráfica de usuario «modelo-vista-controlador» independiente de la plataforma para Java, que sigue un modelo de programación de un solo hilo. Además, este marco proporciona una capa de abstracción entre la estructura del código y la presentación gráfica de una GUI basada en Swing.
FundamentosEditar
Swing es independiente de la plataforma porque está completamente escrito en Java. La documentación completa de todas las clases de Swing se puede encontrar en la Guía de la API de Java para la versión 6 o en la Especificación de la API de la Plataforma Java Standard Edition 8 para la versión 8.
Edición Extensible
Swing es una arquitectura altamente modular, que permite «enchufar» varias implementaciones personalizadas de interfaces de marco especificadas: Los usuarios pueden proporcionar su(s) propia(s) implementación(es) personalizada(s) de estos componentes para anular las implementaciones por defecto utilizando el mecanismo de herencia de Java a través de javax.swing.LookAndFeel.
Swing es un marco de trabajo basado en componentes, cuyos componentes son todos en última instancia derivados de la clase javax.swing.JComponent. Los objetos Swing disparan eventos de forma asíncrona, tienen propiedades vinculadas y responden a un conjunto documentado de métodos específicos del componente. Los componentes Swing son componentes JavaBeans, que cumplen con la especificación JavaBeans.
ConfigurableEdit
La gran dependencia de Swing de los mecanismos en tiempo de ejecución y de los patrones de composición indirecta le permite responder en tiempo de ejecución a cambios fundamentales en su configuración. Por ejemplo, una aplicación basada en Swing es capaz de cambiar en caliente su interfaz de usuario durante el tiempo de ejecución. Además, los usuarios pueden proporcionar su propia implementación de aspecto y sensación, lo que permite cambios uniformes en el aspecto y la sensación de las aplicaciones Swing existentes sin ningún cambio programático en el código de la aplicación.
El alto nivel de flexibilidad de Swing se refleja en su capacidad inherente para anular los controles de la interfaz gráfica de usuario del sistema operativo (SO) nativo para mostrarse. Swing «pinta» sus controles utilizando las API 2D de Java, en lugar de llamar a un kit de herramientas de interfaz de usuario nativo. Por lo tanto, un componente Swing no tiene un componente GUI nativo del sistema operativo, y es libre de representarse a sí mismo de cualquier manera que sea posible con las interfaces gráficas subyacentes.
Sin embargo, en su núcleo, cada componente Swing se basa en un contenedor AWT, ya que (Swing) JComponent extiende (AWT) Container. Esto permite a Swing conectarse al marco de gestión de la interfaz gráfica de usuario del sistema operativo anfitrión, incluyendo las asignaciones cruciales de dispositivo/pantalla y las interacciones del usuario, como la pulsación de teclas o los movimientos del ratón. Swing simplemente «transpone» su propia semántica (independiente del sistema operativo) sobre los componentes subyacentes (específicos del sistema operativo). Así, por ejemplo, cada componente Swing pinta su representación en el dispositivo gráfico en respuesta a una llamada a component.paint(), que se define en Container (AWT). Pero a diferencia de los componentes AWT, que delegan el pintado a su widget «pesado» nativo del sistema operativo, los componentes Swing son responsables de su propio renderizado.
Esta transposición y desacoplamiento no es meramente visual, y se extiende a la gestión y aplicación de Swing de su propia semántica independiente del sistema operativo para los eventos disparados dentro de sus jerarquías de contención de componentes. En términos generales, la arquitectura Swing delega en el contenedor AWT la tarea de mapear los diversos sabores de la semántica de la interfaz gráfica de usuario del sistema operativo en un patrón simple, pero generalizado. Basándose en esa plataforma generalizada, establece su propia semántica de GUI, rica y compleja, en la forma del modelo JComponent.
Acoplado débilmente y MVCEdit
La biblioteca Swing hace un uso intensivo del patrón de diseño de software modelo-vista-controlador, que desacopla conceptualmente los datos que se ven de los controles de la interfaz de usuario a través de los cuales se ven. Por ello, la mayoría de los componentes Swing tienen modelos asociados (que se especifican en términos de interfaces Java), y los programadores pueden utilizar varias implementaciones por defecto o proporcionar las suyas propias. El marco de trabajo proporciona implementaciones por defecto de las interfaces de los modelos para todos sus componentes concretos. El uso típico del marco Swing no requiere la creación de modelos personalizados, ya que el marco proporciona un conjunto de implementaciones por defecto que se asocian de forma transparente, por defecto, con la correspondiente clase hija JComponent de la biblioteca Swing. En general, sólo los componentes complejos, como las tablas, los árboles y a veces las listas, pueden requerir las implementaciones de modelos personalizados en torno a las estructuras de datos específicas de la aplicación. Para tener una buena idea del potencial que la arquitectura Swing hace posible, considere la situación hipotética en la que los modelos personalizados para tablas y listas son envoltorios sobre servicios DAO y/o EJB.
Típicamente, los objetos del modelo del componente Swing son responsables de proporcionar una interfaz concisa que define los eventos disparados, y las propiedades accesibles para el modelo de datos (conceptual) para su uso por el JComponente asociado. Dado que el patrón general MVC es un patrón de relación de objetos de colaboración poco acoplados, el modelo proporciona los medios programáticos para adjuntar escuchas de eventos al objeto del modelo de datos. Normalmente, estos eventos están centrados en el modelo (por ejemplo, un evento de «fila insertada» en un modelo de tabla) y son mapeados por la especialización JComponent en un evento significativo para el componente GUI.
Por ejemplo, el JTable tiene un modelo llamado TableModel que describe una interfaz para cómo una tabla accedería a los datos tabulares. Una implementación por defecto de esto opera en un array bidimensional.
El componente de vista de un JComponente Swing es el objeto utilizado para representar gráficamente el control conceptual de la GUI. Una distinción de Swing, como marco de trabajo de la GUI, está en su dependencia de los controles de la GUI renderizados mediante programación (en contraposición al uso de los controles de la GUI del sistema operativo anfitrión nativo). Antes de la actualización 10 de Java 6, esta distinción era una fuente de complicaciones cuando se mezclaban controles AWT, que utilizan controles nativos, con controles Swing en una GUI (véase Mezcla de componentes AWT y Swing).
Por último, en términos de composición y gestión visual, Swing favorece los diseños relativos (que especifican las relaciones posicionales entre los componentes) frente a los diseños absolutos (que especifican la ubicación y el tamaño exactos de los componentes). Este sesgo hacia la ordenación visual «fluida» se debe a sus orígenes en el entorno operativo de los applets que enmarcó el diseño y desarrollo del conjunto de herramientas de interfaz gráfica de usuario original de Java. (Conceptualmente, esta visión de la gestión de la disposición es bastante similar a la que informa la representación del contenido HTML en los navegadores, y aborda el mismo conjunto de preocupaciones que motivaron la primera.)
Relación con AWTEdit
Por el contrario, los componentes Swing se describen a menudo como ligeros porque no requieren la asignación de recursos nativos en el conjunto de herramientas de ventanas del sistema operativo. Los componentes AWT se denominan componentes pesados.
Mucha de la API de Swing es generalmente una extensión complementaria de la AWT en lugar de un reemplazo directo. De hecho, cada interfaz ligera de Swing existe en última instancia dentro de un componente pesado AWT porque todos los componentes de nivel superior de Swing (JAppletJDialogJFrame, y JWindow) extienden un contenedor de nivel superior AWT. Antes de la actualización 10 de Java 6, se desaconsejaba el uso de componentes ligeros y pesados dentro de la misma ventana debido a las incompatibilidades del orden Z. Sin embargo, las versiones posteriores de Java han solucionado estos problemas, y ahora se pueden utilizar tanto componentes Swing como AWT en una interfaz gráfica de usuario sin problemas de orden Z.
La funcionalidad de renderizado central utilizada por Swing para dibujar sus componentes ligeros es proporcionada por Java 2D, otra parte de JFC.
Relación con SWTEdit
El Standard Widget Toolkit (SWT) es un kit de herramientas de la competencia desarrollado originalmente por IBM y mantenido ahora por la comunidad Eclipse. La implementación de SWT tiene más en común con los componentes pesados de AWT. Esto le confiere ventajas como una mayor fidelidad con el kit de herramientas de ventanas nativo subyacente, a costa de una mayor exposición a la plataforma nativa en el modelo de programación.
Ha habido un importante debate y especulación sobre el rendimiento de SWT frente a Swing; algunos insinuaron que la fuerte dependencia de SWT de JNI lo haría más lento cuando el componente de la interfaz gráfica de usuario y Java necesitan comunicar datos, pero más rápido en la renderización cuando el modelo de datos se ha cargado en la interfaz gráfica de usuario, pero esto no se ha confirmado de ninguna manera. Un conjunto bastante completo de pruebas comparativas realizadas en 2005 concluyó que ni Swing ni SWT superaban claramente al otro en el caso general.