Nos dias 11 e 12 de maio aconteceu, em Fortaleza, o JavaCE Conference, evento com foco na plataforma Java e não restrito apenas a ela. Foram abordadas outras linguagens como C#, Ruby e Scala, além do desenvolvimento mobile para Android e iOS. O evento foi organizado pela Milfont Consulting e TriadWorks.

No primeiro dia, Paulo Silveira e eu apresentamos a principal novidade do futuro próximo do Java, o projeto Lambda do JDK 8, passando por APIs que trazem uma programação mais funcional em Java, como o LambdaJ. Loiane Groner mostrou como ser produtivo com VRaptor e ExtJS, além de fazer uma introdução aos dois frameworks. A equipe TriadWorks analisou várias ferramentas de build (ant, maven e gradle), mostrando vantagens e desvantagens para depois apresentar features do poder do Groovy com Gradle. Carlos Villela e Gregório Melo, da ThoughtWorks, trataram sobre NoSQL, mostrando features do Redis e do HBase, assim como um pouco do teorema CAP. Otavio Santana também apresentou casos de uso sobre bancos NoSQL, focando o Apache Cassandra e no Java.

Ainda teve Douglas Campos fazendo uma palestra hardcore sobre o invoke dynamic, a nova instrução do bytecode do Java 7. Diogo Souza que fez uma excelente e divertida apresentação sobre RoboGuice, ferramenta para injeção de dependências para aplicações Android. Ele explicou desde os conceitos básicos de Injeção dependência até demonstração de código e ainda salientou sobre o ano mobile no país. E por fim tivemos Leonardo Leitão falando sobre Rest e Cloud Computing, e Bruno Souza finalizou com uma discussão sobre os rumos da plataforma Java, o caso da Oracle X Google e como a comunidade e os desenvolvedores se enquadram em toda essa situação. O Tiago Ribeiro também postou sobre o primeiro dia do evento.

No segundo dia, Alberto Souza explicou as facilidades e dificuldades encontradas no desenvolvimento de uma aplicação em Scala, cuidados em relação ao uso dos implicits e o problema do tooling, compilador e do sbt: todos incipientes. Tivemos Marlus Saraiva com JasperReports no Ruby on Rails. Luca Bastos fez uma palestra divertida sobre machine learning, mostrando que ela está presente em praticamente todas as ferramentas que utilizamos. Maurício Linhares fez uma palestra sobre algumas dificuldades que ele teve com Ruby, Java e que com Scala foram sanadas. Por fim, Rodrigo Kumpera explicou da dificuldade dos desenvolvedores mobile em ter que programar cross-plataform, haja visto que cada plataforma (iOS, Android, Windows) utiliza uma linguagem diferente. Ele apresentou a proposta do Mono que é uniformizar C# como linguagem de desenvolvimento para as três ambientes. Ainda tivemos palestras sobre integração contínua com Tiago Bastos e big data analytics com Fernando Meyer.

Foi um evento que mais uma vez mostrou a força que tem a comunidade Java, que há tempos saltou de focar na linguagem para abordar mais firmemente a plataforma e até outras tecnologias. Sem falar na destacada comunidade cearense, sempre presente em eventos de todo o Brasil. Quem foi pode ver muitos dos tópicos quentes sendo apresentados, sem contar as produtivas conversas nos corredores e até mesmo codificação durante os vários happy hours. Tudo isso em uma ensolarada Fortaleza. Nos vemos nos próximos eventos, como o Conexão Java, focado no público iniciante da plataforma, e no QCon SP, uma conferência para os desenvolvedores mais experientes. Fica o agradecimento a todos organizadores, especialmente  ao Christiano Milfont,  pela coordenação e confiança.

Com o crescimento do mercado mobile, a integração de sistemas com os pequenos aparelhos se tornou essencial. O formato JSON se popularizou com a mesma velocidade que o desenvolvimento mobile. Sua simplicidade e facilidade de desenvolver parsers o tornou uma das principais alternativas na integração de sistemas web, em especial para ser consumido via AJAX.

No iOS não foi diferente. A necessidade dos desenvolvedores levou o surgimento de diversas bibliotecas que faziam o trabalho de ler e gerar JSON com extrema facilidade, como o JSON Framework e o TouchJSON. Porém a Apple não quis ficar de fora e incorporou a classe NSJSONSerialization, capaz de gerenciar o formato tanto no iOS como no desenvolvimento para OSX, com a mesma facilidade que as bibliotecas opensource trouxeram.

Recetemente desenvolvemos um projeto para iOS para auxiliar os alunos do nosso curso de iOS, o IP-67, enriquecendo a experiência e trazendo um exemplo bem palpável. A aplicação consiste em buscar os pontos de ônibus próximos a localização do usuário. Para integrar a nossa aplicação com um backend em Ruby utilizamos JSON como o formato e a classe NSJSONSerialization se mostrou extremamente simples e fácil de se trabalhar. Vamos entender como fizemos, do lado do dispositivo, a leitura e manipulação dos dados.

Primeiramente precisamos obter as informações no formato JSON para então parsea-los. Utilizando o método + (id)dataWithContentsOfURL:(NSURL *)url; da classe NSData para fazer uma request e obter as informações de forma síncrona em um endereço da WEB:

NSString *url = [NSString stringWithFormat:@"http://ondeestaoalbi.herokuapp.com/onibusesNosPontosProximos.json?lat=%f&long=%f", -23.588453, -46.632103];
NSData *jsonData = [NSData dataWithContentsOfURL: [NSURL URLWithString:url]];

O nosso serviço retornará um JSON com a seguinte estrutura:

{
    "nome": "920016054",
    "descricao": "R. Dr. Neto De Araujo, 311",
    "coordenada": {
        "latitude": -23.5876,
        "longitude": -46.6321
    }
}

Após receber as informações, vamos utilizar a classe NSJSONSerialization para transformar o JSON em um NSDictionary, contendo as chaves e valores das informações sobre o ponto.

NSError* error;
NSDictionary *resultados = [NSJSONSerialization JSONObjectWithData:jsonData
                options:NSJSONReadingMutableContainers error:&error];

Caso o JSON seja válido e a conversão seja feita com sucesso podemos buscar os valores no NSDictionary a partir de uma chave, utilizando o método - (id)objectForKey:(id)aKey;:

NSError *error;
NSDictionary *resultados = [NSJSONSerialization JSONObjectWithData:jsonData
                options:NSJSONReadingMutableContainers error:&error];
if(!error) {
    NSString *nome = [resultados objectForKey:@"nome"];
    NSString *descricao = [resultados objectForKey:@"descricao"];
    NSLog(@"Nome: %@, descrição: %@", nome, descricao);
}

Poderíamos continuar utilizando o NSDictionary para armazenar as informações dos pontos encontrados, mas imagine que por algum motivo precisemos mostrar a descrição do nosso Ponto sempre com letra minúscula e removendo os espaços do começo e do fim da nossa NSString, o código ficaria da seguinte forma:

    NSString *nome = [resultados objectForKey:@"nome"];
    NSString *descricao = [[resultados objectForKey:@"descricao"] lowercaseString];
    descricao = [descricao stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];
    NSLog(@"Nome: %@, descrição: %@", nome, descricao);

Perceba que o código não é mais tão simples quanto anteriormente, além disso, precisaríamos espalhá-lo por todo o projeto. A manutenção também seria difícil, pois precisaremos copiar e colar o mesmo código toda vez que a descrição for exibida e caso a regra de exibição seja alterada o código que copiamos e colamos terá que ser alterado.

Temos esse problema pois estamos utilizando a classe NSDictionary para guardar estado do nosso Ponto e não podemos definir nenhum comportamento adicional. Para manter os dados organizados e de fácil manutenção devemos sempre criar classes para representar tipos e não mantê-los na representação de chave e valor, desta forma, além de guardar o estado do objeto, podemos também definir novos comportamentos, facilitando a manutenção e a reutilização de código.

