Desenvolver para Android não é uma tarefa fácil. Hoje existem cerca de 700 dispositivos que rodam Android. Além de rodarem diversas versões do android, eles possuem hardwares, telas e tamanhos diferentes. Uma grande dor de cabeça para o desenvolvedor Android, a conhecida fragmentação da plataforma.

Para facilitar o desenvolvimento e  aliviar a dor de cabeça do desenvolvedor, a plataforma Android desenvolveu uma ferramenta fantástica: o Application Resources.

O Application Resources é muito útil no desenvolvimento de aplicativos que serão usados por diversos dispositivos, principalmente se for no caso para smartphones e tablets.

Fonte: http://developer.android.com/images/resources/resource_devices_diagram2.png

Para se utilizar do Application Resources, basta colocar qualifiers nas pastas de Resources (res/). Quando criamos um projeto Android ele já tem a pasta layout. Se, por exemplo, formos criar layouts diferentes (mais adequados) para dispositivos de telas pequenas, criaremos a pasta layout-small. Nesse caso, small é seu qualifier.

Quando sua aplicação é executada, ela carregará os resources de acordo com os qualifiers do seu dispositivo. Se você não utilizar nenhum qualifier, a aplicação utilizará os resources defaults (sem qualifiers. Ex: layout, values, etc.). Aplicações podem possuir diferentes diretórios para diferentes qualifiers, como a figura mostra:

Se você vai desenvolver sua aplicação para uma grande quantidade de dispositivos, é praticamente obrigatório o uso do Application Resources. Ele vai evitar que você faça arquivos de layouts desnecessários, ou seja, ao invés de ter um arquivo XML dentro da pasta layout para cada tipo de tela, você terá o arquivo com o mesmo nome em uma pasta layout e outro com o conteúdo diferente em layout-small. Com isso você pode aproveitar as capacidades (processamento, qualidade e tamanho de telas) dos dispositivos.

Uma curta aplicação de exemplo está disponível no github. Nela exibimos um texto diferente para cada tipo de dispositivo: dispositivo com telas pequenas, telas médias, telas médias em landscape, telas grandes e telas grandes com versão 14. O Application Resources não serve só para internacionalização, no exemplo a ideia é exibir qual o tipo de tela que o dispositivo tem alterando apenas o conteúdo do arquivo strings.xml de acordo com os qualifiers. Seguindo esta ideia, também podemos utilizar o Application resources principalmente no styles.xml, facilitando trabalhar com os diferentes tipos e orientações de telas.

Uma aplicação que tem muitos detalhes diferentes em dispositivos diferentes pode aparecer com diversos qualifiers grandes, como values-pt-large-v14-land.

Mas tome cuidado, não saia colocando qualifiers em tudo. Antes disso, procure usar o que realmente você vai precisar. Esperamos te encontrar aqui no curso de desenvolvimento para Android!

Um dos mais badalados frameworks de ORM no mundo Java (e popular também no .NET), o Hibernate recentemente ganhou sua versão 4.0 Final, que chega para arrebentar de novidades. O framework surgiu em 2001, por iniciativa de Gavin King, e logo se tornou amplamente utilizado devido a uma grande diversidade de recursos para mapeamento objeto relacional. Com a especificação da JPA (Java Persistence API), solidificou-se como  a implementação mais utilizada. Diversos projetos também passaram a ser desenvolvidos pela equipe do Hibernate a fim de aprimorar os recursos existentes no framework. Muitos deles, em vez de serem anexados ao projeto Core, tornaram-se plugins, tais como Hibernate Search, o Hibernate OGM e o Hibernate Validator. Este último, inclusive, teve fortes influências para a criação de uma nova especificação, a Bean Validation (JSR 303).

A partir da versão 3.5, o Hibernate tornou-se uma implementação certificada para a JPA2 (JSR 317), lançada oficialmente no final de 2009. Várias annotations surgiram e muitos recursos foram aprimorados. Em dezembro de 2011, a versão 4.0 Final veio à tona, trazendo algumas importantes novidades que gostaríamos de destacar:

Redesign da SessionFactory

Possivelmente essa é uma das grandes mudanças no Hibernate 4. Estávamos habituados a obter uma SessionFactory da seguinte forma:

private static final SessionFactory sessionFactory =
    new Configuration().configure().buildSessionFactory();

Entretanto, agora o método buildSessionFactory() está listado como deprecated, bem como as classes de Configuration: org.hibernate.cfg.Configuration e AnnotationConfiguration. A nova forma de se obter uma SessionFactory é através do ServiceRegistry, que explicaremos adiante, lançado para esta versão 4:

ServiceRegistry serviceRegistry = new ServiceRegistryBuilder()
    .configure().buildServiceRegistry();
MetadataSources metadataSources = new MetadataSources(serviceRegistry);
metadataSources.addResource("algum.hbm.xml")
    .addAnnotatedClass(SuaEntidade.class);
Metadata metadata = metadataSources.buildMetadata();
SessionFactory sessionFactory = metadata.buildSessionFactory();

Para que possamos obter uma SessionFactory, precisamos de um ServiceRegistry, seguido de um MetadataSources (eventualmente podemos adicionar recursos, classes anotadas, entre outros, de forma similar ao Configuration); a partir deste obtemos um Metadata e então finalmente conseguimos uma SessionFactory.

Para obter uma EntityManagerFactory nada muda, podemos usufruir da classe javax.persistence.Persistence.

ServiceRegistry

