Swing (Java)
Swing é uma estrutura GUI independente de plataforma, “model-view-controller” para Java, que segue um modelo de programação com uma única rosca. Além disso, esta estrutura fornece uma camada de abstracção entre a estrutura de código e a apresentação gráfica de uma GUI baseada em Swing.
FoundationsEdit
Swing é independente de plataforma porque está completamente escrita em Java. Documentação completa para todas as classes Swing pode ser encontrada no Guia API Java para a Versão 6 ou na Especificação API da Plataforma Java Standard Edition 8 para a Versão 8.
ExtensibleEdit
Swing é uma arquitectura altamente modular baseada, que permite a “ligação” de várias implementações personalizadas de interfaces de enquadramento especificadas: Os utilizadores podem fornecer a(s) sua(s) implementação(ões) personalizada(s) destes componentes para substituir as implementações padrão usando o mecanismo de herança de Java via javax.swing.LookAndFeel.
Swing é uma estrutura baseada em componentes, cujos componentes são todos derivados da classe javax.swing.JComponent. Os objectos de Swing disparam de forma assíncrona, têm propriedades vinculadas, e respondem a um conjunto documentado de métodos específicos do componente. Os componentes Swing são componentes JavaBeans, em conformidade com a especificação JavaBeans.
ConfigurableEdit
Swing’s heavy reliance on runtime mechanisms and indirect composition patterns allows it to respond at run time to fundamental changes in its settings. Por exemplo, uma aplicação baseada em Swing é capaz de trocar a sua interface de utilizador a quente durante o tempo de execução. Além disso, os utilizadores podem fornecer a sua própria aparência e implementação, o que permite alterações uniformes na aparência das aplicações Swing existentes sem qualquer alteração programática ao código da aplicação.
Lightweight UI
Swing o elevado nível de flexibilidade reflecte-se na sua capacidade inerente de anular os controlos GUI do sistema operativo anfitrião (OS) nativo para se exibir a si próprio. Swing “pinta” os seus controlos utilizando as APIs Java 2D, em vez de chamar um conjunto de ferramentas de interface de utilizador nativo. Assim, um componente Swing não tem um componente GUI de SO nativo correspondente, e é livre de se renderizar de qualquer forma que seja possível com as GUIs gráficas subjacentes.
No entanto, no seu núcleo, cada componente Swing depende de um contentor AWT, uma vez que (Swing’s) JComponent estende (AWT’s) Container. Isto permite ao Swing ligar-se à estrutura de gestão de GUI do SO anfitrião, incluindo os mapeamentos cruciais do dispositivo/ecrã e as interacções do utilizador, tais como pressionamentos de teclas ou movimentos do rato. Swing simplesmente “transpõe” a sua própria semântica (OS-agnóstica) sobre os componentes subjacentes (OS específicos). Assim, por exemplo, cada componente Swing pinta a sua rendição no dispositivo gráfico em resposta a uma chamada a component.paint(), que é definida em (AWT) Container. Mas ao contrário dos componentes AWT, que delegaram a pintura no seu widget “heavyweight” nativo do SO, os componentes Swing são responsáveis pela sua própria renderização.
Esta transposição e desacoplamento não é meramente visual, e estende-se à gestão do Swing e à aplicação da sua própria semântica independente do SO para eventos disparados dentro das suas hierarquias de contenção de componentes. Em termos gerais, a arquitectura Swing delega a tarefa de mapear os vários sabores da semântica de OS GUI num padrão simples, mas generalizado, para o contentor AWT. Com base nessa plataforma generalizada, estabelece a sua própria semântica GUI rica e complexa sob a forma de JComponent model.
Loosely coupled e MVCEdit
A biblioteca Swing faz um uso pesado do padrão de design do software model-view-controller, que conceitualmente dissocia os dados que estão a ser visualizados a partir dos controlos da interface do utilizador através dos quais são visualizados. Devido a isto, a maioria dos componentes Swing têm modelos associados (que são especificados em termos de interfaces Java), e os programadores podem utilizar várias implementações padrão ou fornecer as suas próprias implementações. A estrutura fornece implementações por defeito de modelos de interfaces para todos os seus componentes concretos. A utilização típica da estrutura Swing não requer a criação de modelos personalizados, uma vez que a estrutura fornece um conjunto de implementações padrão que são transparentemente, por defeito, associadas com a correspondente JComponent classe criança na biblioteca Swing. Em geral, apenas componentes complexos, tais como tabelas, árvores e por vezes listas, podem requerer as implementações de modelos personalizados em torno das estruturas de dados específicas da aplicação. Para se ter uma boa noção do potencial que a arquitectura Swing torna possível, considerar a situação hipotética em que os modelos personalizados para tabelas e listas são envoltórios sobre serviços DAO e/ou EJB.
Tipicamente, os objectos do modelo de componentes Swing são responsáveis por fornecer uma interface concisa definindo eventos disparados, e propriedades acessíveis para o modelo de dados (conceptual) para utilização pelo JComponent associado. Dado que o padrão global MVC é um padrão de relação de colaboração de objectos livremente acoplado, o modelo fornece o meio programático para anexar os ouvintes do evento ao objecto modelo de dados. Tipicamente, estes eventos são centrados no modelo (ex: um evento “linha inserida” num modelo de tabela) e são mapeados pela especialização JComponent num evento significativo para o componente GUI.
Por exemplo, o JTable tem um modelo chamado TableModel que descreve uma interface para a forma como uma tabela acederia aos dados tabulares. Uma implementação padrão desta opera numa matriz bidimensional.
O componente de visualização de um componente Swing JComponent é o objecto utilizado para representar graficamente o controlo conceptual da GUI. Uma distinção do Swing, como uma estrutura GUI, está na sua dependência de controlos GUI programados (em oposição à utilização dos controlos GUI do SO anfitrião nativo). Antes da Actualização Java 6 10, esta distinção era uma fonte de complicações ao misturar controlos AWT, que utilizam controlos nativos, com controlos Swing numa GUI (ver Mixing AWT e componentes Swing).
Finalmente, em termos de composição visual e gestão, Swing favorece layouts relativos (que especificam as relações posicionais entre componentes) em oposição a layouts absolutos (que especificam a localização exacta e o tamanho dos componentes). Esta tendência para a ordenação visual “fluida” deve-se às suas origens no ambiente operacional do applet que emoldurou a concepção e desenvolvimento do kit original de ferramentas GUI Java. (Conceptualmente, esta visão da gestão do layout é bastante semelhante à que informa a renderização do conteúdo HTML nos browsers, e aborda o mesmo conjunto de preocupações que motivaram os primeiros.)
Relação com AWTEdit
Desde as primeiras versões de Java, uma parte do Abstract Window Toolkit (AWT) tem fornecido APIs independentes de plataforma para componentes de interface de utilizador. No AWT, cada componente é renderizado e controlado por um componente nativo específico para o sistema de janelas subjacente.
Por contraste, os componentes Swing são muitas vezes descritos como leves porque não requerem alocação de recursos nativos no conjunto de ferramentas de janelas do sistema operativo. Os componentes AWT são referidos como componentes pesados.
Much do API Swing é geralmente uma extensão complementar do AWT em vez de uma substituição directa. De facto, cada interface leve Swing existe em última análise dentro de um componente pesado AWT porque todos os componentes de nível superior em Swing (JAppletJDialogJFrame, e JWindow) estendem um recipiente de nível superior AWT. Antes da Actualização Java 6 10, a utilização de componentes leves e pesados dentro da mesma janela era geralmente desencorajada devido a incompatibilidades de ordem-Z. Contudo, versões posteriores de Java corrigiram estes problemas, e ambos os componentes Swing e AWT podem agora ser utilizados numa GUI sem problemas de ordem Z.
A funcionalidade de renderização do núcleo utilizada pelo Swing para desenhar os seus componentes leves é fornecida pelo Java 2D, outra parte do JFC.
h3> Relação com SWTEdit
O Standard Widget Toolkit (SWT) é um conjunto de ferramentas concorrente originalmente desenvolvido pela IBM e agora mantido pela comunidade Eclipse. A implementação do SWT tem mais em comum com os componentes de peso pesado do AWT. Isto confere benefícios como uma fidelidade mais precisa com o kit de ferramentas de janelas nativo subjacente, ao custo de uma maior exposição à plataforma nativa no modelo de programação.
Têm havido debates e especulações significativas sobre o desempenho do SWT versus Swing; alguns insinuaram que a forte dependência do SWT em relação à JNI o tornaria mais lento quando o componente da GUI e o Java precisam de comunicar dados, mas mais rápido na renderização quando o modelo de dados foi carregado na GUI, mas isto não foi confirmado de qualquer das maneiras. Um conjunto bastante exaustivo de referências em 2005 concluiu que nem o Swing nem o SWT tiveram um desempenho claramente melhor do que o outro no caso geral.