Vamos criar as classes com os referentes atributos e também definir um método de classe para criar uma instância do Ponto, esse método será responsável por buscar suas informações em um NSDictionary passado como argumento. Essa regra fica isolada e fácil de dar manutenção caso alguma das chaves mude:

#import <Foundation/Foundation.h>
#import "Coordenada.h"

@interface Ponto : NSObject

@property(nonatomic, strong) NSString *nome;
@property(nonatomic, strong) NSString *descricao;
@property(nonatomic, strong) Coordenada *coordenada;

+ (Ponto *) comDicionario: (NSDictionary *) dicionario;

@end

#import "Ponto.h"

@implementation Ponto
@synthesize nome, descricao, coordenada;

+ (Ponto *) comDicionario: (NSDictionary *) dicionario {
	Ponto * ponto = [[Ponto alloc] init];
	[ponto setNome: [dicionario objectForKey:@"nome"]];
	[ponto setDescricao: [dicionario objectForKey:@"descricao"]];

	Coordenada *coordenada  = [Coordenada comDicionario: [dicionario objectForKey: @"coordenada"]];
	[ponto setCoordenada: coordenada];
	return ponto;
}

@end

Se fosse preciso definir uma regra para buscar a descrição do Ponto da forma que descrevemos anteriormente, podemos alterar o método que busca o atributo na classe, isolando o código e facilitando futuras manutenções.

#import "Ponto.h"

@implementation Ponto
@synthesize nome, descricao, coordenada;

- (NSString *) descricao {
    NSString *descricaoEmMinusculo = [descricao lowercaseString];
    return [descricaoEmMinusculo stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];
}

@end

Para obter um Ponto a partir de um JSON chegamos ao seguinte código:

NSString *url = [NSString stringWithFormat:@"http://ondeestaoalbi.herokuapp.com/onibusesNosPontosProximos.json?lat=%f&long=%f", -23.588453, -46.632103];
NSData *jsonData = [NSData dataWithContentsOfURL: [NSURL URLWithString:url]];

NSError *error;
NSDictionary *resultados = [NSJSONSerialization JSONObjectWithData:jsonData
                options:NSJSONReadingMutableContainers error:&error];
if(!error){
    Ponto *ponto = [Ponto comDicionario: resultados];
    NSLog(@"Ponto: %@", ponto.descricao);
}

Percebendo a dificuldade e a duplicação de código que temos que escrever ao buscar os valores no NSDictionary, desenvolvemos uma pequena biblioteca para facilitar essa tarefa. O KeyValueObjectMapping surgiu da necessidade de transformar grandes estruturas de dados automaticamente em objetos, seguindo padrões e quando necessário adicionando configurações para alterar as convenções. Poderíamos remover a implementação do método + (Ponto *) comDicionario: (NSDictionary *) dicionario; e com o KeyValueObjectMapping teríamos:

DCKeyValueObjectMapping *parser = [DCKeyValueObjectMapping mapperForClass:[Ponto class]];
Ponto *ponto = [parser parseDictionary:resultados];

Lembrando que o KeyValueObjectMapping serve para transformar qualquer tipo de dado que se comporte como um NSDictionary, chave e valor, podendo ser um JSON, um PLIST, entre outros. Você está convidado a contribuir nos projetos!

Se você já escreveu algum código JavaScript, não deve mais achar estranho quando alguém atribui uma função a uma variável. Mas o que exatamente acontece quando você faz isso? Em JavaScript, as funções podem ser passadas como parâmetros para outras funções, retornadas como valor e, como já dito, referenciadas por variáveis. A linguagem trata as funções como cidadãs de primeira classe.

O JavaScript representa funções como objetos. Quando atribuímos uma função a uma variável, estamos criando uma referência para um objeto do tipo function. Podemos ver isso de forma clara utilizando o operador typeof. O exemplo abaixo cria uma função e a atribui a variável chamada apresentar, que recebe como parâmetro um objeto com os atributos nome e email. Vamos invocar a função e a seguir usar o operador typeof para inspecionar o tipo que é referenciado pela variável usada para guardar a função:

var apresentar = function(pessoa) {
     console.log("Eu sou "+ pessoa.nome +" e meu email é: "+ pessoa.email);
}

apresentar({nome: "Ricardo", email: "ricardo.valeriano@caelum.com.br"});
// Eu sou Ricardo e meu email é: ricardo.valeriano@caelum.com.br

typeof(apresentar); // "function"

Quando invocamos uma função com o operador (), estamos utilizando uma forma de invocação chamada por alguns de invocação simples. O maneira como uma função é invocada tem efeito direto sobre como a palavra chave this é “atribuída” no corpo da função.

Quando seu código JavaScript é executado em um navegador, uma variável global chamada window é criada para representar a própria janela do navegador. E quando a forma simples de invocação é usada, o objeto referenciado por this é equivalente ao window, veja:

typeof(window); // "object"

console.log(window); // DOWWindow

var verificandoWindow = function() {
    console.log(this);
    console.log(this === window);
}
verificandoWindow();
// DOWWindow, true

Notou que o tipo referenciado por window é object? Podemos criar nossa própria instância de object usando a chamada notação literal, que é a que foi usada para criar o parametro passado na invocação da função apresentar no nosso primeiro exemplo.

A variável window é uma referência para um objeto e podemos adicionar atributos a ele! Quando criamos uma variável fora de uma função (ou seja no escopo

), automaticamente um atributo com o mesmo nome da variável é criado em window para referenciar o objeto atribuído a nova variável. Quando tentamos acessar o valor dessas variáveis, estamos, na verdade, recuperando o valor de um atributo de window. Veja o exemplo a seguir:

var todosPodemMeVer = "porque sou um atributo de window";
console.log(window.todosPodemMeVer);
// porque sou um atributo de window

var pessoa = {
   nome:  "Ricardo",
   email: "ricardo.valeriano@caelum.com.br"
}

console.log(pessoa.nome);
// Ricardo

console.log(window.pessoa === pessoa);
// true

Toda função tem acesso à palavra chave this. Vamos usar isso para obter informações sobre esse objeto. Vamos criar as propriedades nome e email em window e alterar a função para buscar os valores usando atributos presentes em this, e não mais do objeto recebido como argumento:

var nome = "João da Silva";
window.email = "joao@da.silva";

var apresentar = function() {
    console.log(this === window);
    console.log("Eu sou "+ this.nome +" e meu email é "+ this.email);
}

apresentar();
// true
// Eu sou João da Silva e meu email é joao@da.silva

Veja que criamos um atributo novo chamado email para o objeto referenciado por window. Um atributo pode referenciar qualquer objeto, inclusive funções. Para ilustrar, vamos criar um novo atributo chamado quemSouEu em pessoa, que é uma referência para a função apresentar do exemplo anterior. Dessa forma, será possível invocar essa função diretamente a partir do objeto pessoa.

var pessoa = {
   nome:  "Ricardo",
   email: "ricardo.valeriano@caelum.com.br"
}

Mas a função usa internamente a variável this para fazer seu trabalho, certo? Será que isso vai continuar funcionando? Repare a saída:

pessoa.quemSouEu = apresentar;
pessoa.quemSouEu();
// false
// Eu sou Ricardo e meu email é ricardo.valeriano@caelum.com.br

apresentar();// Agora novamente invocando a função com o operador ()
// true
// Eu sou João da Silva e meu email é joao@da.silva

Uma função referenciada por um atributo de um objeto pode ser invocada como um método daquele objeto, a palavra chave this é atribuída ao objeto onde a função foi invocada.

Uma outra forma de executar uma função no contexto de um objeto específico é invocando o método call disponível em todo objeto do tipo function. Esse método possibilita definir o objeto referenciado por this no momento da invocação:

apresentar.call(pessoa);
// false
// Eu sou Ricardo e meu email é ricardo.valeriano@caelum.com.br