Uma nova forma foi implementada para que o Hibernate gerencie seus serviços. Services são classes que fornecem ao Hibernate diversos tipos de funcionalidades, tais como ClassLoader, conexão com o banco (ConnectionProvider), descoberta de dialetos apropriados, entre outros. Você deve estar se perguntando por que isso é um ponto interessante. O fato chave é que agora todos os serviços possuem uma interface. Caso queira, você pode mudar a forma com que o Hibernate realiza algumas funcionalidades de uma maneira muito simples, apenas fazendo com que suas classes implementem a interface de serviço do Hibernate. É uma forma de desacoplar seu código interno e se tornar mais maleável.

Suporte a Multi-Tenancy

Para que não conhece o termo, aí vai um pequeno resumo – em um modelo multi-tenant, é possível compartilhar os mesmos recursos físicos para clientes/empresas diferentes, mas ao mesmo tempo permite-se que fiquem logicamente isolados. A frase anterior pode parecer abstrata, então imagine diversas aplicações de e-commerce. Muitas delas possuem um core muito similar e diferem apenas em questões de layout e UI. Imagine então que fosse criada uma base de código igual para todas essas lógicas de e-commerce e apenas o design de cada loja diferente fosse mudado; cada uma delas teria seu próprio namespace e um endereço na web; contudo a base de código seria a mesma. Esses websites de lojas de e-commerce seriam cada um, um tenant.

Podemos implementar o Multi-Tenancy de algumas formas: Instâncias de bancos separadas (cada tenant possui sua prórpia instância de banco); Schema separados (os tenants compartilham o mesmo banco físico, entretanto cada um deles possui um schema); e também podemos implementar o Multi-Tenancy através de Particionamento (usamos o mesmo banco físico e o mesmo Schema), onde os tenants são particionados de acordo com algum discriminator value (uma chave que apareceria em toda as tabelas) e uma única tabela guarda os dados de cada um deles. O Hibernate 4 dá suporte a esta última opção de maneira fácil. Para este caso, tomemos como exemplo uma tabela no banco denominada Cliente:

CLIENTE (
  ID BIGINT,
  NOME VARCHAR,
  ...
  TENANT_ID VARCHAR (ou uma chave estrangeira)
)

Note que precisamos do campo TENANT_ID, pois ele define a qual tenant nos referimos. Em um exemplo real, esse ID vai dizer a qual loja pertence determinado produto, por exemplo. Essa abordagem via Particionamento ainda dá suporte a cache de segundo nível.

Mas será que sempre precisaremos nos lembrar de criar um TENANT_ID em nossas tabelas? Como poderíamos ter algo como:

CLIENTE (
  ID BIGINT,
  NOME VARCHAR,
  ...
)

sem termos um TENANT_ID? Poderíamos ter schemas separados e criarmos uma SessionFactory para cada tenant. Entretanto, isso seria inviável se tivéssemos muitos tenants, pois muitas SessionFactories podem ser extremamente custosas para a memória. Uma outra ideia seria utilizarmos uma abordagem conhecida como application-supplied connections, onde abrimos uma Session em cada SessionFactory através de uma Connection específica que fornecemos. Podemos dizer ao Hibernate qual Connection utilizar em cada contexto. Lembra-se de quando explicamos o ServiceRegistry? Um dos Services, é o ConnectionProvider. Separando os schemas evitamos a necessidade de um TENANT_ID em cada tabela, mas perdemos a possibilidade de usar o cache de segundo nível de maneira fácil, além de ser mais trabalhoso realizar relatórios e estatísticas com mais de um cliente.

O Hibernate 4 fornece essas alternativas básicas para o cenário multi-tenant, de forma quase transparente.

Usando o Hibernate 4

Quer ver o Hibernate 4 em ação? A maneira mais fácil de colocá-lo em seu projeto é através do Maven:

  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>4.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-entitymanager</artifactId>
    <version>4.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-annotations</artifactId>
    <version>3.5.6-Final</version>
  </dependency>

Se você utiliza alguma outra ferramenta de build, aqui você encontra todas as dependências necessárias declaradas para Ivy, Gradle, SBT, entre outros.

Você também pode baixar os jars necessários para usá-los diretamente. Caso você use o JBoss AS 7 (conheça mais sobre essa nova versão do servidor), a versão 7.1 (ainda em Beta) já vem com o Hibernate 4 Final. Se você preferir o cloud, pode experimentar o Hibernate 4 no Openshift (aqui há um tutorial no blog da Caelum).

Gostou? Há muito mais nos links abaixo:

Webinar de Hibernate 4 – link
Hibernate 4 – post oficial do in.relation.to
Multi-Tenancy – mais informações (tutorial introdutório)
Multi-Tenancy e Hibernate 4 – Perguntas e Respostas

Também não deixe de visitar os vários posts da Caelum sobre Hibernate, inclusive o conhecido 7 hábitos dos desenvolvedores Hibernate e JPA altamente eficazes. Esperamos você no nosso curso de Hibernate e JPA!

Desenvolver um aplicativo Android com uma boa interface com o usuário não é fácil: os diferentes tamanhos de tela podem dar trabalho para chegar a um resultado satisfatório em múltiplos dispositivos. Quando levamos em conta os tablets surge um problema ainda maior: como criar uma aplicação para smartphone que, ao rodar em um tablet, aproveite o espaço extra que o dispositivo oferece? Mais ainda: como fazer isso de maneira fácil?

