PERES JULIAO CORGOSINHO BRUNO BORGES LEMOS DE OLIVEIRA RAFAEL REIS GOMES

(1)

UNIVERSIDADE PRESIDENTE ANTÔNICO CARLOS – UNIPAC / ARAGUARI

PERES JULIAO CORGOSINHO BRUNO BORGES LEMOS DE OLIVEIRA

RAFAEL REIS GOMES

NETBEANS & SWING

(2)

Netbeans

Nos primórdios da plataforma Java, a Sun fornecia um ambiente de desenvolvimento proprietário chamado Java Workshop, que, entretanto, não conquistou o mercado, deixando espaço para outros IDEs (ambientes integrados de desenvolvimento) como o Visual Café e o JBuider. Enquanto isso, uma empresa desconhecida trazia uma proposta inovadora: construir um IDE visual inteiramente em Java, baseado em componentes JavaBeans, que visualmente imitava o popular Delphi – tanto que chamava-se Xelphi. Lentamente, o Xelphi foi ganhando popularidade, até que a Sun decidiu comprar a empresa para tornar o produto base do seu novo ambiente de desenvolvimento, o Forte.

A aquisição pela Sun trouxe mais mudanças do que apenas o nome: o código-fonte do produto original foi aberto à comunidade, de forma semelhante ao que ocorreria posteriormente com o StarOffice, dando origem ao OpenOffice. A versão livre do IDE foi batizada como NetBeans, e é hoje a base das ferramentas de desenvolvimento Java da Sun.

Recursos

Atualmente na versão 6.9, o NetBeans é rico em recursos, não apenas para a programação visual de aplicações desktop, mas também para o desenvolvimento de aplicações web. Entre as suas várias capacidades podemos citar:

• Execução passo a passo de aplicações Java, Applets, Servlets e JSP; • Suporte a bibliotecas de tags no editor de JSP;

• Editor XML com suporte a DTDs e XML Schemas; • Execução de transformações XSLT;

• Edição de folhas de estilo CSS para documentos HTML e XML;

• Database Explorer, para execução interativa de comandos SQL contra qualquer banco de dados, desde que seja fornecido um driver JDBC; • Suporte nativo ao CVS;

(3)

Além desses recursos, todos presentes na distribuição básica do NetBeans, há vários módulos de expansão (modules) que podem ser baixados do site oficial, www.netbeans.org, como por exemplo a integração a servidores de aplicação de diversos fabricantes.

NetBeans x Eclipse

NetBeans e Eclipse são os dois IDEs livres para Java mais populares, portanto é inevitável fazer uma comparação entre eles. Mais isso não é uma tarefa fácil, pois há diferenças fundamentais nos objetivos e projetos dos dois IDEs: enquanto que o primeiro visa ser uma ferramenta fácil para o iniciante, o segundo é uma plataforma para a construção de outras ferramentas de desenvolvimento.

À primeira vista, o NetBeans parece mais rico, pois o Eclipse não incorpora em sua distribuição padrão (plataforma+JDT) recursos para programação visual, banco de dados, web ou XML. Entretanto, fornece suporte ao JUnit e a práticas de Extreme Programming, como refatoração, ausentes na distribuição padrão do NetBeans. Por outro lado, essa comparação de funcionalidades cai logo por terra, pois ambos os IDEs podem ser estendidos com plug-ins/módulos (livres e proprietários). É possível acrescentar ao Eclipse suporte ao desenvolvimento web, a XML, BDs etc.; ou adicionar ao NetBeans suporte ao JUnit e à refatoração de código.

Para muitos desenvolvedores, a experiência com o Eclipse será mais agradável, pois o uso do SWT no lugar do Swing torna sua interface mais integrada ao ambiente nativo do sistema operacional. No entanto, os plug-ins disponíveis para programação visual no Eclipse ainda estão longe de atingir o nível de qualidade do editor de formulários do NetBeans.

Qualquer que seja a preferência, ambos os IDEs geram código 100% Java, e projetos podem ser migrados sem dificuldade de um para o outro.