Mas não pense que acabou! Existem ainda outras formas de invocar funções que interferem em como a palavra this é atribuída. Por exemplo, o operador new pode ser utilizado em associação com o operador () para invocar qualquer função, isso vai fazer com que o this seja atribuído a um novo objeto. O retorno da função também pode ser alterado por essa forma de invocação. Você lerá sobre esses detalhes na segunda parte desse artigo.

Para melhorar a manutenibilidade de um sistema, devemos programar voltados para interface. Assim, nos preocupamos apenas com o contrato definido pela interface, não com sua implementação, diminuindo o acoplamento do código. Uma das formas de facilitar essa prática é utilizar a injeção de dependências. Dessa forma, nossas classes não precisam conhecer a lógica de instanciação, ciclo devida e nem implementação dos componente do sistema, podendo mudar facilmente a implementação de suas dependências.

Quando escrevemos um controller no ASP.NET MVC, é interessante que a classe não precise se preocupar com a instanciação de suas dependências. Queremos, por exemplo, receber todas essas dependências no construtor. Vamos usar como exemplo um UserController que precisa de um IUserDao:

class UserController {
  private IUserDao userDao;
  public UserController(IUserDao userDao) {
      this.userDao = userDao;
  }
}

Porém, o ASP.NET MVC não consegue instanciar um controller escrito dessa forma. Ele não sabe como instanciar um IUserDao! Por esse motivo, apenas controllers que tenham um construtor sem argumentos podem ser instanciados. Para mudar esse comportamento, precisamos ensinar o ASP.NET MVC a instanciar controladores que recebem parâmetros no construtor.

Unity Container

Para que possamos criar instâncias de classes que recebam as dependências pelo construtor, precisamos primeiro guardar as instâncias dessas dependências em algum lugar. Precisamos, por exemplo, ter um IUserDao em mãos para passar para o construtor do UserController.

Existem diversos frameworks que nos ajudam nessa tarefa. Eles são conhecidos como frameworks de injeção de dependência. Nesse post utilizaremos o framework de injeção de dependências da Microsoft, o Unity.

O Unity nos oferece uma classe chamada UnityContainer, classe na qual podemos registrar tipos que serão injetados. Para registrar uma dependência, utilizamos o método RegisterType do container, passando a interface, a implementação que deve ser injetada e um nome para ela.

No exemplo, queremos registrar o UserController como uma implementação de IController e o UserDao como uma implementação de IUserDao. Além disso, para seguir a convenção de nomes do ASP.NET MVC, registraremos o UserController com o nome User.

Container.RegisterType(typeof(IUserDao), typeof(UserDao));
Container.RegisterType(typeof(IController), typeof(UserController), “User”);

Agora que temos registrado no Unity tanto o Dao quanto o Controller, podemos pedir instâncias dessas classes para ele! Ao pedirmos uma instância de UserController, o Unity se encarregará de enviar o UserDao para o construtor dele:

IController controller = Container.Resolve<IController>("User");

ControllerFactory com Injeção de Dependências

Agora precisamos ensinar o ASP.NET MVC a utilizar o Unity para instanciar os controllers. Para fazer isso, precisamos criar uma classe que implementa IControllerFactory. Implementações dessa interface devem fornecer três métodos: CreateController, ReleaseController e GetControllerSessionBehavior.

CreateController recebe uma String com o nome do controller que precisa ser criado e deve devolver uma instância de IController. ReleaseController recebe um IController e deve liberar os recursos utilizados. A String com o nome do controller segue a convenção do ASP.NET MVC, ou seja, quando recebemos a String “User“, devemos criar uma instância de UserController.

class UnityFactory : IControllerFactory {
  public UnityFactory() {
    this.Container = new UnityContainer();
    this.Container.RegisterType(typeof(IUserDao), typeof(UserDao));
    this.Container.RegisterType(typeof(IController), typeof(UserController), “User”);
  }

  public IController CreateController (RequestContext context, String controllerName) {
    IController controller = this.Container.Resolve<IController>(controllerName);
    return controller;
  }
  // ...
}

Precisamos também ensinar o ASP.NET MVC a destruir nosso controller e liberar quaisquer recursos que alocamos. Para isso, vamos implementar o método ReleaseController:

public void ReleaseController(IController controller) {
  this.Container.Teardown(controller);
}

O GetControllerSessionBehavior deve retornar o valor de um enum que define o comportamento da session do ASP.NET MVC. Como queremos que a Session tenha o mesmo comportamento da Session padrão, esse método vai retornar System.Web.SessionState.SessionStateBehavior.Default.

public System.Web.SessionState.SessionStateBehavior
      GetControllerSessionBehavior(RequestContext ctx, string controllerName) {
  return System.Web.SessionState.SessionStateBehavior.Default;
}

Estamos quase lá. Resta apenas substituir o mecanismo padrão do ASP.NET MVC pelo que acabamos de criar. Essa substituição é feita no arquivo Global.asax do projeto, através do método SetControllerFactory. Para manter a organização do arquivo Global.asax, o registro do ControllerFactory ficará junto com as configurações globais dentro do método Application_Start():

protected void Application_Start() {
  AreaRegistration.RegisterAllAreas();
  RegisterGlobalFilters(GlobalFilters.Filters);
  RegisterRoutes(RouteTable.Routes);
  UnityFactory factory = new UnityFactory();
  ControllerBuilder.Current.SetControllerFactory(factory);
}

Agora que a aplicação está utilizando a fábrica customizada, o ASP.NET MVC é capaz de instanciar o UserController, passando o UserDao para ele! Essa factory ainda pode ser melhorada. Poderíamos, por exemplo, registrar automaticamente no Unity todos os controllers e componentes que serão injetados. Você pode ver essa implementação, um pouco mais complicada, aqui. Além disso, você pode ver a implementação da factory utilizando o container Windsor no projeto agile-tickets-csharp, projeto utilizado no curso PM-87 da Caelum.

Pronto! Nossos controllers agora podem declarar suas dependências no construtor, deixando o código mais claro e mais fácil de ser testado. Aprenda a desenvolver com ASP.NET MVC em nosso curso online.

Entre os dias 17 e 18 de abril aconteceu em Londres o Scala Days, evento que reuniu diversos ícones envolvidos com o desenvolvimento da linguagem Scala, a qual também já foi tema de diversos posts no blog da Caelum. A grade contou com palestras sobre frameworks utilizados no mundo de desenvolvimento do Scala, detalhes de implementação do compilador, estado das IDE’s que estão sendo desenvolvidas para melhorar o ferramental, até casos de uso da linguagem nas empresas.

Um detalhe bastante interessante foi ver a preocupação com os problemas de tempo de compilação e compatibilidade binária que a linguagem apresenta. Ainda é muito comum que as versões novas de bibliotecas não sejam compativeis com versões prévias e versões novas da linguagem obrigarem os mantenedores dos frameworks a recompilarem seus projetos. O ScalaTest, por exemplo, tem versões de downloads para diferentes versões do Scala.

O keynote mais esperado foi o de Martin Odersky, principal criador da linguagem, comentando sobre os rumos do Scala. Ele comentou sobre as novas SIP’s, Scala Improvement Process, que são as propostas de melhorias para a linguagem, algo análogo às JSRs. Três bastante comentadas foram as Implicit Classes, Values Classes e as Macros. Esta última é uma nova maneira de realizar meta-programação na linguagem, a ideia é tranformar as Macros na forma padrão de criar extensões do compilador. Martin também comentou sobre a nova API de reflection que foi introduzida na versão 2.10 da linguagem. Eles conseguiram facilitar bastante a vida do programdor, principalmente quando é necessário analisar detalhes específicos do código Scala, como os implicits.