A partir da versão 3 do Android, através da a API de Fragments, podemos dividir nossa tela e dar comportamento a cada pedaço (fragmento) de uma view com um Fragment.

Como exemplo vamos usar uma aplicação que contém uma listagem de nomes de arquivos de fotos em um ListView. Queremos que o evento de clique em um item da lista nos mostre a imagem selecionada.

Caso nosso Tablet esteja na horizontal gostaríamos que a listagem e a imagem escolhida apareçam na mesma tela, conforme ilustrado na imagem abaixo:

Comportamento da seleção de uma imagem no Tablet na horizontal

No caso do tablet estar na vertical gostaríamos de ver apenas a listagem ou a imagem na tela:

Comportamento da seleção da imagem em um Tablet na vertical

Para que isso seja possível precisamos ter layouts diferenciados para o tablet em landscape. Podemos fazer isso colocando qualifiers nas pastas de layout. Em nosso caso telas grandes em landscape.

Na view em landscape podemos usar a tag fragment:

<LinearLayout ...>
  <fragment android:id="@+id/fragment1"
     android:name="br.com.caelum.hubbletablet.ListaImagensFragment" .../>

  <fragment android:id="@+id/fragment2"
     android:name="br.com.caelum.hubbletablet.ImagemFragment" .../>
</LinearLayout>

Enquanto a outra será apenas um framelayout para inflar:

<LinearLayout ...>
     <FrameLayout android:id="@+id/ambos_fragments" .../>
</LinearLayout>

Para criarmos um Fragment basta herdarmos da classe e implementar o método onCreateView, onde receberemos um inflater o qual podemos usar para inflar uma view que queremos associar ao Fragment.

public class ListaImagensFragment extends Fragment {
   public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {

       View viewLista = inflater.inflate(R.layout.lista, null);

       ListView listaImagens = (ListView) viewLista
           .findViewById(R.id.listaImagens);

       colocaDadosNoListView(listaImagens);
   }
   // ...
}

O controle da tela ainda é feito pela Activity e através dela manipularemos os Fragments. Caso o tablet esteja na horizontal, a Activity estará associada à versão do main.xml que usa a tag fragment, que informa ao Android as classes dos Fragments que desejamos usar, então o próprio Android se encarregará de instanciá-los. Caso o tablet esteja na vertical, a Activity estará associada à versão do main.xml que contem apenas uma tag FrameLayout, nesse caso precisaremos criar o fragment que trará a lista e associá-lo ao FrameLayout. Fazemos isso no onCreate da Activity:

getFragmentManager().beginTransaction()
    .add(R.id.ambos_fragments, new ListaImagensFragment())
.commit();

Para termos a funcionalidade de apertar o botao de back no Android e o mesmo empilhar e desempilhar os fragments, podemos fazer:

getFragmentManager().beginTransaction()
    .replace(R.id.ambos_fragments, new ListaImagensFragment())
    .addToBackStack(null)
.commit();

O código acima só deve ser executado se o tablet estiver na horizontal, portanto precisamos fazer essa verificação, uma maneira de fazer isso é através do Activity.getResources().getConfiguration().orientation.

No onCreateView do ListaImagensFragment podemos guardar em um atributo o endereço da imagem selecionada quando houver um clique em um item na lista. Como fazemos agora para passar essa informação para o ImagemFragment para que ele possa mostrar a imagem?

Quando estamos trabalhando apenas com Activities temos que usar o putExtra em Intents para enviar dados de uma Activity para outra. O envio de informações de um Fragment para o outro pode ser feito na Activity de uma forma menos orientada a Strings e maps, tornando nosso código mais orientado a objetos.

Se o tablet estiver na horizontal:

ListaImagensFragment listaFragment = (ListaImagensFragment)
	getFragmentManager().findFragmentById(R.id.fragment1);

ImagemFragment imagemFragment = (ImagemFragment)
	getFragmentManager().findFragmentById(R.id.fragment2);

imagemFragment.setImagem(listaFragment.getImagemSelecionada());
imagemFragment.atualizaImagem();

Se estiver na vertical:

ListaImagensFragment listaFragment = (ListaImagensFragment)
	getFragmentManager().findFragmentById(R.id.ambos_fragments);

ImagemFragment imagemFragment = new ImagemFragment();
imagemFragment.setImagem(listaFragment.getImagemSelecionada());

getFragmentManager().beginTransaction()
	.replace(R.id.ambos_fragments, imagemFragment)
	.addToBackStack(null)
.commit();

Essa solução ficou tão interessante que os desenvolvedores da plataforma resolveram criar um pacote de compatibilidade para poder usar praticamente as mesmas ideias nos dispositivos antigos, sem precisar de um dispositivo moderno com versão 3.x ou 4.x, de maneira bem simples.

Um grande cuidado que devemos ter com o uso de Fragments é evitar espalhar por toda aplicação if’s que verificam se a tela é grande ou o aparelho está na horizontal, etc. Podemos criar diferentes classes que implementam o comportamento em aparelhos grandes e em pequenos e então fazê-las implementar uma interface java. Assim podemos utilizar o polimorfismo e chegar a uma solução mais elegante.

O cloud vem se espalhando pelo mercado de TI e em especial entre os desenvolvedores de software. Heroku, Cloud Foundry, Microsoft Azure, Google App Engine, entre outros serviços de cloud no modelo PaaS, (Platform as a Service), popularizaram-se muito nos últimos tempos.

