Tag: Java

Programe para Android no próprio Android

O AIDE é um aplicativo que permite programar em Java para Android diretamente no dispositivo. Esse app é um ambiente de desenvolvimento com os elementos padrões da SDK do Android e é compatível com os projetos gerados no Eclipse. Além de ter um editor otimizado para tablets e smartphones, ele compila seu código gerando um APK que é instalado e executado no mesmo aparelho.

AIDE rodando em tablet

Eu testei em um smartphone Android e realmente funciona. A interface é muito legal e o editor bem completo, mas confesso que é um pouco chato de usar o celular pra isso. Com certeza em tablets deve ficar bem melhor e aí sim vale a pena usar esse IDE. O vídeo abaixo mostra a aplicação rodando em um Galaxy S2:

 

Se você quiser testar a AIDE, baixe no Android Market Google Play gratuitamente. Lá também tem mais imagens e detalhes do aplicativo.

Mock de métodos estáticos em Java

Logo PowerMock

A utilização de métodos estáticos, na maioria dos casos, deve ser evitada por dificultar os testes unitários e criar um alto acoplamento. Mas se você se deparar com um método estático e tiver que sobrescrever seu comportamento para implementar testes unitários utilizando a técnica Mock Objects, indico a ferramenta PowerMock.

Esse framework permite a criação de mocks de métodos marcados com static ou até mesmo final. O PowerMock é utilizado como uma extensão de outras ferramentas de mock, como o EasyMock e o Mockito.

Exemplo

O trecho de código abaixo retirado deste exemplo, demonstra como utilizar o PowerMock com o EasyMock:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import org.powermock.reflect.Whitebox;
import samples.singleton.StaticService;

import static org.easymock.EasyMock.expect;
import static org.junit.Assert.*;
import static org.powermock.api.easymock.PowerMock.*;

@RunWith(PowerMockRunner.class)
@PrepareForTest( { StaticService.class })
public class MockStaticTest {

 @Test
 public void testMockStatic() throws Exception {
  mockStatic(StaticService.class);
  String expected = "Hello altered World";
  expect(StaticService.say("hello")).andReturn("Hello altered World");
  replay(StaticService.class);

  String actual = StaticService.say("hello");

  verify(StaticService.class);
  assertEquals("Expected and actual did not match", expected, actual);
 }
}

O método estático a ser “mockado” é o say da classe StaticService. Suponha que a implementação deste método retorna “Hello World”. O objetivo deste código de exemplo é sobrescrever o comportamento de say para retornar “Hello altered World” quando recebe “hello” como parâmetro.

A linha 12 define o runner do PowerMock para o JUnit 4 e a linha 13 informa quais as classes que devem ser preparadas para o teste. Entre as linhas 18 e 21 é definido o comportamento esperado para o metodo say, que é retornar “Hello altered World” quando receber “hello” como parâmetro. O método say é chamado na linha 23 e retornará o valor definido, o que é verificado nas linhas 25 e 26.

A utilização do PowerMock é praticamente igual à do EasyMock padrão, com excessão do runner, da annotation @PrepareForTest e da chamada do método mockStatic.

Por que eu preciso disso?

Um caso em que o PowerMock ajuda muito é quando foi utilizado o design pattern Singleton ou um Factory Method estático. Por exemplo, no código a seguir é chamado o método getInstance de ServicoAutenticacao.

public class LoginController {

 public void realizarLogin(String login, String senha) throws LoginInvalidoException {
  ServicoAutenticacao servicoAutenticacao = ServicoAutenticacao.getInstance();

  //faz algo...
 }
}

O problema é que para realizar os testes unitários você não deve utilizar a implementação real deste serviço, já que ele pode depender de recursos (banco de dados, LDAP, etc.) e é necessário sobrescrever seu comportamento para os testes. Com o PowerMock você sobrescreve o método estático para retornar uma implementação fake do serviço ou um mock object.

O ideal neste caso seria substituir o método estático por uma Injeção de Dependência, porém isso não é possível se você estiver utilizando uma API ou framework que tenha uma chamada desse tipo.

Instalação

A página Getting Started da wiki do projeto explica como adicionar a biblioteca em seu projeto, utilizando o Maven ou não.

Referências

BDD em aplicações web – JM 98

Capa Java Magazine 98Foi publicado na Java Magazine 98 meu artigo BDD em aplicações web na seção Engenharia de Software. Neste artigo escrevo sobre a utilização da metodologia BDD (Behavior Driven Development) para o desenvolvimento de aplicações web com as ferramentas JBehave e Selenium.

Para quem não conhece, o BDD descreve os comportamentos do sistema em uma linguagem compreendida por todos os envolvidos do projeto (cliente, desenvolvedores, equipe de QA, etc.) e possibilita automatizar os testes de aceitação em aplicações web. Considerada por muitos a evolução do TDD (Test Driven Development), essa metologia é útil para equipes que utilizam metodologias ágeis no desenvolvimento de aplicações web.

Se você ainda não conhece essa metodologia ou ainda não aplicou ela integrada com o Selenium, dê uma conferida no meu artigo. Aguardo seu feedback :)