Foi um evento muito bom, enquanto que no ano passado tiveram em torno de 250 inscrições, esse ano chegou na marca de 400 pessoas. Ficou claro que os próximos passos da linguagem são na direção de deixá-la mais preparada para uma abordagem enterprise. O esforço na melhoria das IDEs, compatibilidade binária e compilador deixa evidente a preocupação do time da Typesafe com o ferramental de suporte. O mesmo ferramental que é alvo de muitas critícas hoje em dia. Um outro ponto importante é a importância dada à inovação: basta analisar as novas SIP’s que trazem sempre novidades. Você já pode conferir algumas das palestras online.

Há bastante tempo aplicamos e escrevemos sobre integração contínua, uma das práticas mais importantes do desenvolvimento ágil. Através dela, é possível agilizar tarefas demoradas como a compilação de um projeto e a execução dos seus testes automatizados. Com um servidor de integração contínua bem configurado, essas tarefas são executadas a cada mudança no repositório de código e, em caso de erros de compilação ou falhas nos testes automatizados, todos os desenvolvedores são alertados rapidamente. Dessa forma, se o servidor de integração não aponta problemas no projeto, a equipe tem a segurança de que as mudanças no código estão de acordo com a bateria de testes. É também um passo na direção do deploy contínuo.

Nesse post, iremos ensinar como instalar e configurar um projeto simples com testes de unidade no Jenkins, uma versão renovada (e forkada) do Hudson, o servidor de integração contínua que utilizamos aqui na Caelum e um dos mais populares.

O Jenkins é distribuído como um war e portanto pode ser deployado em um servidor de aplicação como o Tomcat ou o Jetty. Nesse post, iremos utilizar o Tomcat e vamos supor que ele já esteja instalado no seu computador. Chamaremos a home do Tomcat de <tomcat>. Você também deve ter o ant instalado no seu computador pois o utilizaremos para compilar o código e executar os testes. Baixe a versão mais recente do Jenkins e coloque no diretório <tomcat>/webpps/. Inicie o servidor de aplicação executando o script <tomcat>/bin/startup.sh. Depois disso, você poderá acessar a interface web do jenkins pela URL http://localhost:8080/jenkins/ no seu navegador.

Para demonstrar a configuração de um projeto novo, iremos utilizar um projeto simples, criado para esse tutorial. Ele possui apenas duas classes bem simples e uma classe de teste com o JUnit. Além disso, o projeto possui um build.xml configurado para compilar o  projeto, executar os testes e gerar um jar. Você pode também ir aplicando todos os passos em seu próprio projeto. Se você ainda não desenvolve com integração contínua, vai poder mudar bastante a forma com que sua equipe desenvolve e receber um feedback contínuo do que está acontecendo.

Como o projeto se encontra em um repositório Git, será necessário instalar um plugin do Git no Jenkins (inicialmente, o Jenkins só suporta CVS e SVN). Para isso, vá até o plugin manager do Jenkins (Manage Jenkins > Manage Plugins) na aba Avaiable, habilite o Git Plugin e clique em Download now and install after restart (pode ser que não exista nenhum plugin disponível na aba Avaiable, nesse caso, vá até a aba Advanced e clique em Check Now para atualizar o repositório de plugins). Depois do término da instalação do plugin, você deverá reiniciar o Jenkins.

Com o plugin instalado, podemos criar uma nova task no Jenkins para compilar e executar os testes do nosso projeto. Clique em New Job, dê um nome a ele, selecione a opção Build a free-style software project e clique em Ok. Você será redirecionado para a página de configurações do projeto.

