wpjr2’s Weblog

Artigos e tutoriais úteis

Arquivo para Maio 2nd, 2008

Proposta de Curso de JavaME Avançado

Escrito por wpjr2 em Maio 2, 2008

Desde que lecionei o ultimo curso de JavaME no ano passado (Outubro de 2007), tenho tido o desejo de criar uma segunda parte para este curso, com alguns dos tópicos abaixo. Apesar de ainda não ter tido tempo para trabalhar numa ementa, ainda tenho o desejo de criar este curso, que na minha opinião, seria muito interessante para os desenvolvedores JavaME aqui de BH e tb de regiões próximas.

Tópicos:

- Over the Air e Push Registry
- GCF, Rede (HTTP, sockets, datagramas) Avançado
- Wireless messaging (JSR 120 , 205) Avançado
- PIM/FileConnection API (JSR 75)
- Mobile Media API e a AMS (JSR 135, 234)
- Sun Java Toolkit for CDC
- Ferramentas (Eclipse, EclipseME, Netbeans Mobility Pack)
- SDKs de fabricantes (Nokia, Sony Ericsson, Siemens, etc)
- Emuladores de Palm (Palm OS)
- Web Services (JSR 172), Aplicações JavaEE e JavaME
- Bluetooth API (JSR 82)
- Mobile 3D (JSR 184)
- Gaming API
- Design Patterns em J2ME
- CDC / PBP / FP / AGUI (JSR 209)
- Novas tecnologias (MIDP 3.0, MSA, IMS, etc)
- Ant/Antenna
- J2MEUnit
- SuperWaba
- IBM J9 (CVM para Palm OS)

Enviado em Curso de Programação JavaME | Tagged: , , | Nenhum comentário »

JavaME: Netbeans GameBuilder

Escrito por wpjr2 em Maio 2, 2008

Segue abaixo um link interessante sobre um plugin do Netbeans que
auxilia a construção de jogos em JavaME:

http://wiki.netbeans.org/wiki/view/CreatingJavaMEGamesWithGameBuilder

Enviado em JavaME | Tagged: , | Nenhum comentário »

Macromedia AdobeFlex

Escrito por wpjr2 em Maio 2, 2008

Extraído de: http://www.cfgigolo.com/archives/2005/06/macromedia_flex_interface_e_ex.html

Interface e Experiência

Por Fabio Terracini

O Flash nasceu como uma ferramenta visual, para animações, desenho e afins. Mas lá pela versão 6 a Macromedia incorporou à ele outras capacidades, como a de gerar formulários e se conectar com a camada de negócios (via Flash Remoting ou WebServices). Foi um pequeno passo, mas que já naquele momento propunha uma quebra de um paradgima e uma solução para um problema recorrente, a falta de uma ferramenta para o desenvolvimento de aplicativos na web.

Atualmente é possível desenvolver aplicações somente com o Flash, mas em comparação com o Flex, a produção é mais demorada. Em contra partida, o Flash é bastante poderoso para designers gráficos, e terá mais recursos nesse âmbito na próxima versão.

Perguntaram-me uma vez como os web designers poderiam se adequar ao Flex. Bem, eu não vejo outro jeito, se não os web designers aprenderem como o Flex funciona, quais os recursos que ele oferece em termos de apelo visual (animações, estilos, etc) e desenvolver efetivamente utilizando a ferramenta. E aprender a tecnologia vai de cada um.

Proposta do Macromedia Flex

Macromedia define o Flex como uma solução enterprise para rich internet applications, partindo da premissa que a Internet provê uma boa experiência em busca e navegação – operações essencialmente de leitura através da web. Mas para interações e transações, a Internet, mesmo utilizando o DHTML, ainda contém muitos refreshs, o que consome tempo e potencializa erros dos operadores. A necessidade é de uma inteligência que fica disponível no desktop do cliente e através de múltiplas plataformas.

Macromedia)
Fonte: Macromedia

Com esta necessidades em mente, a Macromedia foca no conceito de aplicações ricas para a internet, utilizando o Flash como meio de distribuição destas aplicações. O benefícios das Rich Internet Applications são, segundo a Macromedia:

• Maior faturamento: Mais transações online são finalizadas devido a velocidades, finalização de tarefa, retorno
• Maior diferenciação: Mais intuitivo, costumizada e fortemente orientada à serviços
• Maior entendimento: Forma de visualização de informações de negócio complexas
• Custo reduzido de suporte: Mais usável + menos erros = menos chamados
• Custo reduzido em recursos eletrônicos: Com um smart cliente, somente dados são trafegados, reduzindo o consumo de banda e fazendo menor uso de processador
• Custos de desenvolvimento reduzido: Construido para aplicação, multi-plataforma, componentes profissionais

Mudança no modelo de construir o visual

Programadores programam, certo? O que fizeram os programadores em Fortran quando surgiu o C? Alguns simplesmente ignoraram, é verdade. Mas a maioria (e que sobreviveu) encarou a novidade como benéfica e foi aprender como funcionava, para continuar a fazer o que já faziam: programar.

E há novidades que não vêm para substituir, mas para complementar, como é o caso do CSS em relação ao HTML. O CSS veio para ajudar a separar o visual do conteúdo, e o fez de forma bastante interessante, inclusive evoluindo quando chegou o XML.

Os web designers que trabalharam com essa tecnologia vão ter que evoluir. Eles vão continuar produzindo o mesmo que sabem produzir – interfaces visuais – mas dessa vez, em um novo modelo, e com uma nova proposta, como visual designers para aplicações. Da mesma maneira que um web designer outrora aprendeu o Photoshop, agora para ser um visual designer de aplicações ele precisa também conhecer o Flex.

Um dos primeiros paradigmas encontrados é o que o designer já conhece de Flash. É um tanto quanto estranho para quem tinha uma timeline, agora ter de realizar as mesmas tarefas programaticamente. Há vantagens em realizar essas tarefas via programação, como facilidade de controle de propriedades, controlar objetos para múltiplos dispositivos (de telas widescreen à dispositivos portáteis), e a integração de diferentes elementos multimídia (Sham Bhanl em seu livro Flash MX Designer’s ActionScript Reference).

A “cara de componentes” também é um fator bastante citado. Uma aplicação não necessariamente precisa ser linda. Ela precisa ser sem dúvida, usável, e o Halo, experience model criado pela Macromedia, facilita bastante esta tarefa. O Halo inclui o conjunto de componentes (inputs de texto, de calendário, tabnavigator, etc) e um skin (um tema visual) padrão, que é a “cara de componente” que os habituados com o Flash chamam. Mas com algumas poucas linhas de CSS já é possível trabalhar bastante o aspecto visual da aplicação, e esse recurso é algo que muitos esquecem. O Flex Style Explorer, da Macromedia Consulting, é uma excelente ferramenta para trabalhar com o CSS e ver o resultado em tempo real.

Um desenvolvedor, mesmo que não foque no visual, já consegue construir uma aplicação bastante elegante e usável (providos pelo Helo), seguindo os princípios do arquiteto de informação. Mas se o visual designer trabalhar no look and feel, com certeza o usuário se sentirá mais a vontade.

Um outro forte paradigma é a programação em si. Como no HTML, há ferramentas capazes de gerar o código através de auxílios visuais (ex: Flex Builder), mas para dominar todo o poder que a linguagem é capaz de oferecer – bem como gerar um código mais eficiente – o usuário terá que fazer programaticamente.

Experiência

Há inúmeras referências sobre experiência, mas há uma pergunta que eu costumeiramente faço nas palestras que já elucida uma boa parte do conceito: Por que as pessoas pagam R$ 2,00 no Fran’s Café por uma xícara de café de R$ 0,50?

A experiência em aplicações é mais do que animações e um look and feel bonitinho, e sim fornecer, utilizando auxílios visuais, usabilidade e facilidade para o usuário completar com êxito as tarefas que precisa.

Uma boa experiência é útil, usável e desejável:

Útil: ajudar os usuários a resolverem problemas importantes de maneira rápida e eficiente, de acordo com as necessidades dos usuários.
Usável: Fácil de aprender e usar, de maneira intuítiva e natural para os usuários, com uma qualidade visual agradável que passa a sensação de alta qualidade.
Desejável: De acordo com os valores e costumes do usuários, dando sensação de controle e liberdade.

