Integrando o Eclipse ao Team Foundation Server

Postado 19 de março de 2012 por Paulo Morandi

Introdução

Durante o desenvolvimento de um projeto pessoal, fui apresentado a um plugin para o Eclipse que me chamou a atenção. Percebi então, que este plugin na verdade poderia ser a solução de alguns problemas de Gerência de Configuração, como a padronização de processos de release de produtos. Resolvi trazê-lo para o conhecimento de todos através deste post. Este plugin que é pouco comentado no mercado, pode ser de grande utilidade para empresas que já possuem um Team Foundation Server (TFS) instalado (como é o caso da Mobiltec). Por mais que o SVN, Git e CVS sejam bons softwares de gestão de códigos fonte, é difícil para qualquer empresa ter que controlar diferentes tipos de servidores e ter que gerenciar diferentes tipos de releases de seus softwares. O ideal seria utilizar apenas um deles e unificar essa gestão. Pois bem, se a sua empresa já trabalha com o TFS e possui outros projetos em Java, o Team Explorer Everywhere 2010 (TEE) pode ser uma solução para unificar todos os processos da Gerência de configuração, centralizando tudo dentro do TFS. O TEE era de propriedade da empresa Teamprise que foi comprada pela Microsoft. Quem já possui uma subscription da MSDN, provavelmente tem direitos a este software e nunca ficou sabendo para que ele serve. Com este plugin, é possível integrar todas as funcionalidades do TFS no Eclipse, inclusive checkins vinculados a itens cadastrados no portal do TFS. É possível também controlar bugs, issues, etc., através deste plugin. Este plugin irá ajudar a Mobiltec em sua Gerência de Configuração, padronizando todos os projetos que são desenvolvidos em Java e C#, facilitando, assim a gerência dos projetos. O objetivo deste post será mostrar a instalação e demonstrar alguns recursos interessantes dessa ferramenta de integração, que auxiliam na gestão do desenvolvimento.

Instalação
Depois desta introdução é hora de por a mão na massa. O Team Explorer Everywhere 2010 SP1 está disponível para download aqui. O TEE SP1 é compatível com as versões 2005, 2008 e 2010 do TFS. É necessário ter o Eclipse, ou o IBM Rational Application Developer, ou ainda qualquer IDE baseado no Eclipse como o Aptana Studio e Adobe Flash Builder.

A instalação utilizada como exemplo será a do Eclipse, que é a ferramenta padrão de desenvolvimento Java aqui na Mobiltec. Para iniciar a instalação, baixe o arquivo zip TFSEclipsePlugin, usaremos ele mais adiante. O outro arquivo, TEE-CLC, é um cliente para acessar o TFS via linha de comando. Este cliente é cross-platform, ou seja, pode ser usado em qualquer sistema operacional, desde que suportado pelo programa. Não utilizaremos esse TEE-CLC, apenas o TFSEclipsePlugin. Depois do download concluído, no Eclipse, vá em Help e depois em Install New Software, conforme figura abaixo:

Na tela seguinte vá em Add e depois em Archive e selecione o zip baixado anteriormente. Em Name, pode ser colocado qualquer coisa (recomendação da Microsoft: Local Team Explorer plug-in archive). Feito isso, deverá aparecer o Plugin listado conforme a figura abaixo:

Marque o checkbox e clique em Next e novamente em Next. Aceite os termos da licença, e finalize. O plugin será instalado e será necessário reiniciar o Eclipse.

Utilizando o TFS Exploring

Depois que o Eclipse é reiniciado, para iniciar o cliente do TFS, vá em Window e depois em Open Perspective escolha Other. Irá aparecer uma lista de Perspectives parecida com a figura abaixo:

Selecione a perspectiva Team Foundation Server Exploring. Este é o plugin para o Eclipse do TFS. Na visualização padrão, a esquerda é apresentado o servidor do TFS, e logo abaixo uma janela contendo os checkins pendentes. Outras janelas, como o History (histórico de alterações) podem ser encontradas em Window, Show View e depois em Other.

Para se conectar à um servidor TFS, utilize o botão abaixo da janela Team Explorer:

Irá aparecer uma janela mostrando os termos da licença, e antes de continuarmos, uma palavrinha sobre a licença.

Você poderá utilizar o TEE completo por 30 dias. Para trocar a licença do TEE, no Eclipse, vá em Window, Preferences e procure pelo caminho conforme a figura abaixo:

Retomando, após aceitar os termos da licença, irá aparecer uma tela para adicionar um servidor TFS. Preencha os campos com as informações necessárias para se conectar ao seu servidor TFS.

Principais Recursos

Abaixo uma lista dos principais recursos desse plugin.

Source Control

Com o Source Control é possível explorar as soluções e os códigos fontes que estão no TFS. É possível visualizar históricos, realizar branches, merges, etc.

Work Items

Podemos criar e consultar Work Items do projeto. Um Work Item pode ser um bug, uma issue ou mesmo uma tarefa que precisa ser realizada.

Synchronize

Perspectiva que mostra as diferenças entre os fontes que estão na máquina do desenvolvedor e no servidor. Para abrir essa perspectiva, clique com o botão direito no projeto, depois em Team e Synchronize.

Vinculando Check-ins a Work Items

Observe por esta imagem que podemos procurar por Work Items para que este possa ser vinculado ao check-in que o programador estiver fazendo. Assim fica fácil rastrear as correções de bugs e implementações de tarefas.

Conclusões

Observamos que a integração deste plugin com o TFS foi bem sucedida e este atendeu todas as expectativas. Com certeza será de grande utilidade nos projetos desenvolvidos para Android e J2EE. Agora falta descobrirmos uma integração entre o XCode e o TFS. Alguém tem uma sugestão? Bom, acho que isto é assunto para um futuro post. Até mais!

Escrito por Paulo Sérgio Morandi

Desenvolvimento Mobile na Plataforma Java ME

Postado 26 de dezembro de 2011 por Paulo Morandi

Introdução

Perdido no meio da explosão dos smartphones, o J2ME parece ainda ter fôlego em algumas empresas. Recentemente, foi solicitado a Mobiltec que fosse desenvolvido um cliente J2ME para nosso produto M3. Vocês podem estar se perguntando: porque uma empresa investiria ainda em J2ME? A resposta é simples: custo. Os smartphones mais recentes tem um custo elevado e uma sofisticação que muitas vezes não é necessária para algumas empresas. O objetivo deste post, seguindo a proposta dos outros posts introdutórios, é conhecer algumas definições do J2ME e capacitar o leitor a começar o desenvolvimento nesta plataforma. Futuramente mostraremos como funciona a construção de interfaces e também comentaremos um pouco sobre segurança.

Conceitos

Antes de por a mão na massa, devemos entender do que se trata o J2ME. Primeiro, devemos salientar que o termo J2ME não é mais usado pela Oracle, que trata agora apenas de Java ME. O Java Micro Edition, é um conjunto de tecnologias e especificações desenvolvidas para trabalhar com as restrições impostas por dispositivos de baixa capacidade (memória, display, bateria, etc).

Existem dois tipos de configurações especificadas pelo Java ME: CDC e CLDC. Connected Device Configuration (CDC) são especificações para dispositivos do tipo PDA ou setup boxes. Já o Connected Limited Device Configuration (CLDC) são especificações para dispositivos móveis do tipo celular (com mais restrições em termos de hardware que um PDA).

Se um dispositivo é compatível com Java ME, ele precisa necessariamente implementar um profile, que é um subconjunto das especificações de uma das configurações acima. Para o CLDC existem o MIDP (Mobile Information Device Profile) e o IDP (Information Device Profile). Para o CDC existe o FP (Foundation Profile) e o PBP (Personal Basis Profile). Não entraremos em mais detalhes, se quiser saber mais veja aqui.

Neste post (e nos próximos) o foco será no profile MIDP versão 2.0 ou superior.

Pré-Requisitos para o Desenvolvimento

Assim como no Android, não há nenhum custo para iniciar o desenvolvimento em Java ME. Tanto o SDK, quanto as IDEs que trabalham com Java ME são livres para serem baixadas e utilizadas. Primeiro passo é ter o Java SE SDK instalado em seu computador, para isso baixe a última versão do site da Oracle. O SDK do Java é o pré-requisito para a próxima ferramenta: Netbeans. Usaremos como exemplo o Netbeans pois ele já vem com o Java ME integrado e pronto para uso, diferente do Eclipse que necessita de um setup inicial. Na versão anterior do Eclipse (Helios), existia uma integração no projeto chamado Eclipse Pulsar, que era uma IDE especial para o desenvolvimento de aplicativos móveis. Mas na versão mais recente (Indigo), até o presente momento, esse projeto Pulsar não existe mais.