Na seção Source Code Management, selecione Git e coloque a url pública do repositório (git://github.com/csokol/jenkins-exemplo.git). Em Build Triggers, selecione Poll SCM e no campo Schedule coloque “*/5 * * * *“. Essa configuração determina que o Jenkins irá verificar se houve alterações no repositório desde o último build a cada cinco minutos. Se existir alguma, irá atualizar o seu repositório e executar o job.

Nesse projeto temos duas targets principais do ant que queremos executar no Jenkins, uma para executar os testes e outra para gerar um jar do projeto, pronto para ser distribuído. Para configurar a execução dessas targets, selecione a opção Invoke Ant na seção Build e no campo Targets coloque test jar, essas são as targets que executa os testes e gera o jar, respectivamente.

Agora, precisamos configurar as ações que o Jenkins irá executar depois de executar o ant. Caso exista alguma falha nos testes ou na criação do jar, o Jenkins deve notificar a equipe, para isso, na seção Post-build Actions selecione E-mail Notification e adicione os emails que devem ser notificados em caso de falha no build. Além disso, gostaríamos também de guardar o jar gereado pelo ant, para isso, selecione Archive the artifacts e coloque target/*.jar no campo Files to archive. Assim, toda vez que o job for executado, o Jenkins irá disponibilizar o jar para download em sua interface. Clique em Save para salvar as configurações.

Pronto! Agora o projeto está configurado e cada alteração no repositório irá disparar o Job no Jenkins, executando os testes de unidade:

Como nesse momento o Job nunca foi executado, o primeiro irá iniciar automaticamente e você poderá vizualizá-lo no painel do lado esquerdo em Build history. Você também pode inicar o processo manualmente, clicando em Build Now. Com o build finalizado, você pode visualizar sua página de status, onde poderá baixar o jar criado e também examinar o resultado dos testes em Console Output.

O Jenkins oferece muitos outros recursos além dos descritos aqui, ele é capaz de executar diversas tarefas, como colocar deployar um war em um servidor em produção, gerar relatórios de cobertura de testes, calcular métricas sobre o código do projeto, entre outras. Você poderá conhecer essas funcionalidades explorando os plugins disponíveis ou mesmo desenvolvendo o seu.

O mercado mobile está explodindo em todo o mundo, e no Brasil não é diferente. Saiba porque e como aproveitar as oportunidades.

É verdade que o Brasil já ultrapassou a marca de mais celulares que gente há algum tempo. Ainda em 2010, batemos a marca de 200 milhões de linhas. Desde então, o volume de linhas não pára de crescer, a ponto de já termos o nono dígito nos números celulares de SP a partir de Julho.

É verdade também que já desenvolvemos aplicativos para celulares há muitos anos. Só aqui na Caelum, oferecemos cursos de Java ME desde 2005 e Android desde 2010. Livros sobre desenvolvimento para celulares são bestsellers em todas as livrarias nacionais já faz tempo.

Apesar de tudo isso, eu acredito que 2012 será um ano particular para o mercado móvel no Brasil. Muita coisa está acontecendo agora nessa área. E o potencial é gigantesco.

Consumidores + …

Uma pesquisa antiga – de fevereiro de 2011 – mostrava que 33% das pessoas já tinham smartphone e 20% tinha celular convencional avançado (com Wifi, GPS etc). 41% acessava a Internet no celular (83% entre os donos de smartphone!). 15% já tinha efetuado alguma compra via celular (63% entre usuários de iPhone!). Mais da metade das pessoas tinha um celular com menos de 6 meses de uso. E 40% das pessoas pretendia trocar de aparelho nos seis meses seguintes.

Recentemente, saiu a informação de que a venda de smartphones cresceu 179% em 2011 no Brasil. Muita gente ainda compra celulares convencionais, mas o preço médio do smartphone caiu 33% em 2011, facilitando a maior adoção. A banda larga móvel cresce assustadoramente e já ultrapassou a banda larga fixa há algum tempo.

O pessoal do Google Analytics divulgou que, só nos últimos 4 meses de 2011, o número de usuários mobile cresceu 40%. Mais: vem crescendo 2% por semana e eles prevêem um boom para 2012.

E, apenas para colocar os números em perspectiva: por dia, 370 mil novos seres humanos nascem no mundo todo. E, por dia, só de aparelhos Androids são novos 700 mil. E ainda temos mais 380 mil iPhones/dia. Se somar todos os smartphones e tablets, são 1 milhão e meio de novos aparelhos por dia, uma taxa de crescimento 4x maior que a da população mundial.

… + Governo

As novidades para 2012 atingem até políticas governamentais. Foram anunciados incentivos fiscais tanto para produção de tablets quanto de smartphones no Brasil. O iPhone 4 já é produzido no Brasil desde o ano passado e o iPad começou esse ano.

A tendência é que o preço dos aparelhos caia bastante ainda esse ano e que surjam smartphones a preços populares.

… + Aparelhos

Pela primeira vez, o Google trouxe para o Brasil um modelo da sua grife Nexus de celulares de ponta. É o primeiro modelo com Android 4.0 a chegar por aqui. Aliás, essa que é a versão do Android mais revolucionária lançada até hoje e que logo estará em diversos aparelhos novos e em updates para aparelhos já existentes.

No mundo Apple, cada novo lançamento quebra novamente recordes anteriores. A Microsoft e a Nokia lançam sua linha Lumia com Windows Phone no Brasil com bastante barulho.

E não é só de celulares e tablets que vive o mundo móvel. A chegada iminente da Amazon ao Brasil vai trazer uma revolução à parte no mundo dos ebooks e do comércio eletrônico. E, junto, vem o Kindle para a preços arrasadores. Inclusive o Kindle Fire, seu tablet barato com Android que conseguiu deixar o mercado americano de tablets de ponta cabeça no final do ano passado.

… + Novos comportamentos

O Google recentemente divulgou diversas estatísticas sobre a última edição do Super Bowl americano e o efeito nas buscas. Uma em particular me chamou a atenção: 25% de todas as buscas realizadas sobre o Super Bowl foram feitas em dispositivos móveis.

Mais: durante o jogo, provavelmente com a TV ligada, 41% das buscas foram feitas em dispositivos móveis.

Nas compras não é diferente. O pessoal do Google Adwords fez uma pesquisa que mostrou que 79% dos consumidores usam o celular no processo de compra – seja comparando preços, analisando opções etc. Mais: 70% da pessoas usam o celular quando estão dentro da loja física.

É uma imensa mudança de comportamento!

Usamos celulares a todo momento, e frequentemente para complementar uma experiência já existente. Juntamos mídias ao usar nosso dispositivo enquanto vemos TV e mudamos toda a lógica do comércio ao usar o celular para uma compra física mais informada.

O PayPal, especializado em pagamentos online, teve 141 milhões de dólares movimentados em transações via mobile em 2009. Esse número cresceu para 750 milhões de dólares em 2010 e para incríveis 4 bilhões de dólares em 2011!

O Facebook, maior rede social do Brasil e do mundo, teve 33% de todo o seu tráfego de 2011 originado em dispositivos móveis. No Twitter, incríveis 55% do tráfego foram em mobile em 2011.

= Tremendas oportunidades

O mercado móvel está só no começo, sobretudo no Brasil.

Aquela pesquisa de 2011 sobre o consumidor móvel brasileiro, mostrava ainda que mais de 50% das pessoas desejavam que houvesse mais conteúdo móvel disponível. E 65% mostraram intenção de comprar um tablet.

Um estudo da Gomez em Julho de 2011, mostrou a gritante diferença entre as expectativas dos usuários mobile e a (ainda) triste realidade. 71% das pessoas esperam que um site móvel seja tão rápido quanto no Desktop mas para 46% a experiência foi de mais lentidão. E 57% das pessoas falaram ter tido problemas ao acessar sites em seus celulares.

São muitas oportunidades!

Para o Google, os imensos avanços de 2011 são apenas o começo da história do mundo móvel. E, eles falam também que 2012 será o grande ano de mobile.

Como atacar o mercado móvel?

Há basicamente dois caminhos: criar uma app mobile e criar um site mobile.

Apps

Apps dão uma excelente experiência para o usuário, por serem nativas e se integrarem muito bem com o aparelho. Existe a inconveniência da portabilidade – e mesmo você fazendo uma para iOS e outra para Android, não esqueça que existem zilhões de outros usuários (e 70% deles nem smartphone têm).

Jacok Nielsen, o papa da usabilidade, afirma que Apps dedicadas hoje provêem uma melhor experiência pro usuário. São mais integradas ao aparelho e conseguem minimizar as limitações com maior sucesso.

Mas talvez o ponto mais crítico para Apps seja o mais óbvio: elas precisam ser instaladas. Apps são ótimas para quem já é seu cliente, mas são uma barreira para converter novos clientes. Ninguém quer instalar uma nova App para cada empresa e serviço do mundo.

Aqui entra a Web mobile, uma área que eu particularmente vejo com muito potencial de crescimento.

E a conclusão daquele artigo do Jakob Nielsen sobre Apps serem melhores de UX hoje, é que a Web Mobile é bem melhor a longo a prazo e será a solução definitiva conforme os navegadores móveis forem evoluindo.

Web mobile

Muita gente acessa a Internet no celular e a maioria navegando por aí. E é péssimo abrir algum Site que não esteja otimizado para mobile. Mesmo nos smartphones mais modernos com telas maiores que permitem abrir sites normais, não há dúvidas que um site não otimizado para mobile traz uma pior experiência para o usuário. E isso prejudica suas vendas, trata mal potenciais clientes e até afeta negativamente sua marca.

Se quiser tirar uma lição desse post gigante e transformá-la em uma ação para esse ano, faça isso: crie já uma versão mobile do seu site.

E não é só para grandes portais ou redes sociais. É fato que as pessoas lêem muitas notícias em seus celulares e tablets, mas também lêem blogs e outros conteúdos. Também querem fazer compras online enquanto estiverem na rua. E querem receber um link qualquer por email ou Facebook e poder visualizá-lo no seu dispositivo. Querem apenas… navegar normalmente.

Todos os sites deveriam funcionar bem em dispositivos móveis.

Aqui você pode estar pensando no trabalho de criar uma versão nova do seu site para mobile. E que talvez não valha muito a pena o investimento, dado o (ainda) pequeno número de usuários. Mas você pode apenas adaptar seu site normal para todo tipo de dispositivo, como mostro nesse artigo sobre design resposivo.

Fizemos isso no site do Livro de Arquitetura Java da Caelum sem muito esforço. O chato é saber que, após ler sobre o livro em seu dispositivo, o usuário terá uma péssima experiência tentando comprá-lo caso não esteja em seu Desktop, já que as lojas virtuais brasileiras não estão prontas para o mundo móvel.

Mas é disso que trata esse post: despertar para a explosão do mundo mobile e incentivar que cada um faça sua parte para mudarmos o cenários mobile no Brasil.

E se você precisar de uma ajuda pra fazer Apps móveis, a Caelum têm cursos para Android e iOS. E nosso curso de desenvolvimento Web trata também de sites mobile.

Em outubro de 2011 a Apple lançou o iOS 5. Os desenvolvedores comemoraram bastante a disponibilização de uma funcionalidade chamada Automatic Reference Couting (ARC), que promete facilitar muito o desenvolvimento de aplicações iOS.

O desenvolvedor Objective-C precisa se  preocupar com o gerenciamento de memória em suas aplicações, basicamente isso significa alocar a memória que será usada pelos objetos, utilizá-la e depois liberar essa memória. Esquecer de liberar a memória, ou liberá-la enquanto ainda está em uso, são problemas que podem causar mau funcionamento da aplicação e inclusive o famoso “crash”, fazendo-a fechar inesperadamente.

O mecanismo para gerenciamento de memória usado em Objective-C é conhecido como reference counting. Para alocar a memória manualmente, enviamos uma mensagem alloc (uma invocação de método) para uma classe. Uma receita comum para a criação de objetos é invocar o método init para o retorno de uma invocação ao alloc, como no exemplo para instanciar uma NSArray:

NSArray *array = [[NSArray alloc] init]

O retorno dessa chamada a init é uma referência a um objeto pronto para uso, mas por quanto tempo esse objeto ficará em uso? Quando vamos permitir que ele seja varrido da memória?

Podemos invocar o retain para um objeto e isso soma 1 ao seu contador de referências. O método release é usado para subtrair 1 do contador, podendo possibilitar sua desalocação. Se esse balanço é comprometido (que é o que acontece quando esquecemos de invocar release para uma referência que não será mais usada) começam aparecer os tais vazamentos de memória. Esse processo manual de alocação e liberação de memória pode ser ilustrado como na imagem abaixo:

Aliás, é bastante didático utilizar o Instruments para poder aprender e visualizar o reference count de cada objeto em memória.

A ideia do ARC é facilitar, tirando a nossa responsabilidade de invocar retain e release: essa tarefa passa a ser executada por debaixo dos panos, com a ajuda do compilador. Para desenvolver código que aproveita ao máximo essa funcionalidade é preciso pensar na forma como os objetos se relacionam entre si durante a execução de seu programa. Se optar pelo ARC, você não poderá mais invocar retain e release explicitamente, essas invocações serão incluídas automaticamente pelo compilador. Mas como o compilador decide quando usar esses métodos? Ele considera os chamados modificadores de ciclo de vida, na declaração das referências.

Quando declaramos uma propriedade podemos utilizar esses modificadores de ciclo de vida, é isso que define como um objeto é tratado em termos de gerenciamento de memória. O modificador de ciclo de vida padrão para uma proprieade é o assign. Além dele podemos usar retain e copy. Com o ARC surgiram o strong e o weak.

assign

É o modificador padrão de ciclo de vida. A propriedade é apenas um ponteiro para o objeto atribuído a ela, não soma ou subtrai do contador de referências e portanto não interfere no gerenciamento da memória para o objeto referenciado. Se o objeto for liberado da memória em um outro ponto do código, a referência apontada pela propriedade se tornará inválida, pois passa a apontar para um endereço de memória que não existe mais. Uma invocação de método nessa propriedade irá causar um erro de execução.

@property NotaFiscal *nota;

retain

Atribuir um objeto para a propriedade declarada com esse modificador soma 1 ao seu contador de referências. Usamos retain para tornar explícito que essa propriedade, após atribuída, estará disponível enquanto o objeto que a declara estiver sendo utilizando:

@property(retain) Produto *produto;

copy

Usado normalmente quando a propriedade se refere a um objeto que pode ser mutável como strings, arrays e dictionaries. Todos esses tipos têm subclasses que podem gerar objetos mutáveis, porém quando passamos esses objetos como parâmetro a intenção normalmente é a de usar valores no método que recebe o parâmetro, não queremos permitir nenhuma alteração no objeto original. Como uma cópia defensiva, para não expor os atributos do nosso objeto a modificações indesejadas. Se esse for o caso podemos usar o modificador copy, isso vai garantir que o objeto seja copiado no momento da atribuição, essa cópia inicia sua vida com seu contador de referência valendo 1.

@property(copy) NSString *nomeCompleto;

Todos esses modificadores são tratados automaticamente pelo ARC. Isso significa que o próprio compilador vai se encarregar de procurar o melhor momento para adicionar envios de mensagem release para liberar a memória alocada por essas declarações, quando isso for necessário. O ARC também disponibiliza alguns modificadores novos, que vem de encontro com a ideia de livrar o desenvolvedor da preocupação com a alocação de memória:

strong

Quando um objeto é atribuído o contador de referências é incrementado, e a responsabilidade por fazer um decremento no contador é do objeto que possui a propriedade. O funcionamento é análogo ao do modificador retain.

@property(strong) Pessoa *cliente;

weak

Atribuir um objeto não incrementa o contador, semelhante ao modificador assign. Porém se a memória alocada para o objeto for liberada, a propriedade automaticamente torna-se nil. Essa diferença com relação ao assign é crucial pois se for invocado um método nessa propriedade (agora com o valor nil) não haverá um erro de execução, como se ela fosse ignorada.

@property(weak) Endereço *endereco;

A vantagem de usar strong e weak com o ARC é poder pensar no grafo de objetos e suas relações, sem se preocupar com o contador de referências. Uma preocupação que ainda temos é a de garantir que não haverá nenhuma referência cíclica impedindo algum objeto de ser liberado da memória. Imagine uma propriedade chamada cliente que contém uma referência com modificador strong para um objeto do tipo Pessoa. Esse objeto internamente faz uma referência para uma instância de Endereco, veja a declaração dessas classes:

@interface Pessoa
@property(strong) Endereco *endereco;
@end

@interface Endereco
@property(strong) Pessoa *pessoa;
// outras propriedades...
@end

@implementation Endereco
-(id) initComLogradouro:(NSString *)_logradouro eNumero:(NSString *)_numero paraPessoa:(Pessoa *)_pessoa {
    self = [super init];
    if(self) {
        self.pessoa = _pessoa;
    }
    // restante das atribuições...
    return self;
}

Podemos pensar em um sistema de cadastro que crie objetos do tipo Pessoa e Endereço, e faça as associações entre eles:

@interface Cadastro
@property(strong) Pessoa *pessoa;
- (void) cadastraPessoaComNome:(NSString *)nome;
@end

E essa poderia ser uma implementação para o método cadastraPessoa:

- (void) cadastraPessoa:(NSString *)nome {
    self.pessoa = [[Pessoa alloc] initComNome:nome];
    Endereco *e = [[Endereco alloc] initComLogradouro:@"Rua Vergueiro" eNumero:3185 paraPessoa:self.pessoa];
}

Dentro do método cadastraPessoa: é criado um objeto do tipo Pessoa, quando ele é atribuído à propriedade pessoa, o contador de referência é incrementado. O compilador irá inserir o envio da mensagem release para a propriedade pessoa da classe Cadastro. Mas perceba que o contador de referências para esse objeto foi incrementado também durante a execução do inicializador initComLogradouro:eNumero:paraPessoa:. Nesse momento o contador de referências para o objeto pessoa criado no método cadastraPessoa: tem o total de 2.

Para o gerenciador de memória liberar o objeto do tipo Cadastro utilizado no exemplo, uma das coisas que precisa ser feito é a liberação do objeto apontado pela propriedade do tipo Pessoa. Para isso será subtraído 1 do contador de referências, agora o contador tem 1, e o objeto referenciado por pessoa não será liberado da memória. Faz sentido! Mas não é o comportamento esperado, já que o objeto criado pelo cadastro deveria ser liberado da memória junto com o cadastro que o criou. É um vazamento!

Para evitar isso, podemos usar o modificador de ciclo de vida weak na propriedade pessoa de endereço, dessa forma a propriedade será nil quando esse objeto for liberado a qualquer momento, e não há o risco de uma referência para o objeto do tipo Pessoa ficar pendente (dangling). Uma forma de pensar nesse tipo de relacionamento é: endereço pertence a uma pessoa, portanto ele aponta para a pessoa de forma weak, se a pessoa for liberada, endereço não tem que interferir nisso. Já a pessoa quer ter certeza de que o endereço estará sempre disponível para ela, portanto ela aponta para o endereço de forma strong.

Vamos nos apoiar no ARC para corrigir o problema, podemos declarar as classes Pessoa e Endereço da seguinte forma:

@interface Pessoa

@property(strong) Endereco *endereco;

@end

@interface Endereco

@property(weak) Pessoa *pessoa;

@end

Existem modificadores específicos para variáveis de instância. Além do __strong e do __weak que funcionam da mesma forma que os análogos strong e weak utilizados em propriedades, existem também:

__unsafe_unretained

Semelhante ao _weak, porém a variável não recebe o valor nil quando a memória é liberada, o valor continua sendo um ponteiro que agora fica pendente. Equivalente ao assign para propriedades.

__autoreleasing

Libera a memória utilizada para armazenar um objeto passado como parâmetro para um método assim que ele retorna. Garante que dentro da execução do método o objeto vai estar disponível, mas só durante esse período.

Existem outros aspectos relacionados ao gerenciamento de memória com o ARC. Por exemplo: não é possível usar retain e release explícitamente com o ARC habilitado, isso irá gerar erros de compilação. Também não é possível usar objetos do tipo NSAutoreleasePool, para essa funcionalidade devemos utilizar um bloco @autoreleasepool. É possível desabilitar o ARC em um projeto para arquivos específicos, isso significa que você pode utilizar bibliotecas “pré-ARC”, mesmo se sua aplicação quiser usar este novo contador automático de referêncais.

Vale lembrar que o código para atribuição e leitura dos dados de uma proprieade com seus devidos retains serão gerados automaticamente pelo compilador ao usar a diretiva @synthesize.

No curso IP-67 da Caelum esse assunto é debatido e relacionado com vários outros aspectos do desenvolvimento para aplicações iOS.

Testes de aceitação são extremamente úteis quando se trata de verificar se as funcionalidades de um sistema estão se comportando corretamente sem que tenhamos de testar manualmente a aplicação, abrindo um navegador, navegando por ela e visualizar os resultados. Como poderíamos automatizar esses testes que envolvem realizar a navegação na aplicação?

Para isso ser possível, existem algumas ferramentas que permitem tal trabalho, simulando a interação de um usuário com a aplicação. Esse é o caso do Selenium que, com a assistência do JUnit, pode facilitar o trabalho de escrever tais testes.

Para vermos como o Selenium pode nos ajudar, vamos considerar uma página contendo simples HTML, que ao clicarmos em um link dela, seremos redirecionados para outra página.

 <a class="botao" href="outra_pagina.html">Clique Aqui</a>

Quando clicado, o link deve redirecionar para a outra_pagina.html, que tem o conteúdo:

</pre>
<h2>Estou na outra página!</h2>
<pre>

Com essas páginas, podemos escrever um teste, usando o Selenium, para que ele clique no link e em seguida verifique se estamos na outra página. Para isso, podemos escrever um pequeno teste com o JUnit usando a API do Selenium:

@Test
public void deveIrParaAOutraPagina() {
   WebDriver driver = new FirefoxDriver();
   driver.navigate().to("http://localhost:8080/pagina.html");

   driver.findElement(By.className("botao")).click();

   String texto = driver.findElement(By.tagName("h2")).getText();
   assertEquals("Estou na outra página!", texto);
}

Com a API do Selenium, esse código parece simples, não é? Mas imagine se precisássemos fazer várias ações e navegar por diversas páginas para conseguirmos testar uma funcionalidade. Um possível exemplo seria o login aplicação, onde uma possibilidade de teste é:

@Test
public void aoSeLogarNaAplicacaoDeveMostrarQueEstaLogado(){
   WebDriver driver = new FirefoxDriver();
   driver.navigate().to("http://localhost:8080/login.html");

   // pega uma referencia para o formulário de login que estará na tela
   WebElement formulario = driver.findElement(By.tagName("form"));

   // preenche usuário e senha
   driver.findElement(By.id("usuario")).sendKeys("joao");
   driver.findElement(By.id("senha")).sendKeys("123456");

   // submete o formulário
   formulario.submit();

   // na próxima tela, o login desse usuário deveria estar aparecendo
   String usuarioLogado = driver.findElement(By.id("usuario-logado")).getText();

   // verifica se o joao conseguiu fazer o login
   assertEquals("joao", usuarioLogado);
}

Apesar de funcionar perfeitamente, o código acima possui um grave problema: lê-lo já está extremamente mais complexo do que o teste que havíamos feito antes! Agora, imagine se estivéssemos escrevendo testes para uma funcionalidade que envolva interação com várias outras telas?

Para simplificar e organizar esse código de teste, vamos separar cada uma das telas em classes diferentes, ou seja, para a tela de login vamos criar uma classe chamada TelaDeLogin e para a página interna uma classe chamada PaginaInterna, dessa forma poderíamos ter o método loga com seguinte código para a TelaDeLogin:

public class TelaDeLogin {

   public void abre() {
      driver.navigate().to("http://localhost:8080/login.html");
   }

   public void loga(String usuario, String senha) {
      // pega uma referencia para o formulário na tela
      WebElement formulario = driver.findElement(By.tagName("form"));

      // preenche usuário e senha
      driver.findElement(By.id("usuario")).sendKeys(usuario);
      driver.findElement(By.id("senha")).sendKeys(senha);

      // submete o formulário
      formulario.submit();
   }
}

Note que o código acima ainda não compila, pois precisamos de uma referência para o WebDriver. Podemos passar a recebê-la via construtor:

public class TelaDeLogin {
   private WebDriver driver;

   public TelaDeLogin(WebDriver driver) {
      this.driver = driver;
   }

   public void abre() {
      // navega para a tela de login
   }

   public void loga(String usuario, String senha) {
      // código que usa o Selenium para fazer o login
   }
}

Dessa forma, podemos usar a nova classe TelaDeLogin no lugar do código do Selenium em nossas classes de teste. Com isso, o teste ficará parecido com:

public class TestesDeAceitacao extends SeleniumTest {

   private TelaDeLogin telaDeLogin;

   // Instanciamos a base de nossa aplicacao
   @Before
   public void setup() {
      WebDriver driver = new FirefoxDriver();
      this.telaDeLogin = new TelaDeLogin(driver);
   }

   // Efetuamos o teste
   @Test
   public void aoSeLogarNaAplicacaoDeveMostrarQueEstaLogado(){
      telaDeLogin.abre();
      telaDeLogin.loga("joao","123456");

      // na próxima tela, o login desse usuário deveria estar aparecendo
      String usuarioLogado = driver.findElement(By.id("usuario-logado")).getText();

      // verifica se o joao conseguiu fazer o login
      assertEquals("joao", usuarioLogado);
   }
}

O código do teste melhorou, mas ainda continua com problemas, um deles é que ainda usamos a API do Selenium diretamente dentro do teste e novamente, se ele fosse um pouco mais complexo, continuaria difícil de ler seu código. Como o trecho que ainda está usando o código do Selenium direto no teste diz respeito à página interna do sistema, podemos levar esse código para a classe PaginaInterna, dessa forma teremos:

public class PaginaInterna {
   private WebDriver driver;

   public PaginaInterna(WebDriver driver) {
      this.driver = driver;
   }

   public boolean estaLogado(String usuario) {
      String usuarioLogado = driver.findElement(By.id("usuario-logado")).getText();

      return usuarioLogado.equals(usuario);
   }
}

Dessa maneira, podemos fazer uma simples refatoração no nosso teste, para usar a nova classe implementada:

   @Test
   public void aoSeLogarNaAplicacaoDeveMostrarQueEstaLogado() {
      String usuario = "joao";
      telaDeLogin.abre();
      telaDeLogin.loga(usuario, "123456");

      boolean estaLogado = new PaginaInterna(driver).estaLogado(usuario);
      assertTrue(estaLogado);
   }

Agora estamos num nível melhor, mas continua tendo pontos para melhorar. O principal deles agora, é que toda troca de tela que existir em nosso teste, precisamos instanciar um objeto para a nova tela, passar o driver como parâmetro, para aí sim, podermos invocar o método. Note que ao fazermos o login com sucesso, nesse caso, sempre seremos redirecionados para a mesma página, sendo assim, poderíamos fazer o método loga já retornar uma instância de PaginaInterna para nós e assim, só precisaríamos chamar o método verificaSeEstaLogado:

public class TelaDeLogin {

   // construtor e atributo driver

   public PaginaInterna loga(String usuario, String senha) {
      // pega uma referencia para o formulário na tela
      WebElement formulario = driver.findElement(By.tagName("form"));

      // preenche usuário e senha
      driver.findElement(By.id("usuario")).sendKeys(usuario);
      driver.findElement(By.id("senha")).sendKeys(senha);

      // submete o formulário
      formulario.submit();

      return new PaginaInterna(driver);
   }
}

Essa alteração na classe TelaDeLogin nos permite encadear as chamadas dos métodos loga e verificaSeEstaLogado no nosso teste de aceitação:

   @Test
   public void aoSeLogarNaAplicacaoDeveMostrarQueEstaLogado() {
      String usuario = "joao";
      telaDeLogin.abre();

      boolean estaLogado = telaDeLogin.loga(usuario, "123456").estaLogado(usuario);
      assertTrue(estaLogado);
   }

Agora nosso teste está bem mais legível, e o código do Selenium todo encapsulado dentro de classes, que chamamos de PageObjects. Ainda há brechas que precisam de melhoras. Podemos fazer o método abre() retornar a própria instância de TelaDeLogin e, com isso, poderíamos ter todos os métodos encadeados, o que faria o teste ficar como:

   @Test
   public void aoSeLogarNaAplicacaoDeveMostrarQueEstaLogado(){
      String usuario = "joao";

      boolean estaLogado = telaDeLogin.abre().loga(usuario, "123456").estaLogado(usuario);
      assertTrue(estaLogado);
   }

Com isso, temos um código de teste bem mais legível, onde toda a API do Selenium está encapsulado dentro de classes que representam as páginas, formando os Page Objects.

Que outras ferramentas e práticas você utiliza para facilitar seus testes de aceitação?

Já fez seu site mobile? Explore o mercado que mais cresce no Brasil e no mundo com as melhores práticas de Web mobile.

No artigo sobre viewport, aqui do Blog, vimos como criar uma página com tamanho adequado aos diversos dispositivos que temos que lidar hoje em dia.

Se colocarmos um viewport com width=320, por exemplo, conseguimos criar uma página para iPhone e outros smartphones normalmente. Mas e se a página for aberta num iPad de 768px de resolução? Ou em um tablet Android de 600px de largura? Ou um smartphone Android de 533px em modo paisagem?

Criar sites específicos para cada tamanho de tela não é a melhor solução.

Podemos então colocar o viewport com width=device-width e codificar nosso HTML e CSS para usarem 100% da largura, flexibilizando nosso layout. Mas será que nosso layout vai ficar bonito tanto em um smartphone de 240px quanto num tablet com 1024px?

No último site mobile que fizemos, o do livro Arquitetura Java, usar um layout flexível deixava a página muito usável em telas pequenas (como num Nokia de 240px) mas não em telas maiores (como em um iPad):

Só fazer layouts flexíveis também não é a melhor solução. Precisamos ajustar o design de acordo com o dispositivo usado.

Media types

Desde muito tempo o CSS tem suporte para se definir regras que só valem em certo contexto. Os media types permitem que se use estilos diferentes em situações diferentes e sempre foram muito usados para distinguir a renderização na tela da impressão:

   <link rel="stylesheet" href="estilos.css" media="screen">
   <link rel="stylesheet" href="impressao.css" media="print">

Todos os navegadores modernos suportam esse media type print que é aplicado apenas quando vamos imprimir uma página (útil para esconder o menu de navegação ou aumentar a fonte do texto, por exemplo).

Alguns celulares antigos suportavam também o tipo handheld para estilos específicos para sites mobile. Os smartphones modernos como iPhone e Android, porém, ignoram o media type handheld pois são capazes de renderizar sites completos e não apenas as versões simples feitas para os celulares antigos.

Como então escrever CSS específico para mobile pensando em smartphones e tablets que não se encaixam no media querie handheld? Novos media queries!

CSS3 media queries

Melhor do que separar os dispositivos em desktop (screen) e mobile (handheld), os novos media queries permitem que foquemos principalmente no tamanho da tela onde vamos exibir o conteúdo.

É possível criar um CSS que só se aplique a tamanhos de tela de, no máximo, 320px por exemplo (como um iPhone em modo retrato):

<link rel="stylesheet" href="iphone.css"
      media="screen and (max-width: 320px)">

Existem diversas opções de media queries com bastante suporte. Além da max-width, podemos usar min-width, width e device-width – e todas as variações delas com height.

A diferença entre width e device-width é se estamos pensando em CSS pixels ou no tamanho do viewport. Geralmente não é boa prática depender do tamanho físico do aparelho então não usamos tanto device-width.

Uma decisão que precisa ser tomada é de se usar max-width ou min-width. O max é bom para quando temos um layout Desktop pronto e queremos adaptá-lo para dispositivos menores – vamos então definindo novas regras que se aplicam só aos dispositivos de no máximo certo tamanho. Já o min pode ser útil quando criamos um site só mobile ou começamos pelo mobile – nesse caso, é mais fácil ter um layout base e ir customizando para dispositivos maiores, com no mínimo certo tamanho.

Mais media queries

Além dos media queries de tamanho, aparelhos mais modernos suportam também um media querie que pega a orientação do dispositivo:

<link rel="stylesheet" href="phones.css"
      media="screen and (min-width: 320px) and (orientation: portrait)">

Isso pode ser útil para customizar a experiência do site de acordo com como o usuário está segurando o aparelho. É sabido, por exemplo, que um celular em modo retrato é mais usável com navegação na parte de baixo à esquerda; e, no modo paisagem, com navegação no topo e nas laterais.

Áreas quentes para toque num smartphone comum em retrato e paisagem

Além de declarar as media queries na tag <link> no HTML, podemos também fazer direto dentro do arquivo CSS (podemos juntar tudo num arquivo CSS só e economizar requests):

/* regra aplicada em todo lugar */
body { background: blue; }

/* aplica somente a partir de 320px */
@media screen and (min-width: 320px) {
   body { font-size: 80%; }
}

/* aplica somente a partir de 480px em landscape */
@media screen and (min-width: 480px) and (orientation: landscape) {
   nav { float: left; }
}

Há ainda como mirar dispositivos de alta resolução (como iPhones e iPads com Retina Display) com device-pixel-ratio para provermos imagens de melhor qualidade quando elas forem úteis. Ou ainda a opção (color) que permite distinguir entre dispositivos coloridos ou não (como um ereader ou Kindle).

Temos muitas outras opções de media queries na especificação do W3C e várias delas já disponíveis nos aparelhos de hoje.

Media queries comuns

E quais valores usar no projeto para adaptar para diferentes larguras? O ideal seria fazer as adaptações conforme seu layout exige (seria até possível fazer um layout só com porcentagens e sem media querie nenhum que funcione em diversos tamanhos de tela).

Mas se você pensa nos dispositivos mais comuns de hoje, existem algumas combinações de media queries famosas. O projeto 320andup por exemplo sugere que você faça um layout base pensando em 320px e depois adapte para outros tamanhos com:

@media print { }

@media only screen and (min-width: 480px) { }
@media only screen and (min-width: 600px) { }
@media only screen and (min-width: 992px) { }
@media only screen and (min-width: 1382px) { }

@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min-device-pixel-ratio: 1.5) { }

