Há mais exemplos nos links da minha assinatura.
O mesmo vale para o DefaultMutableTreeNode. Prefira criar seu próprio TreeModel, como descrito aqui.
-
Não use Nullayout, ou redimensione componentes com setBounds. Eu sei que pode ser tentador as vezes, que lembra o Delphi e o VB, mas não faça isso. Usando esse layout, sua aplicação não suportará redimensionamento das janelas, não rodará em diferentes look&feel e você ter problemas ao troca-la de sistema operacional. No lugar, informe-se sobre os gerenciadores de layout, em especial, sobre o BorderLayout, FlowLayout, GridBagLayout e, se vc usar o matisse, sobre o GroupLayout. Outra boa opção é usar uma API de terceiros, chamada de MigLayout;
-
Aprenda como as coisas funcionam. Visual editor e matisse são legais, mas procure entender os conceitos por trás do Swing. Em especial, como funciona a divisão de model/view-controller dentro dele. Também aprenda como o Swing trabalha com sua thread. Você precisará criar conteúdo dinâmico cedo ou tarde e será importante saber como fazer janelas no braço.
-
Não tente modificar o comportamento padrão das coisas, caso o Swing não dê para você essa possibilidade “built-in”. Por exemplo, muita gente se incomoda pelo fato das barras de títulos dos internal panes do Swing não desaparecerem quando a janela é maximizada. Bem, é assim que é, e mudar esse comportamento vai te gerar um código difícil de manter, complexo e que dificilmente vale o esforço. É mais provável que seu usuário toparia de maneira diferente, ou nem se incomodaria tanto com isso assim;
-
Se for sobrescrever componentes, lembre-se que o método de pintura para ser sobrescrito é o paintComponent, não o paint. Também será necessário tirar uma cópia do objeto graphics recebido no parâmetro antes de usa-lo. Não tenha a brilhante idéia de sobrescrever um JPanel que contem outros botões, textos, etc. Não chame repaint() de dentro dos métodos paint e paintComponent, já que ele irá chamar esses mesmos métodos. Sobrescrever componentes é uma tarefa complexa, não despreze-a. Leia sobre como funciona a pintura no Swing e como trabalhar com Graphics2D antes de iniciar a faze-lo.
-
Processamentos pesados devem ser feito fora da thread do Swing. Use a classe SwingWorker para disparar uma outra thread e faze-lo. Processamentos feitos em outras threads não devem atualizar componentes do Swing diretamente. Chame o método EventQueue.invokeLater() ou EventQueue.invokeAndWait() para isso.
-
Nunca chame setVisible(true) no construtor de suas janelas. É uma boa prática deixar a escolha de quando a janela se tornará visível para quem deu “new” nela. Além disso, isso também garante que todos os componentes já estarão presentes na janela quando ela se abrir. Lembre-se que até que o construtor termine, a janela sequer foi construída totalmente ainda e torna-la visível é nesse momento é no mínimo estranho.
-
Não misture componentes do Swing com os da AWT. Além de ser completamente desnecessário, os componentes da AWT sempre ficarão acima dos componentes do Swing, por serem heavy-weight. Aliás, não há razões para você usar componentes AWT hoje em dia. Um erro comum é criar filhos de Window ou Canvas ao invés de JComponent.
-
KeyListeners dificilmente vão resolver seus problemas. Para validar campos de texto (JTextField, JTextArea, JTextPane), informe-se sobre os objetos Document e o InputVerifier. Existe até um tutorial no GUJ a respeito do Document. Para disparar eventos através do teclado, conheça o InputMap e o ActionMap, como nesse exemplo de uma calculadora. Quando pensar no KeyListener, lembre-se que seu usuário geralmente pode usar CTRL+C e CTRL+V com o mouse, e você vai ver que a solução não passa por aí.
-
Trate eventos separadamente. Fazer seu JFrame implementar actionListener e redirecionar todos os eventos para um único actionPerformed, além de uma grande estupidez, gera código espaguete e exige que você novamente separe esses eventos num switch, o que piora a performance do código. Use no lugar uma inner class anônima para cada evento, ou melhor ainda, implemente Actions.
-
Evite usar o DesktopPane e o InternalFrame. Sua implementação simplesmente não é boa. A barra de títulos do InternalFrame não desaparece quando ele é maximizado, não aparecem barras de rolagem no desktop pane caso um internal frame fique fora da área dele. Note também que aplicações MDI tem desaparecido até do Windows. O próprio Office não é mais assim;
-
Comunique dados entre janelas através de passagens de parâmetros, nunca através de variáveis estáticas.
-
Evite usar Singletons. Dois locais comuns onde você pode ficar tentado é na construção de janelas e na conexão com o banco de dados. Janelas singleton são menos reutilizáveis e nunca são elegíveis para garbage collection. Conexões com o banco de dados singleton sempre ficam abertas, desperdiçam recursos do banco, não tratam situações de erro (como quando o banco as fechou), não funcionam bem com múltiplas threads. Não constitui boa prática de desenvolvimento manter recursos ociosos abertos. No lugar, use um ConnectionPool, como o Jakarta DBCP ou o C3P0 ou, melhor ainda, use um mapeamento objeto relacional, como o Hibernate. Se precisar de janelas singleton, considere o uso de uma só classe singleton chamada WindowManager, que controle o acesso a instâncias que devem ser compatilhadas, mas não tire a possibilidade de reinstanciar a janela. Lembre-se que variáveis estáticas (inclusive a dos singletons) são as principais fontes de memory leaks e são péssimas em ambientes multi-thread.
-
Lembre-se que o primeiro parâmetro do JOptionPane e do JFileChooser deve ser a janela que está abrindo o OptionPane, e nunca null. O null você só usará em aplicações desktop, quando não houver outras janelas abertas. Normalmente, em aplicações Swing, o valor correto será this. Esquecer desse detalhe irá gerar um comportamento estranho no alt+tab. Não sei porque, mas muitos GUJnautas tem mania de usar null, ignorando o que deveriam ter lido na documentação.
-
No mais, saiba que para obter ajuda para um componente do Swing basta ir no google e digitar “How to <nomeDoComponente>”. Por exemplo, para achar ajuda sobre o JLabel, digite How to JLabel. O link da Oracle com um artigo explicativo e exemplos será exibido entre os primeiros da lista em 99.9% das vezes.
Finalmente, divirta-se. O Swing é muito poderoso. Embora no início ele possa parecer complicado, nunca trabalhei com um pacote tão poderoso de classes quanto ele. Ele é flexível, robusto e fácil de programar.