Infelizmente tem que ser a versão mais completa do Netbeans (em torno de 245 Mb), pois conforme a tabela abaixo é a única que tem suporte ao Java ME.

: Versões Netbeans

Depois do Netbeans instalado certifique-se que o plugin do Java ME está ativado. No menu Ferramentas, escolha a opção Plug-ins:

: Seleção de plug-ins

Veja na figura abaixo como deve estar a opção do Java ME:

: Ativação do Java ME

Pronto, estamos aptos para iniciar um projeto Java ME.

Desenvolvimento

O Java ME é basicamente um subconjunto, bem mais restrito, do Java SE. Isso é natural, uma vez que foi feito para ser utilizado em dispositivos com baixa capacidade de processador e memória. Como exemplo dessa restrição podemos citar o acesso a arquivos. No Java SE existe um pacote (package) chamado java.io que possui uma classe chamada File responsável por manipular arquivos. No Java ME (lembrando que estamos falando de MIDP 2.0 ou superior) não existe esse conceito de arquivo. Existe uma classe responsável por criar uma conexão com um recurso chamada Connector. Essa classe serve tanto para criar uma conexão HTTP, quanto para abrir e manipular um arquivo. Através dela informamos qual o recurso desejado e recebemos de volta uma interface chamada Connection. Onde podemos ler e escrever os bytes desse recurso que foi aberto. Mais informações sobre esta classe pode ser encontrada aqui.

Muitas vezes encontramos uma biblioteca Java SE que gostaríamos de utilizar no Java ME, mas infelizmente, isso, na maioria das vezes, não vai funcionar. Mas nem tudo está perdido! Existe uma chance (pequena, mas existe!) de sucesso se a biblioteca for open source e tenha sido feita puramente em Java (sem mais dependências). Assim é possível tentar alterar o código fonte da biblioteca para usar os recursos do Java ME (como trocar a classe File pela Connector). Nessas horas sempre é bom procurar por aí por alguém que já tenha feito este trabalho.

Um programa feito em Java ME possui uma classe chamada Midlet, que é responsável por gerenciar o ciclo de vida da aplicação. Os três principais métodos dessa classe são:

startApp: Chamado quando o usuário seleciona a aplicação no menu de aplicações.
pauseApp: Chamado quando o usuário do telefone recebe uma ligação por exemplo.
destroyApp: É a sinalização que a aplicação deve ser encerrada.

A documentação da API do Java ME (MIDP 2.0) com os métodos disponíveis está aqui.

No próximo post falaremos mais sobre a estrutura de interfaces (Midlet) de um projeto Java ME e mostraremos como funciona a navegação entre os forms de uma aplicação.

Distribuição de Aplicativos

Diferentemente do Android, Windows Phone e iOS, não existe uma “Java ME Store” controlada pela Oracle. A Oracle apenas fornece a documentação, suporte e treinamento em Java ME, bem como é a responsável por definir os rumos futuros da plataforma. Algumas empresas, como a Nokia, possuem uma loja própria onde é vendido/distribuído seus aplicativos desenvolvidos em Java ME (ou em alguma linguagem nativa, no caso da Nokia, C++). Lojas próprias não são algo tão incomum assim. Com o Android, por exemplo, temos grandes empresas como Samsung, Amazon e Barnes & Noble que possuem sua própria forma de licenciar e distribuir aplicativos para Android.

Frameworks

E antes do apagar das luzes, uma última informação sobre outros frameworks Java ME. As vezes temos que utilizar um framework Java ME que não o default da plataforma, para utilizarmos os recursos específicos de uma plataforma, como, por exemplo, uma API de geolocalização. Para instalar outros frameworks no Netbeans, acesse a página do SDK (exemplo: Symbiam SDKs) e instale a partir do menu Ferramentas, opção Plataforma Java, conforme figura abaixo:

: Adicionando frameworks

Conclusão

A Oracle parece ainda não ter desistido do Java ME e continua a atualizar a plataforma. Aparentemente o mercado caminha para termos dispositivos cada vez mais robustos por preços mais acessíveis. Aparentemente somente em países subdesenvolvidos a Nokia continua com sua linha que ainda possui aparelhos compatíveis com Java ME, mas mesmo assim a empresa dá mais ênfase no desenvolvimento utilizando C++ para o seu sistema S40. Mas mesmo a Nokia, que sempre foi uma gigante na telefonia, está aos poucos migrando para o Windows Phone e a tendência é que o Java ME seja deixado de lado e fique talvez mais restrito a sistemas embarcados. Mas conhecimento nunca é demais e nunca sabemos quando teremos que dar manutenção naquele código legado de Java ME, não é mesmo? Até o próximo post!