Para disponibilizar serviços de cloud, é necessário que haja uma infraestrutura de servidores bastante robusta e uma ambientação sofisticada. Aproveitando a experiência no ramo, a Red Hat lançou, em maio de 2011, durante o Red Hat Summit, seu serviço de PaaS: o OpenShift.

O OpenShift possui duas versões – OpenShift Express, opção simples e rápida para hospedar aplicações Ruby, Python, Perl ou Java do zero; e OpenShift Flex, para ser integrado ao Amazon EC2 em aplicações PHP e Java a fim de propiciar monitoramento avançado e auto-scale.

Havia uma boa disponibilidade de PaaS para linguagens como Ruby e Python, e, em contrapartida, o mercado contava com poucas opções de PaaS para Java. A fim de atacar esse ponto, a equipe do OpenShift lançou suporte para aplicações Java, tanto para aas versões Express quanto para a Flex. Adotando como servidor o JBoss AS 7 (mais informações neste post), o OpenShift implementou uma maneira muito simples e rápida para deployar aplicações Java para o cloud, aceitando quase qualquer framework disponível.

Primeiros passos com o OpenShift

Para usar o OpenShift Express, inicialmente é preciso cadastrar uma conta. Feito isso, devemos instalar o conjunto de ferramentas para trabalharmos com o OpenShift. Para Linux ou Mac OS, é necessário que Ruby 1.8 esteja instalado na máquina, e, como root, devemos executar:

gem install json_pure
gem install rhc

Fizemos um pequeno screencast para dar uma pequena introdução ao OpenShift Express. Você pode seguir os passos descritos no vídeo abaixo após instalar as gems especificadas acima:

Agora é necessário criar um domínio para hospedar nossas aplicações. Basta digitarmos no terminal:

rhc-create-domain -n meu_dominio -l seu_login

Os parâmetros -n e -l especificam, respectivamente, o nome do domínio que você deseja e seu login no OpenShift. Será solicitada sua senha; digite-a e pronto, seu domínio foi criado.

É importante frisar que o OpenShift utiliza git para controle de versão, por isso é necessário tê-lo instalado em sua máquina antes de criar aplicações.

Em seguida, vamos criar uma aplicação. Além de fornecermos o nome, é necessário também fornecer o tipo da aplicação que iremos deployar – Ruby, Java, Python, Perl ou PHP. Para tanto, executamos o seguinte comando:

rhc-create-app -a minha_app -t jbossas-7.0 -l seu_login

Os parâmetros -a e -t representam, respectivamente, o nome de sua aplicação e o tipo (linguagem) escolhido. Novamente, -l representa seu login no OpenShift. O tipo da aplicação, indicado por -t, pode receber os seguintes valores:

rack-1.1 – Aplicações Ruby
wsgi-3.2 – Aplicações Python
jbossas-7.0 – Aplicações Java
perl-5.10 – Aplicações Perl
php-5.3 – Aplicações PHP

Experimente acessar http://minha_app-meu_dominio.rhcloud.com/. Uma página de index padrão deve aparecer se tudo correu bem.

O OpenShift suporta alguns bancos bastante populares como MySQL e SQLite. Podemos adicionar suporte ao MySQL em nossa aplicação de exemplo digitando o seguinte comando:

rhc-ctl-app -a minha_app -e add-mysql-5.1

O parâmetro -a refere-se ao nome de nossa aplicação, e -e refere-se à ação que desejamos efetuar; no caso, adicionar suporte para MySQL. O OpenShift então irá lhe devolver em seu console alguns dados de sua base, tais como nome, host e senha. Anote e guarde esses dados!

Podemos ainda acessar nosso banco remoto com o auxílio do PHPMyAdmin. Basta digitar o comando:

rhc-ctl-app -a minha_app -e add-phpmyadmin-3.4

Digitamos então o usuário e senha do banco remoto que nos foi fornecido anteriormente e pronto! Temos suporte do PHPMyAdmin.

Todas as etapas até a criação de sua aplicação podem ser realizadas por meio da interface gráfica disponibilizada pelo site do OpenShift. Apenas frisando que criar a aplicação via linha de comando já gera automaticamente um projeto trackeado para a branch remota de sua aplicação no OpenShift. Criar através do assistente gráfico vai requerer que você faça isso manualmente.

Gostou? Atualmente um dos projetos da Caelum, o Calopsita, está no OpenShift. Você também pode obter mais informações acessando a documentação oficial e também nos diversos materiais elaborados pela Red Hat e pela comunidade. Será um forte competidor para as outras plataforma?

Após um bom tempo de aulas ministradas, encontrei uma linha de aprendizagem que acho interessante para chegar até as consideradas boas práticas. A linha é formada pelos conceitos básicos de Orientação a Objetos, Testes, Injeção de Dependências, Programação orientada a interfaces e Mocks. Obviamente há uma interdependência dos tópicos. Há espaço aí para separação de responsabilidades com aspectos, além de design patterns.

Não é a toa que mocks sejam complicados para quem está começando, ele é totalmente obscuro (experiência própria), além de que, dependendo das unidades, é possível testá-las sem mocks. Portanto, é mais interessante lidar com outros conceitos, como injeção de dependências, para só depois partir para Mocks.

O artigo não tem como objetivo explicar o conceito de Mocks, mas sim explicar a aplicabilidade do framework de testes Mockito nos seus projetos. Se você está começando agora, uma boa dica é procurar as edições da MundoJ (em quase toda edição há artigos relacionados a testes e consequentemente mocks) e depois ler o artigo do Martin Fowler.