Há a regra para impressão e outras 4 pensando em tamanhos comuns de smartphones e tablets. A última regra foca em dispositivos com alta resolução como os Retina Display e Android modernos. (o uso da keyword only serve apenas para esconder essas regras de navegadores antigos que não suportem media queries mas suportam o media type screen)

No nosso site arquiteturajava.com.br que suporta mobile, usamos o layout base pensando em 240px e os seguintes media queries:

@media screen and (min-width:320px) { }
@media screen and (min-width:480px) { }
@media screen and (min-width:600px) { }
@media screen and (min-width:768px) { }
@media screen and (min-width:992px) { }

Nós inclusive abrimos o código do site no Github para servir de exemplo de design mobile com media queries e viewport.

Site do livro aberto em tudo quanto é dispositivo: tablet, ipad, smartphone, tv, desktop, ereader

Conclusão

As novas media queries do CSS3 são muito úteis para adaptar nosso site a diferentes resoluções. E o melhor é que contam com excelente suporte nos navegadores mobile.

O título desse post não está muito correto. Apesar das media queries serem fundamentais para a Web mobile (e terem nascido nesse meio), todo os navegadores Desktop modernos também suportam os media queries de CSS3 (até o IE). Usar max-width, por exemplo, vai fazer com que o layout se ajuste ao tamanho da janela do navegador.