Swing

(4)

O pacote AWT (Abstract Windows Toolkit) possui os primeiros componentes gráficos que surgiram no java. Como janelas (Container, Frame, Panel...), alguns botões (Button, RadioButton, CheckBox...), Rótulos (Label), campos de texto (TextField), Listas (Choice, List,...) entre outros componentes. Esses componentes eram muito utilizados quando ainda não existia o pacote Swing. Eles possuem uma aparência mais "padrão", são mais quadrados e não possuem muitos efeitos gráficos.

Componentes Swing

O pacote Swing é uma evolução do pacote AWT. Além de seus próprios componentes, esse pacote possui quase todos os componentes que já existiam no pacote AWT, porém com uma interface gráfica mais evoluída e com maiores efeitos. Os componentes Swing começam com a letra "J", assim um botão que no AWT se denomina Button, no Swing é JButton. Como dito antes, o pacote Swing possui componentes próprios, esses componentes estão entre telas mais aperfeiçoadas (JTabbedPane, JToolBar, JInternalFrame, JColorChooser...), novos botões e campos para dispor as informações na aplicação (JFormattedTextField, JProgressBar, JSpeener, JPasswordField, JTextPane, JTextArea...) e menus (JMenuBar, JMenu...).

Contêiners

JToolBar: A barra de ferramentas é utilizada para criar atalhos da aplicação. Assim como no Eclipse, por exemplo, temos os "play" verde para executar o aplicativo, podemos criar atalhos para nossos programas também.

(5)

JPanel: O painel é um componente utilizado para fazer subdivisões na tela, ou para separar de forma organizada componentes dispostos na tela.

JTabbedPane: O JTabbedPane permite agrupar vários JPanels em um único componente formando uma aba para cada painel.

JSplitPane: O componente é semelhante a um JPanel possuindo dentro dele dois botões que fazem a divisão da tela.

(6)

JScrollPane: O painel de rolagem sempre é utilizado com algum outro componente, normalmente um componente para adicionar textos como o JTextArea (veremos o JTextArea no próximo capítulo). Esse componente adiciona barra de rolagens ao componente que se localiza dentro dele.

JLabel: O JLabel é utilizado para apresentar um texto "fixo" ao usuário. É muito comum utilizar o componente como rótulo para os demais componentes, ou seja, para identificar o que representa cada campo na tela. Pode ser utilizado também como saída de dados, onde o usuário irá visualizar o resultado final de alguma operação. O texto desse componente só pode ser alterado via código.

(7)

JFormattedTextField: O JFormattedTextField é um campo bem semelhante ao JTextField, possuindo as mesmas propriedades e algumas a mais. Ele é utilizado quando o JTextField necessita de algum tipo de formatação, como a “Data”.

JTextArea: O JTextArea é um componente utilizado para a entrada/saída de textos ou frases maiores. Ele permite que seja adicionada mais de uma linha.

JList: A JList é uma lista utilizada normalmente para representar as saídas de um problema ou para listar informações. A JList trabalha com índices, cada linha representa um único índice.

JComboBox: O JComboBox é utilizado como seletor de dados, onde são configurados determinados campos pelo programador e o usuário pode

(8)

escolher um deles. Um exemplo prático seria um campo para escolher o estado, onde o usuário só poderia escolher um dos estados definidos. A caixão de seleção também trabalha com índices.

JSpinner: O JSpinner, semelhante ao JComboBox é utilizado para que o usuário possa selecionar uma informação dentre as pré definidas. O que muda, é que esse componente possui setas para cima e para baixo permitindo a visualização de seu conteúdo.

JButton: O JButton é o componente correspondente ao botão. É utilizado para que seja efetuada alguma tarefa ou função ao ser clicado.

(9)