Escrito por Paulo Sérgio Morandi

Serialização XML em Dispositivos Móveis (Android)

Postado 3 de outubro de 2011 por Paulo Morandi

Durante a realização de um projeto na Mobiltec, nos deparamos com o seguinte desafio: serializar (XML) um objeto em .NET e deserializar o mesmo objeto em um dispositivo Android (Java). No .NET Framework (C#) a operação de serialização é bem trivial, basta executar o seguinte código exemplo:

System.Xml.XmlSerializer xmlSr = new XmlSerializer(typeof(Model));
Model model = new Model();
xmlSr.Serialize(stream, model);

O processo de deserialização é igualmente fácil:

Model udtModel = (Model)xmlSr.Deserialize(stream);

Por exemplo, a seguinte classe Model

using System.Collections.Generic;
public class Model
{
     public bool IsValid { get; set; }
     public int Identifier { get; set; }
     public string SomeText { get; set; }
}

irá gerar esse XML:

<?xml version="1.0" encoding="utf-8"?>
<Model xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <IsValid>false</IsValid>
  <Identifier>134</Identifier>
  <SomeText>text</SomeText>
</Model>

Algumas observações importantes na serialização de objetos em .NET:

Não é necessário nenhuma preparação inicial do objeto a ser serializado (Model)
Não é necessário marcar a classe como serializável (modificador [Serializable])
Todos os atributos que serão serializados devem ser públicos (a classe Model inclusive), senão o método Serialize gera uma exceção (“XMLSerializationTest.Model é inacessível por causa do seu nível de proteção. Apenas tipos públicos podem ser processados.”)

No Android não temos nada que o próprio Framework do Java tenha que seja tão simples quanto o .NET, apenas o básico de leitura de XML está presente. Entretanto, em outros projetos desenvolvidos na Mobiltec utilizando a linguagem Java (mais especificamente J2EE), observamos que existiam algumas bibliotecas que auxiliam na serialização de objetos, similar ao .NET, como o JAXB. Conforme vimos no post sobre desenvolvimento em Android, não é qualquer código em Java que irá funcionar no Android. A bibliteca JAXB poderia ser utilizada, porém estávamos em busca de algo mais leve e encontramos a excelente biblioteca Simple. O jar da biblioteca JAXB tem aproximadamente 10,4 Mb, já a biblioteca Simple tem apenas 360 Kb. Para deserializar o XML gerado anteriormente, utilizando a biblioteca Simple, basta gerar o seguinte código:

import org.simpleframework.xml.Serializer;
import org.simpleframework.xml.core.Persister;

Serializer serializer = new Persister();
Model model = serializer.read(Model.class, source);

Observações importantes da biblioteca Simple:

Os atributos da classe são utilizados para serializar/deserializar o objeto
Ao recriar a classe Model em Java, esta deve ter atributos com o mesmo nome das propriedades do .NET para que a correspondência possa ser feita

O Simple é case sensitive, ou seja, a seguinte classe deve ser definida para que a importação exemplificada neste post funcione:

import org.simpleframework.xml.Default;

@Default
public class Model {

	private boolean IsValid;
	private int Identifier;
	private String SomeText;

        //metodos get/set omitidos
}

Com este dois exemplos observamos uma certa dependência entre as classes Model definidas. Como uma dica de utilização podemos realizar algumas marcações nas duas classes de forma a padronizar o XML gerado, facilitando a importação em qualquer outra plataforma. Em .NET podemos fazer o seguinte com a classe Model:

[XmlRootAttribute("model")]
public class Model
{
    [XmlElement("valid")]
    public bool IsValid { get; set; }

    [XmlElement("identifier")]
    public int Identifier { get; set; }

    [XmlElement("someText")]
    public string SomeText { get; set; }
}

A biblioteca Simple também permite as mesmas marcações:

@Root(name="model")
public class Model {

	@Element(name="valid")
	private boolean valid;

	@Element(name="identifier")
	private int identifier;

	@Element(name="someText")
	private String someText;

        //metodos get/set omitidos propositalmente
}

Era isso por hoje e aguardem em breve mais um post com mais dicas sobre serialização utilizando a biblioteca Simple. Caso tenha ficado curioso sobre a utilização do JAXB, este site mostra uma comparação entre Simple e o JAXB.

Escrito por Paulo Sérgio Morandi