Mesmo sem conhecer Mocks, lanço um desafio. Continue lendo o artigo e ao final sentirá quanto absorveu do conteúdo. Certamente terá dificuldades. Faça o bookmark do post, volte aos seus estudos, pratique e retorne depois. Ao reler o texto, perceberá o quanto evoluiu, resultado direto de seus estudos.

Então vamos ao código. Temos uma classe FuncionarioDAO e um método buscarFuncionario. No nosso exemplo, para buscar o Funcionario, o sistema deve se comunicar com um mainframe por meio de uma interface Transacao. Mas perceba aqui que poderia ser uma interface EJB comunicando-se remotamente ou até mesmo uma transação simples JDBC. Essa transação mainframe retorna uma String contendo as informações do usuário, separada por colunas. Então o que devemos fazer é uma lógica para montar um Funcionario a partir dessa resposta. Começando pelos testes, teríamos o seguinte:

class FuncionarioDAOTest {

  private FuncionarioDAO funcionarioDAO;

  @Mock
  private Transacao transacao;

  @Before
  public void init(){
    MockitoAnnotations.initMocks(this);
    funcionarioDAO = new FuncionarioDAO(transacao);
  }

  @Test
  public void quandoUmUsuarioValidoForPesquisado(){
    when(transacao.executar("12345")).thenReturn("RAPHAEL   12345 2045 ");
    Funcionario funci = funcionarioDAO.buscarFuncionario("12345");
    Assert.assertEquals("RAPHAEL", funci.getNome());
    Assert.assertEquals(2045, funci.getSetor());
    Assert.assertEquals("12345", funci.getMatricula());
    verify(transacao, atMostOnce()).executar("12345");
  }

  @Test(expected=UsuarioInexistenteException.class)
  public void quandoUmUsuarioInexistenteForPesquisado(){
    when(transacao.executar("123")).thenThrow(new TransacaoOnlineException());
    Funcionario funci = funcionarioDAO.buscarFuncionario("123");
  }
}

O grande problema é a interface Transacao. Como estamos testando a unidade, não queremos que um objeto real se comunique com o mainframe: seria lento e difícil de testar o resultado, além de testar mais de uma unidade. Esse assunto já foi bastante discutido em artigos do blog da Caelum que falam de testes, sua influência no design, no acoplamento e na velocidade do seu projeto. Perceba o uso da annotation @Mock, ela facilita a criação de mocks, deixando o código mais limpo.

A primeira linha do primeiro teste (when(transacao.executar("12345")).thenReturn(" ... "))define como queremos que o mock se comporte durante a chamada do método executar. O Mockito leva uma grande vantagem aqui sobre os outros frameworks por ser extremamente refactoring friendly. Para isso, usamos o método when. Já na primeira linha do segundo teste podemos emular um erro através do thenThrow, ou seja, caso não haja nenhum funcionario, o método deverá lançar uma exceção. Com isso isolamos o teste apenas à unidade em questão, sem que código de outras unidades sejam executados.

Podemos ainda verificar se durante a execução de buscarFuncionario o método do nosso mock foi acionado. Para isso usamos o método verify. O segundo argumento pode receber alguns outros métodos do Mockito como never, atMostOnce, alLeastOnce, times().

Há algumas pessoas que acham desnecessário verificar se o método do objeto mocado foi realmente invocado. Inclusive a própria documentação do mockito comenta a respeito. Porém o uso do verify evita que alguém retire essa linha do seu código, algo bem difícil de acontecer, mas por experiência própria, podemos esquecer algum assert.

Feito os testes, partimos então para a lógica.

class FuncionarioDAO {
    private Transacao transacao;
    FuncionarioDAO(Transacao tx) {
       this.transacao = tx;
    }

   public Funcionario buscarFuncionario(String matricula) {
      try {
          String resposta = transacao.executar(matricula);
          return montarFuncionario(resposta);
      }
      catch(TransacaoOnlineException e){
         throw new UsuarioInexistenteException(e);
      }
   }

   private Funcionario montarFuncionario(String resposta) {
      String nome = resposta.substring(0,10);
      String matricula = resposta.substring(10,16);
      String setor = resposta.substring(16,21);
      return new Funcionario(nome.trim(),
         matricula.trim(), Integer.parseInt(setor.trim()));
   }
}

Agora, ao rodar os testes, você obterá a green bar!.

Vamos imaginar um cenário que você esteja lidando com um sistema com design mais pobre, com muito uso de métodos estáticos, e seu design ficasse assim:

class FuncionarioDAO {
    public Funcionario buscarFuncionario(String matricula){
       String resposta = TransacaoServiceLocator.executar(matricula);
       return montarFuncionario(resposta);
    }
}

Há algumas formas de testar esse código, ou seja, mocar o comportamento estático. A primeira é manipulação de bytecode (finamente explicado pelo meu amigo André Breves). Entretanto, não me arriscaria a fazer isso na mão, já existem frameworks para tal finalidade e um deles é o PowerMock, que se integra facilmente com Mockito e JUnit. É muito útil principalmente quando o framework que você está usando lhe impõe invocações estáticas a ele. Exemplificando, mesmo tendo D.I, inevitavelmente, uma hora ou outra utilizando o Seam 2.2, você invocará Component.getInstance().