JRadioButton e JCheckBox: O JRadioButton é um componente utilizado para que o usuário possa selecionar alguma informação definida pelo programador. Normalmente é utilizado em conjunto com outros JRadioButtons, para que o usuário tenha várias opção de seleção. Esse componente, geralmente é utilizado em casos onde o usuário deve selecionar apenas uma das opções disponíveis. O JCheckBox é semelhante ao JRadioButton, porém é utilizado quando o usuário pode, ou não, selecionar várias das opções disponíveis.

JSeparator: O JSeparator é um componente visual utilizado apenas para separar outros componentes, deixando a tela mais organizada. Normalmente é utilizado em menus.

Desenvolvimento Desktop

O desenvolvimento de aplicações para desktop em Java é menos frequente do que para web ou dispositivos móveis. Hoje é possível implantar sistemas escritos em Java em ambientes antes dominados por linguagens nativas, mas, além da concorrência com ambientes RAD e linguagens nativas, o universo Java com suas APIs e jargões muitas vezes espanta quem quer trabalhar com Java nesse segmento.

É inevitável a comparação com ambientes RAD (Rapid Application Development) como VB e Delphi quando se trata de desenvolvimento para desktop. Essas linguagens são muitas vezes o ponto de partida para quem

(10)

trabalha com esse tipo de aplicação. Alguns desenvolvedores, por opção ou oportunidade, tentam também conhecer o que Java oferece nesse segmento. No entanto, o desenvolvimento Java para desktop exige uma curva de aprendizado distinta das tecnologias RAD, e geralmente mais complexa. A complexidade tende a ser maior devido a fatores como:

• Sopa de letrinhas do mundo open source: quem começa a estudar Java para desktop facilmente se depara com Camadas, Padrões de Projeto, Java SE, MVC, Swing, SWT, layout manager, Matisse, JGoodies, JDBC, JPA, Hibernate, etc. e tudo isso pode gerar muita confusão na cabeça do desenvolvedor;

• Opções de utilização de APIs de acordo com as necessidades de cada sistema ou mesmo preferência de cada equipe: Java conta com uma grande comunidade de desenvolvedores e com o apoio de grandes players do mercado de TI. Sendo assim, não existe uma configuração “oficial” e cabe ao desenvolvedor ou à equipe escolherem o que será usado para cada aplicação: API de componentes visuais (Swing ou SWT?), layout managers (usar ou não?), persistência (JDBC, JPA ou Hibernate?);

• Inexistência de um IDE padrão: temos ainda, felizmente, a opção de escolher entre diversos ambientes de desenvolvimento. A escolha nesse caso poderá levar em conta: pago ou gratuito; a API de componentes visuais utilizada na aplicação, pois o IDE escolhido pode ter ou não editor gráfico para as telas criadas utilizando a API; facilidade de configuração, etc.

Enfim, quem conhece pouco ou nada de Java para desktop pode se perder e até mesmo desistir de trabalhar com essa linguagem diante de tantas decisões a serem tomadas já no início do desenvolvimento. Mas, com um guia, um pouco de informação e decisões tomadas nas horas certas, essas opções deixam de ser um bicho de sete cabeças. E é isso que vamos mostrar como dar os primeiros passos no desenvolvimento Java para desktop.

Para mostrar a aplicação dos conceitos e APIs apresentadas, vamos construir gradativamente um programa CRUD (Create, Retrieve, Update e Delete) chamado Agenda de Contatos.

(11)

Divisão em camadas

De acordo com Martin Fowler, em seu livro Patterns of Enterprise Application Architecture, “a divisão em camadas é uma das técnicas mais utilizadas por projetistas de software para ‘quebrar’ aplicações complexas”. O termo quebrar aqui tem o sentido de separar, criar partes e responsabilidades distintas dentro da aplicação. Assim, a complexidade de cada parte é menor que a da aplicação como um todo, o que facilita o desenvolvimento.

As camadas podem ser físicas e lógicas. Em linhas gerais, camadas físicas são aquelas cujas partes são executadas por processos distintos, em máquinas distintas. Já as lógicas são partes de um mesmo processo.