Leia o artigo na versão digital da revista

Agradeço ao Eduardo Spínola pelo convite para escrever na Java Magazine.

 

Desenvolvedor no controle utilizando TDD #soudevcon

Palestrei na primeira edição da #soudevcon falando sobre TDD. Para quem quiser dar uma olhada novamente nos slides e no código-fonte, disponibilizei eles no SlideShare e no github.

Atualizado em 19/10: A gravação da palestra agora também está disponível.

Slides da palestra:

Código-fonte: 
https://github.com/victorserta/exemplostdd/tree/master/controle_estoque_soudevcon

Gravação:
Clique para assistir
Player Adobe Connect

Curtiu a palestra ou tem alguma dúvida? Deixe seu comentário aqui e compartilhe no twitter. :)

Agradeço o feedback do pessoal no twitter após a palestra:

@jandersonfc: “excelente palestra so @victorserta sobre #tdd no #soudevcon #soudev … parabéns brother”

@diogorosanelli: “Palestra do Victor Serta sobre #TDD show de bola no #soudevcon Parabéns ! 8)”

@gilmarpalega: “Nota 10 para a palestra #TDD do @victorserta no #soudevcon #soudev”

@lincolnpomper: “Peguei só o final da palestra sobre #TDD do @victorserta no #soudevcon mas parece que foi ótima como sempre.

Hashtags: #soudev #soudevcon #tdd

Injeção de Dependência em Java

Injeção de dependência (Depedency Injection ou apenas DI) é um design pattern utilizado para manter o acoplamento fraco entre classes ou módulos do sistema. O foco principal é fazer com que uma classe não tenha conhecimento de como instanciar um objeto de um tipo do qual é dependente.

Inject Coffee - Injeção Dependência em Java

Neste post vou apresentar as principais ferramentas utilizadas com essa finalidade em Java, mas antes uma explicação inicial sobre o assunto. Dê uma olhada no código Java abaixo:

Continue reading »

Annotation com atributo “default null” funciona?

As annotations podem ter atributos que são obrigatórios ou opcionais, sendo que os opcionais a linguagem exige que se defina um valor padrão. Para deixar um atributo que não  seja primitivo como opcional, nada mais óbvio do que definí-lo com “default null”, certo? Mas será que isso funciona?
Arroba Annotation
O exemplo abaixo apresenta como deixamos atributos da annotation com valores padrões:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD})
public @interface GuardarLogAlteracao {
   String value() default "";
   boolean exibirValor() default true;
}
Observe que “value” possui como valor padrão uma string vazia e “exibirValor” possui “true”. Essa annotation poderia ser utilizado como  o seguinte exemplo:
public class Usuario {
   @GuardarLogAlteracao("Nome do usuário")
   private String nome;

   @GuardarLogAlteracao(value = "Senha", exibirValor = false)
   private String senha;

   //getters e setters...
}
Para “nome” o atributo “exibirValor” será “true”. Voltando a questão principal, se adicionarmos um atributo que seja um objeto, poderíamos definí-lo como nulo por padrão como abaixo:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD})
public @interface GuardarLogAlteracao {
   String value() default "";
   boolean exibirValor() default true;
   Class<? extends FormatadorLog> formatador() default null;
}
Então utilizaríamos a annotation dessa forma, onde por padrão “formator” é nulo para “nome” e “senha”:
public class Usuario {
   @GuardarLogAlteracao("Nome do usuário")
   private String nome;

   @GuardarLogAlteracao(value = "Senha", exibirValor = false)
   private String senha;

   @GuardarLogAlteracao(formatador = FormatadorData.class)
   private Date dataAlteracao;

   //getters e setters...
}
Aí vem o problema: isso não compila. O erro retornado pelo compilador é “The value for annotation attribute GuardarLogAlteracao.formatador must be a class literal“.
O motivo disso é que o compilador bloqueia valores nulos para os campos das annotations para evitar o uso incorreto como “@GuardarLogAlteracao(value = null)“. Isso facilita para quem for implementar o código que tratará a annotation, pois não será necessário validar se os campos possuem valor diferente de nulo e lançar NullPointerException.  Na JSR-308 existe um texto que diz respeito a essa questão.
Para contornar essa limitação encontrei algumas pessoas que utilizaram formas altenativas (pra não chamar de “xunxo” ou “gambiarra”) como esta:
public @interface Optional {
public String value() default NULL;
   public static final NULL = "THIS IS A SPECIAL NULL VALUE" +
      "- DO NOT USE";
}
Pessoalmente eu não gosto desse tipo de solução. Minha sugestão é tentar remodelar a idéia inicial, por exemplo, separando o atributo opcional em outra annotation:
public class Usuario {
   @GuardarLogAlteracao("Nome do usuário")
   private String nome;

   @GuardarLogAlteracao(value = "Senha", exibirValor = false)
   private String senha;

   @GuardarLogAlteracao("Data de Alteração")
   @FormatadorLog(FormatadorData.class)
   private Date dataAlteracao;

   //getters e setters...
}
Apesar de ser necessário mais uma annotation, essa seria uma solução mais elegante para o problema. E você, tem outra sugestão?