Mas é sempre bom lembrar que fazer um design mais orientado a interfaces e desacoplado de implementações concretas lhe dará uma maior flexibilidade tanto na programação do sistema quanto na construção de testes. A discussão sobre utilização de métodos estáticos já está batida na comunidade, vários argumentos, dentre eles a programação mais estruturada e menos O.O.

A segunda seria encapsular o TransacaoServiceLocator em uma outra classe e mockar essa classe, sem ter de fazer malabarismos.

A terceira forma seria extrair a chamada para um método e na classe FuncionarioDAOTest, na criação de FuncionarioDAO, poderíamos criar uma classe anônima e fazer o override do método buscarTransacao, retornando um mock.

public Funcionario buscarFuncionario(String matricula){
       Transacao tx =  buscarTransacao();
       String resposta = tx.executar(matricula) ;
       return montarFuncionario(resposta);
}

public Transacao buscarTransacao() {
      return TransacaoServiceLocator.buscarTransacaoMainFrame();
}

Mas tudo isso é muito complicado, como o mockito te ajuda? Aí vêm os Spy Objects, a próposito, brilhantemente explicado aqui. Em suma, Spy Objects são objetos reais até que se prove o contrário. E provamos o contrário quando definimos algum comportamento para ele. Exemplificando:

class FuncionarioDAOTest{

   private FuncionarioDAO funcionarioDAO;

   @Mock
   private Transacao transacao;

   @Before
   public void init(){
        MockitoAnnotations.initMocks(this);
        funcionarioDAO = spy(new FuncionarioDAO(transacao));
        doReturn(transacao).when(funcionarioDAO).buscarTransacao();
   }

Agora definimos que todos os métodos de FuncionarioDAO serão invocados normalmente, com exceção do método buscarTransacao, que teve o comportamento alterado. É importante reparar que eu usei doReturn ao invés do when.

Concluindo, o importante mesmo é saber lidar com as várias ferramentas que existem, tirando o maior proveito delas para construção de testes. Por exemplo, o meu framework não faz injeção de dependências por construtores, então já que eu não tenho construtores para receber os atributos, nos meus testes eu faço a injeção usando o Mirror, uma DSL que ajuda na manipulação da API reflection. Hoje mesmo já fui apresentando a uma outra ferramenta, fixture-factory. Indubitavelmente, conhecer o poder que cada ferramenta pode lhe oferecer e principalmente saber quando as utilizar são duas importantes tarefas de um arquiteto de software.

E quais ferramentas você utiliza para fazer os seus testes?

Créditos especiais ao companheiro de trabalho Taciano Tres,que me ajudou com ótimas referências e sempre me obriga a estar atualizado!

A versão 3 dos Enterprise Java Beans trouxe grandes mudanças e muitas simplificações para o desenvolvedor. O forte uso de anotações e convenções, que deixaram os XMLs complexos opcionais, entrou no JPA como forma padrão de persistência para substituir os burocráticos entity beans e a injeção de dependências melhora o design para não depender de lookups acoplados.

O EJB 3.1 foi um passo na mesma direção. Nessa versão as interfaces locais ficaram opcionais, os EJBs podem ser utilizados dentro de um WAR, o que simplifica o empacotamento (EAR não é mais preciso), e várias outras novidades.

Uma das melhorias do EJB 3.1 está relacionada com o agendamento de terefas dentro do servidor de aplicação, o que é o foco desse post. Mas, para ser exato, o agendamento já era possível nas versões anteriores do EJB (entrou na versão 2.1 da especificação), mas foi muito aperfeiçoado no EJB 3.1.

Como funcionava com EJB 3.0/2.1

Primeiro era preciso definir o método que era chamado quando o @Timeout de um agendamento ocorria. Para isso podemos usar um Session Bean Stateless:

@Stateless @Remote(Agendador.class) //pode ser @Local também
public class AgendadorBean implements Agendador {

	@Timeout // no EJB 2.1 implementava a interface javax.ejb.TimedObject
	public void timeout(Timer timer) {
		System.out.println("Timeout: " + timer.getInfo());
	}

Para agendar a execução desse método, usamos o TimerService. Com ele podemos definir o agendamento e executar um método anotado com @Timeout apenas uma vez, ou em intervalos (single-action ou interval-action). O TimerService pode ser injetado, com EJB3, da seguinte maneira:

@Stateless @Remote(Agendador.class)
public class AgendadorBean implements Agendador {

	@Resource //no EJB 2.1 era preciso usar ejbContext.getTimerService()
	private TimerService timerService;