Um exemplo de divisão em camadas físicas é velho conhecido de quem trabalha com aplicações que acessam bancos de dados: a arquitetura cliente/servidor. Uma camada corresponde aos clientes, que podem ser aplicativos rodando em diversas máquinas dentro de uma rede, e com o objetivo principal de fazer a interação com o usuário. Outra camada é o servidor, que tem uma responsabilidade completamente diferente, a de fornecer os dados requisitados pelos clientes, para que esses possam desempenhar seu papel.

Inicialmente, as aplicações eram desenvolvidas sem divisão em camadas. O objetivo de muitos sistemas de informação era apenas registrar e buscar informações em bases de dados, sem grande volume de processamento de regras de negócio. Nesses sistemas, era comum ver os componentes da tela associados diretamente aos campos das tabelas do banco de dados. Mas com

(12)

o aumento da complexidade das aplicações, um problema passou a fazer parte do dia-a-dia dos desenvolvedores: onde e quando processar as regras de negócio? No código da tela, onde já eram tratadas conexões com o banco de dados, e os eventos de interação com o usuário? Não era uma boa opção, principalmente se o processamento da regra de negócio pudesse ser acionado por mais de uma tela ou rotina, o que terminaria em replicação de código, e essa não é uma boa prática de programação.

Surgia então a necessidade de um ponto comum onde essas regras fossem processadas, e criou-se a camada de “lógica de domínio”, ou “lógica de negócio”. O objetivo dessa camada é centralizar o processamento das regras de negócio do sistema e ela deve ser projetada de forma independente das telas, que pertencem agora à camada de “apresentação”. Mas no modelo inicial, sem camadas, as conexões com o banco de dados eram gerenciadas pela própria camada de apresentação. Além disso, os elementos da lógica de negócio também precisam de conexões com o banco. Como a lógica de negócio não deve depender da apresentação, surgiu a necessidade de mais uma camada: a de “acesso a dados”. Essa camada será então responsável por tratar conexões e transações com o banco de dados.

(13)

Funcionamento MVC

Em um projeto de software baseado no padrão MVC, define-se uma arquitetura básica com 3 camadas possivelmente abstratas:

• Model: Implementa o modelo representando a estrutura de baixo nível do projeto, podendo ser o modelo objeto-relacional que implementa a camada de dados, e ou num caso de MVC de Interface poderia guardar informações de estado dos controles;

• Controller: Implementa a camada responsável pelo gerenciamentos de eventos no projeto, tais como cliques do usuário, chamando a camada Model para processar os eventos, também pode manter informações de estado do usuário na aplicação;

• View: Gera a interface com usuário de modo que esta somente requisite o processamento de eventos pelo Controller.

Padrões de projeto

Uma vez explicada a divisão em camadas, vamos para mais um assunto que faz parte do dia-a-dia de quem trabalha com orientação a objetos: os design patterns, ou padrões de projeto. Padrões são soluções genéricas para problemas recorrentes nas atividades do profissional. Eles ajudam os profissionais a comunicar soluções propostas para problemas, pois usam uma linguagem e nomenclatura comuns, além de terem um padrão de documentação. Este modelo de documentação foi proposto inicialmente pelo arquiteto Christopher Alexander, na década de 70.

DAO – Data Access Object

Tem como objetivo encapsular toda a lógica de comunicação com bancos de dados ou qualquer outro mecanismo de persistência.

O padrão DAO é um dos mais fáceis de serem entendidos e aplicados. As classes que o implementam são responsáveis por fazer todo o tratamento de acesso aos dados que são manipulados pelo sistema, mas ficam armazenados fora dele, como em um banco de dados. Logo, o código com instruções SQL não devem aparecer em nenhuma outra classe que não implemente esse padrão. Para começar a utilizar esse padrão, precisamos apenas criar as classes cujos nomes, por convenção, terminam com as letras DAO. Não há

(14)

obrigatoriedade de se implementar nenhuma interface específica, apesar dessa ser uma boa prática de programação orientada a objetos.

(15)

Classe Model

(16)