Code Bubbles: Uma IDE inovadora

Sendo você um desenvolvedor que utiliza um simples editor de texto ou uma IDE gráfica com milhares de botões e janelas, sabe que às vezes é confuso ficar navegando e trabalhando com vários arquivos abertos apenas para utilizar uma parte do código deles.

Pensando nisso, pesquisadores da Brown University e da University of Central Florida estão desenvolvendo um projeto chamado Code Bubbles. A idéia dessa IDE baseada no Eclipse é, ao invés de abrir arquivos inteiros, visualizar fragmentos de código como ”bolhas” que se relacionam.

Veja o vídeo que é mais fácil de entender:

 

Achei uma visão bem inovadora e diferente das atuais IDEs. Se realmente ajuda no desenvolvimento, só podemos saber na prática.

No site do projeto dá para se registrar para ser notificado quando a versão beta for lançada.

Temas de cores no Eclipse

Uns dias atrás, cansado do “fundo branco“, resolvi trocar as cores do editor do Eclipse. Imaginei que eu iria encontrar combinações de cores pré-configuradas, mas para minha surpresa eu teria que definir uma a uma na mão.

UPDATE (14/02/2012): Recentemente foi criado um plugin para o Eclipse que já faz isso. Recomendo dar uma olhada nele ao invés de usar esses procedimentos, apesar de funcionar também.

Pesquisando um pouco na internet encontrei essa solução. Apesar de não se tratar de um suporte “nativo” a temas, é bem simples.

O Eclipse salva as cores do editor nesses 2 arquivos localizados em .metadata/.plugins/org.eclipse.core.runtime/.settings dentro do seu workspace:

  • org.eclipse.jdt.ui.prefs
  • org.eclipse.ui.editors.prefs

Basta substituir esses arquivos pelos do “tema” que você deseja utilizar. Naquele link que encontrei sobre isso, tem algumas combinações de cores muito legais:

Baixar temas

Baixar temas

Se você gosta de programar com “fundo preto“, é só escolher um desses temas e usar no seu Eclipse. Apenas lembre-se de fazer o backup dos arquivos originais.

Rodando o Google Android em x86

Originalmente o sistema operacional Android tinha como objetivo (pelo menos oficialmente) de ser utilizado em telefones celulares. Com o mercado crescente dos netbooks, muito tem se falado da possibilidade de rodar esse sistema em computadores pessoais.  Lendo essa notícia fiquei sabendo do projeto LiveAndroid, que tem como objetivo disponibilizar uma versão do Android que rode em computadores x86 sem precisar instalar nada. Apesar de eu já conhecer o sistema através do emulador disponibilizado na SDK, resolvi baixar a imagem de CD e testar em meu computador.

Continue reading »

Instalando o JBoss Tools 3 no Eclipse 3.4/3.5

O Jboss Tools é um conjunto de plugins que facilita a vida de quem trabalha com Seam, JSF, (X)HTML, Hibernate, JBoss AS, Drools, jBPM, entre outros. A versão estável do JBoss Tools 3 foi lançada essa semana e é necessária para quem quer utilizar estes plugins no Eclipse 3.4 (ou 3.5)¹, já que as versões 2.x rodam somente no 3.3 ou inferior.

É importante notar que antes você precisa ter instalado os plugins padrões para Java EE no Eclipse, caso não tenha baixe a versão “Eclipse 3.5 IDE for Java EE Developers”¹ aqui.

A instalação do JBoss Tools é muito simples e pode ser realizada pelo próprio update do Eclipse. Bem, vamos lá:

Eclipse Galileo 3.5¹

  1. Vá em “Help” e “Install New Software…”
  2. Clique em “Add…” para adicionar um novo site
  3. Na tela coloque em “JBoss Tools” (ou outro nome que preferir) e “http://download.jboss.org/jbosstools/updates/development” na url e clique em “OK”
  4. Expanda esse novo site, vá em “JBoss Tools 3.1.0 …” e selecione os plugins que deseja instalar
  5. Clique em “Next” e siga os procedimentos
Instalação do Jboss Tools 3 no Eclipse 3.5

Instalação do Jboss Tools 3 no Eclipse 3.5

Eclipse Ganymede 3.4

  1. Vá em “Help” e “Software Updates…”
  2. Na aba “Available Software” clique em “Add Site…”
  3. Coloque a url “http://download.jboss.org/jbosstools/updates/development” e clique em “OK”
  4. Expanda esse novo site, vá em “JBoss Tools 3.0.0 …” e selecione os plugins que deseja instalar
  5. Clique em “Install…” e siga os procedimentos

Instalação do JBoss Tools 3

As imagens abaixo mostram os plugins Seam Tools (com editor visual de JSF/XHTML aberto) e Hibernate Tools funcionando:

Seam Tools

Hibernate Tools


Mais informações em: http://www.jboss.org/tools

Post do Camilo Lopes com vídeo do processo de instalação: http://blog.camilolopes.com.br/?p=1177

¹Atualização em 10/08/2009: Adicionei os procedimentos para a instalação no Eclipse 3.5 / Galileo