	public void agenda() {
		//definir o agendamento - daqui 10s, cada 20s
		this.timerService.createTimer(10*1000L, 20*1000L, "alguma info");
	}
}

O método createTimer(..) é sobrecarregado e possui variações, mas não tem como fazer mais do que definir single-action-timer ou interval-action.

O que melhorou com EJB 3.1

No EJB 3.1 o TimerService ganhou métodos para deixar o agendamento mais preciso, baseado em expressões de calendar. Isso é bem parecido com o que o framework Quartz permite no Java, e as expressões cron:

public void agenda() {
	// cada segunda e quarta as 8:30
	ScheduleExpression expression = new ScheduleExpression();
	expression.dayOfWeek("Mon,Wed");
	expression.hour("8");
	expression.minute("30");
	this.timerService.createCalendarTimer(expression);
	System.out.println("Agendado: " + expression);
}

Com essas expressões podemos definir intervalos bem precisos e a mesma definição também pode ser feita de forma declarativa, através da anotação @Schedule. Com ela nem é necessário usar @Timeout. O método anotado com @Schedule é invocado quando o timeout ocorre:

//dentro do session bean
@Schedule(dayOfWeek="Mon,Wed", hour="8", minute="30")
void agendado() {
	System.out.println("agendado pela anotacao @Schedule");
}

O servidor de aplicação chama então o agendado() periodicamente. Importante saber que qualquer timer que definir um intervalo (interval-action-timer) é persistido e será recuperado quando o servidor reiniciar. Mas podemos deixar o agendamento não persistente também:

//dentro do session bean
@Schedule(dayOfWeek="Mon,Wed", hour="8", minute="30", persistent=false)
void agendado() {
	System.out.println("agendado pela anotacao @Schedule");
}

ou ser for agendado programaticamente:

ScheduleExpression expression = new ScheduleExpression();
//..
TimerConfig config = new TimerConfig();
config.setPersistent(false);

this.timerService.createCalendarTimer(expression, config);

Poderíamos ainda melhorar o exemplo usando @Singleton e @Startup, outras novidades do EJB 3.1. Isso pode ser útil se for utilizado o agendamento através do @Schedule não persistente. E claro, isso é apenas mais uma das facilidades que o container EJB e o servidor de aplicação podem oferecer, todos vistos no treinamento Java EE avançado e Web Services.

JSF é um framework web MVC que foi criado para desenvolver aplicações web de maneira stateful (além de vários outros motivos). São os componentes do JSF que guardam este estado e por causa deles JSF consegue se lembrar, por exemplo, qual converter ou validator é para usar, ou qual era o valor que o usuário digitou na requisição anterior.

O simples formulário abaixo declara um h:inputText e um h:commandButton. Quando o JSF recebe a requisição inicial (HTTP GET) serão instanciados esses componentes que são do tipo UIForm, UIInput (que é associado com um validator DoubleRangeValidator) e um UICommand. Cada componente estende a classe UIComponent e pode ter filhos, assim usando o famoso design pattern Composite, veja o exemplo:

<h:form>
	<h:inputText value="#{formularioBean.valor}" id="valor">
		<f:validateDoubleRange minimum="0" />
	</h:inputText>
	<h:commandButton value="Enviar" action="#{formularioBean.mostra}"/>
</h:form>

O resultado é a árvore de componentes (também é chamado view ou UIViewRoot). Ela fica salva na HttpSession do usuário. Por isso, JSF sabe se lembrar qual valor (setter) deve ser usado para preencher o nosso modelo (é o componente que guarda isso!) e por isso também não é preciso definir na URI qual método deve ser chamado no bean, que é tão comum nos frameworks action-based. No formulário acima essa informação está encapsulado no UICommand (h:commandButton).

Cada vez que o controlador JSF recebe um novo HTTP GET para uma página (request inicial) será criado uma árvore nova. Para distinguir entre as árvores diferentes, JSF renderiza no HTML sempre um campo a mais que representa a identificação da árvore dentro da sessão HTTP:

<input id="javax.faces.ViewState" value="-5331242430046946924:4161480279607048884"  type="hidden" />

javax.faces.ViewState guarda a identificação da árvore no lado do cliente e para cada GET se repete este procedimento (nova árvore, nova identificação). Ou seja, todas as página vão ter uma ou mais árvores de componentes na sessão (mesmo para uma aplicação com poucas páginas, o usuário poderia usar várias abas da mesma página). Para testar isso basta chamar uma página (GET) e verificar o número do campo javax.faces.ViewState (a identificação deve mudar):

1. HTTP GET -> ViewState ID: 3695116712045768933
2. HTTP GET -> ViewState ID:-7330234494192939826
3. HTTP GET -> ViewState ID: 6490700310803488872
(3 requisições para a mesma página geram 3 árvores diferentes na sessão do usuário)

Isso significa que um usuário mal intencionado poderia enviar milhares de GET para uma página JSF para causar a criação de árvores na sessão até a memória HEAP acabar. Para evitar esse tipo de problema, o controlador JSF limita a quantidade de árvores por usuário. Usando a implementação referencial Mojarra o padrão é de 15 árvores no máximo por sessão. Caso o usuário abra, por exemplo, mais do que 15 abas no navegador, o controlador JSF automaticamente vai tirar a árvore menos usada (LRU) da sessão. Para testar isso podemos usar um filtro que imprime o conteúdo da sessão, como mostra a imagem ao lado. Se o usuário usa uma aba com uma ID que o controlador já tirou recebemos a famosa ViewExpiredException:

Através de uma configuração no web.xml, específica para cada implementação JSF, podemos mudar o padrão. Segue a definição para Mojarra:

<context-param>
   <param-name>com.sun.faces.numberOfViewsInSession</param-name>
   <param-value>5</param-value>
</context-param>

O parâmetro é específico para a implementação Mojarra e só funciona na versão 1.2. Mojarra 2.x não respeita o parâmetro apesar da documentação indicar que ela sirva para ambas versões. A implementação MyFaces também possui uma configuração parecida.

Conseguimos então limitar a quantidade de árvores na sessão. Dependendo da quantidade de usuários e complexidade das telas comparado com o tamanho disponível de memória no servidor podemos mesmo assim enfrentar problemas. Por isso a especificação JSF oferece um recurso para não gravar a árvore de componentes na sessão. Mas onde fica o estado então? Toda árvore do componentes é serializada e é devolvida através de um inputHidden na resposta da requisição. Esse não é o comportamento padrão e deve ser configurado no web.xml, mas faz parte da especificação JSF:

  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value> <!-- server é o padrão -->
  </context-param>

Nesse caso não fica mais a identifição da árvore no HTML gerado, e sim a árvore serializada:

Em cada requisição trafega a árvore inteira entre navegador e servidor e no início de cada requisição o servidor recria essa tela. Isso aumenta a banda e uso da CPU no servidor, mas diminui o uso da memória. É importante mencionar que apenas o ViewState será serializado (os componentes) e não o estado da aplicação (ManagedBeans). Caso colocarmos algum ManagedBean na sessão, o bean continua não sessão, não fazendo parte da serialização. O filtro mostra esse comportamento e continua imprimindo o FormularioBean:

A documentação da Mojarra indica que normalmente o client-state é a melhor solução, mas isso é um tradeoff entre desempenho e uso de memoria e deve ser avaliado para cada projeto. Mojarra até oferece soluções misturadas, podemos por exemplo serializar o view-state, mas deixar a árvore serializada na sessão.

Desenvolver com Java para web permite a criação de aplicações robustas e escaláveis. Entretanto, uma das principais queixas dos desenvolvedores consiste na questão dos servidores. De modo geral, diferente de Ruby ou PHP, criar e manter aplicações para web com Java consiste em ter que reiniciar o servidor a cada mudança nas classes, uma vez que Java não é uma linguagem interpretada. Esse “tempo gasto” com o servidor originou algumas frases que devem lhe soar de modo familiar, tais como: “Esse servidor é muito lento para startar!” ou “Dá tempo de tomar cinco cafés até que o deploy termine!“. Outro ponto de incômodo consiste na questão da complexidade de alguns servidores. Você já deve ter ouvido alguma pergunta do tipo “Qual desses infinitos XMLs devo modificar para ativar o que eu preciso?“. Muitas vezes os servidores Java EE, por mais ricos e robustos que fossem, geravam alguma confusão e certo transtorno.

Eis que o JBoss AS 7 vem para derrubar algumas dessas questões que geravam um enorme incômodo nos desenvolvedores. Usamos o JBoss AS há muito tempo, inclusive no nosso curso FJ-31, e o primeiro ponto que impressiona no AS 7 é seu tempo de start – em cerca dois segundos ou menos é possível iniciar uma instância do servidor (levantando alguma aplicação que esteja na pasta de deploys também). Não, você não leu errado, aproximadamente dois segundos. Para usuários de versões antigas do JBoss AS isso pode parecer um pouco absurdo, uma vez que o AS 5, por exemplo, tinha fama de levar muito tempo para iniciar após a realização de um deploy.

O Jboss AS 7 foi completamente reescrito, deixando de utilizar o JBoss Microcontainer para dar lugar ao JBoss Modular Service Container (MSC). Basicamente, em vez de adotar dependências de modo hierárquico na hora de iniciar o servidor, o MSC define dependências explícitas de modo similar a um grafo, sendo possível levantar diversos serviços de forma concorrente.

Mudanças em relação a versões antigas do JBoss AS

Falando em outras versões do JBoss AS, uma das mudanças que ocorreram consta no script de start. Não há mais o run.bat ou run.sh; este foi substituído pelo standalone.bat ou standalone.sh. Essa mudança se deu porque o AS 7 agora pode operar em dois modos: standalone, que é similar às versões anteriores do JBoss AS, onde um único processo é iniciado; ou operar em Managed Domain, onde múltiplas instâncias são iniciadas e regidas por uma instância central, tal qual mostra a figura abaixo:

JBossAS7 domain

Muito simplificadamente, a imagem acima ilustra o funcionamento do JBoss AS 7 em modo domain. Basicamente, um processo central (Domain Controller) rege múltiplas instâncias do AS 7 contidas em hosts diversos. Operar em modo domain é bastante interessante. Você pode obter mais informações na documentação oficial do JBoss AS 7.

JBoss AS 7 em produção

A boa notícia é que a maioria das aplicações Java EE que rodavam em versões antigas do JBoss AS e em outros servidores Java EE ou até mesmo servlet contaners, tais como Jetty e Tomcat, provavelmente funcionarão sem nenhuma configuração adicional ao serem movidas para o JBoss AS 7. Entretanto, é possível que seja necessário um ajuste ou outro devido ao Class Loading do AS 7, que é consideravelmente diferente de outros servidores, podendo carregar dependências equivocadas. Na maioria dos casos, declarar explicitamente as dependências no MANIFEST.MF resolve a os problemas. Por exemplo, para utilizar versões antigas ou que não sejam padrão do slf4j, basta adicionar ao MANIFEST.MF a seguinte linha:

Dependencies: org.slf4j.jcl-over-slf4j

Apesar de novo, já há projetos fazendo uso do JBoss AS 7 devido a suas inúmeras vantagens. Por exemplo, o Openshift, projeto de Cloud da Red Hat, utiliza o AS 7. Você inclusive pode realizar deploy de suas aplicações Java gratuitamente lá. O Torquebox, projeto que possibilita a criação de aplicações com JRuby on Rails, roda no AS 7 a partir da versão 2.

O JBoss AS 7 é bastante promissor para o desenvolvimento Java para web. O vídeo a seguir mostra um pouco dele na prática.

Você pode baixar o JBoss AS 7 aqui. Caso queira informações extras sobre a estrutura do AS 7, leia esse post publicado no In Relation To.