O conceito de “useful, usable, desirable” é do livro Creating Breakthrough Products de Jonathan Cagan e Craig M. Vogel.)

Quando tratamos de lojas reais há um custo para o consumidor sair de uma loja e entrar em outra. Mas e quando compra-se pela Internet, qual a dificuldade de sair de um site e entrar em outro? Cada vez mais a experiência é importante, fazendo com que o usuário sinta-se confortável e atraído. E isso cria uma particularidade nas aplicações, afinal, em um site de compras on-line, há concorrentes. Mas em um sistema interno de uma empresa, aquele é meio pelo qual o usuário deve desenvolver a tarefa. Se ele não se sentir confortável com o sistema, ele irá procurar outros meios de realizar sua tarefa (como planilhas Excel, as mais utilizadas), ou pior, não irá fazer o trabalho necessário.

Já ouvi dizeres de que o Flex não foi feito para designers. Mas isso é um pensamento imediatista e precipitada. O Flex pode proporcionar mais do que um simples design. Pode proporcionar uma experiência.

Enviado em JavaEE | Tagged: , , | Nenhum comentário »

Criando Bibliotecas Java

Escrito por wpjr2 em Maio 2, 2008

Java Archive (JAR) é um arquivo compactado usado para distribuir um conjunto de classes Java. É usado para armazenar classes compiladas e metadados associados que podem constituir um programa. As vantagens de se utilizaá-lo incluem:

  • Segurança: arquivos JAR pode ser assinados digitalmente, onde usuários deste arquivo podem liberar permissões de segurança para acessar recursos específicos onde no caso normal não seria possível.
  • Tamanho: como seu conteúdo é zipado (comprimido), a quantidade de bytes para transmitir uma biblioteca é menor do que o conjunto de classes da mesma.
  • Marca (sealing): classes podem ser marcadas para que estas tenham consistência (todas as classes definidas em um JAR devem ser
  • Package Sealing: Packages stored in JAR files can be optionally sealed so that the package can enforce version consistency. Sealing a package within a JAR file means that all classes defined in that package must be found in the same JAR file.
  • Versionamento: um arquivo JAR pode armazenar dados sobre os arquivos que esta contém, como o vendedor, versão, etc.
  • Portabilidade: o mecanismo para gerenciar arquivos JAR é um padrão na plataforma Java pelas suas APIs.

Arquivos jar podem ser criados e extraídos usando o utilitário “jar” da JDK. Ferramentas de compressão (como o Winzip) também podem criar arquivos jar.

Um arquivo jar possui um arquivo manifesto localizado no caminho META-INF/MANIFEST.MF. As entradas do arquivo manifesto determinam como o arquivo jar será usado. Arquivos jar que têm a intenção de serem executáveis (como o *.exe do Windows) terão uma de suas classes especificadas como a classe “principal”. O arquivo manifesto terá uma entrada como:

Main-Class: pacote.MinhaClasse

As aplicações contidas nestes arquivos são tipicamente executadas com um comando similar a:

  • Executando direto do JAR utilizando o manifesto:
java -jar exemplo.jar
  • Executando via classpath:
java -cp exemplo.jar pacote.MinhaClasse

A execução destes aplicativos também pode ser feita automaticamente ao clicar no arquivo JAR, por exemplo o Windows Explorer do MS Windows ou File Explorer de qualquer distribuição do Linux.

Os arquivos jar podem ser “ofuscados” para que o seu conteúdo não seja visível para outras pessoas.

Em Junho de 2005 foi iniciado o JSR 277: Java Module System que pretende criar um sucessor do formato jar. Espera-se que esta evolução esteja disponível já na nova versão do JavaSe 7.0, previsto para 2008.


JAR é também o nome de um programa que cria arquivos diferentes dos criados pelo JAR da Sun Microsystems. É um formato de arquivos comprimidos de proposta geral e sucessor do ARJ.

jar cvfm exemplo.jar manifesto.txt -C classes myclasspath

- c : criar um arquivo JAR
- v : verbose, mostrar detalhes na console do processo de criação do JAR
- f : nome do arquivo JAR
- m : nome do arquivo manifesto
- -C: definição do diretório raiz a ser compactado
- myclasspath: define o classpath das classes a ser considerado na compactação, geralmente o ponto "." é usado.

Enviado em Curso de Programação Java | Tagged: , | Nenhum comentário »

Especificações Java: Introdução ao Java Community Process

Escrito por wpjr2 em Maio 2, 2008

Estarei apresentando neste post a parte introdutória do artigo que escrevi para a revista Mundo Java em Junho de 2006 sobre especificações Java. No momento, tive a oportunidade de trabalhar como o líder de manutenção da JSR 253 (Mobile Telephony API) no JCP pela Siemens/Benq Mobile.

Resumo

Como uma tecnologia Java é criada? Como os padrões, plataformas, perfis e configurações são definidos e quem participa na definição destes padrões? Qual é o processo utilizado e quem é responsável por este processo? Este artigo descreve o Processo da Comunidade Java ou JCP, “Java Community Process”, que gerencia o desenvolvimento comunitário de especificações da tecnologia Java, também apresentando informações de como indivíduos e empresas podem participar na definição de tecnologias através das JSRs.

Introdução

Criado em 1998, o Java Community Process ou (JCP) formaliza a definição de futuras versões e tecnologias da plataforma Java através de um grupo de processos, onde várias entidades podem contribuir e direcionar as chamadas requisições de especificações Java, ou JSRs (Java Specification Requests). O processo envolve a utilização destas JSRs, sendo estas compostas de documentos formais que descrevem especificações e tecnologias propostas para serem adicionadas a plataforma Java. Durante a conceituação de uma JSR, diversas revisões formais e públicas são efetuadas antes desta alcançar o estado de finalizada, sendo votada pelo Comitê Executivo do JCP. O processo JCP em si está definido em uma própria JSR, em 2006 na versão atual 2.6 descrita na JSR 215. Presentemente, existem mais de 300 JSRs sob a direção do processo JCP.

Definições Básicas
Logo abaixo estão algumas definições importantes relacionadas ao JCP:

Java Community Process (JCP): o processo da comunidade Java, formalmente escrito em documentações para o desenvolvimento ou revisão de especificações da tecnologia Java. Este processo é composto de diversos estágios que serão melhor descritos mais adiante neste artigo.

Executive Committee (EC): o Comitê Executivo responsável por direcionar a evolução das tecnologias Java. Diversas corporações, empresas, entidades e membros individuais da comunidade Java fazem parte do comitê. Este é responsável pela aprovação de especificações por pontos chaves do JCP e reconciliar as discrepâncias entre especificações e pacotes de testes. Existem hoje dois grupos de comitês executivos: o comitê SE/EE que gerencia as tecnologias Java na área de desktop PCs e servidores (especificações J2SE e J2EE) e o ME que cuida das tecnologias Java nas áreas de dispositivos embarcados (especificações J2ME). O comitê é composto de dez assentos ratificados, cinco acentos por voto e, obviamente um assento permanente para a Sun Microsystems, cada membro servindo em termos de três anos. Os termos de três anos são gerenciados de uma forma tal que cinco dos quinze assentos são normalmente disponibilizados para candidatos a cada ano.Cada comitê é responsável por:

  • Selecionar JSRs para o desenvolvimento dentro do JCP;
  • Prover a aprovação de especificações em rascunho (“draft”) para a revisão pública
  • Prover a aprovação final a especificações completadas e seus associados RIs e TCKs;
  • Revisar as revisões de manutenção que possivelmente podem acarretar a criação de novas JSRs;
  • Aprovar a transferência de responsabilidades entre membros do JCP;
  • Prover auxílio ao escritório de gerenciamento de projetos do JCP (Program Management Office ou PMO);

JCP Member: membro do JCP, sendo este uma empresa, organização ou indivíduo que tenha assinado o acordo JSPA, concordando com seus termos.

Java Specification Participation Agreement (JSPA): acordo anual e renovável entre a Sun Microsystems e uma empresa, organização ou indivíduo que permite a esta entidade a participar do JCP. A participação envolve um custo de US $ 5,000.00 para entidades empresariais, US$ 2,000.00 para entidades filantrópicas e gratuitamente para indivíduos. A participação como entidade empresarial possui a vantagem da possibilidade de qualquer membro da empresa participar do JCP.

Individual Expert Participation Agreement (IEPA): acordo entre a Sun Microsystems e um indivíduo que permite este a servir no grupo de especialistas (Expert Group) ao convite de um líder de especificação (Spec leader). Este acordo permite a participação de técnicos especialistas que não representam nenhuma empresa ou organização para participar do grupo de especialistas.

Program Management Office (PMO): grupo interno da Sun Microsystems responsável por administrar o JCP e o Comitê Executivo.

Expert Group (EG): grupo de especialistas, compondo empresas, organizações e indivíduos escolhidos pelo líder de especificação para auxiliá-lo no desenvolvimento de uma especificação Java através de revisões, sugestões, etc. Este grupo é gerenciado pelo líder de especificação.

Expert: um membro representativo ou indivíduo (com o IEPA assinado) que possui conhecimentos/expertise e praticador ativo da tecnologia envolvida pela JSR.

Supporting Members: membros do Comitê Executivo contatados pelo líder de especificação, incluindo os responsáveis que apóiam um pedido de criação de uma especificação Java.

Java Specification (Specification): uma especificação descrevendo algum aspecto da tecnologia Java, que inclui a linguagem, máquinas virtuais, edições de plataformas, perfis, e interfaces de programação para aplicativos (Application Programming Interfaces ou APIs).

Java Specification Request (JSR): documento submetido ao PMO por um ou mais membros do JCP propondo o desenvolvimento de uma nova especificação ou uma revisão significativa a uma especificação existente.

Umbrella Java Specification Request (UJSR): uma JSR que define ou propõe uma revisão especificamente de uma edição de plataforma ou especificação de perfil. O processo de evolução deste tipo de especificação é feito da mesma forma do que qualquer outra JSR. Um exemplo inclui a JSR 270 (JavaSE 6.0).

Specification Lead (Spec Lead): líder de especificação, responsável pelo gerenciamento do desenvolvimento da mesma através do JCP. O líder é o especialista com a responsabilidade de direcionar o desenvolvimento ou revisões de uma especificação e completar todos os requisitos necessários para a completude da especificação que incluem a RI e o TCK. O líder de especificação (ou empresa/organização sendo representada) precisa ser membro do JCP.

Maintenance Lead: líder de manutenção, responsável pela manutenção de uma determinada especificação Java após esta ser finalizada, assumindo a responsabilidade da especificação, RI e TCK, e das revisões significativas da especificação.

Platform Edition Specification (Platform Edition): uma tipo de especificação que define uma API de infra-estrutura que provê uma base para aplicativos, outras APIs e configurações a serem construídas. Presentemente no Java, existem três especificações de edições de plataformas: JavaSE, JavaEE e JavaME.

Profile Specification (Profile): um tipo de especificação que referencia uma das especificações de edições de plataformas a zero ou mais especificações do JCP que ainda não fazem parte da especificação de edição da plataforma. As bibliotecas ou APIs referenciadas na edição de plataforma devem ser incluídas de acordo com as regras de referencia definidas pela especificação da plataforma. Outros tipos de especificações precisam ser referenciados em sua totalidade.

Reference Implementation (RI): a implementação de referência, protótipo ou prova de conceito de uma especificação.

Test Compatibility Kit (TCK): o conjunto de testes, ferramentas e documentação que permite uma organização determinar se sua implementação está de acordo com a especificação de uma API ou tecnologia Java.

JCP Web Site: o sítio na Web onde se podem obter informações sobre as atividades do JCP, abaixar especificações em rascunho e finais, e acompanhar o progresso das especificações pelo JCP. O site provê ferramentas de auxílio para o líder de especificação, tais como a página da comunidade, provendo atualizações da especificação e tópicos sendo discutidos dentro do grupo de especialistas. Um “alias” também é disponibilizado para que o líder possa gerenciar a informação entre os membros interessados sobre o progresso e assuntos relacionados na especificação.

JCP Specification Page (Spec Page): página no sítio do JCP onde cada especificação aprovada para desenvolvimento ou revisão pode ser acessada, contendo o histórico da passagem da especificação pelo JCP, incluindo um registro de decisões, ações, e votos efetuados pelo Comitê Executivo relacionados à especificação.

Enviado em Curso de Programação Java | Tagged: , , | Nenhum comentário »