O Conexão Java 2012 foi um sucesso. Em São Paulo, 400 participantes lotaram o auditório para participar de um evento com novo formato: um problema foi proposto e trabalhado em todas as palestras, guiando quem está começando na plataforma Java. O objetivo era criar uma aplicação Android que consumisse JSON do cloud, para saber que ônibus passavam pelos pontos mais próximos de você. Mais fotos no facebook.

Como houve muita codificação ao vivo, os slides não mostram tudo que ocorreu no evento. Enquanto não lançamos os videos de algumas das palestras, publicamos o código fonte utilizado, além dos slides. Eu comecei falando um pouco mais da importância da JVM e mostrando como funciona o bytecode e as otimizações do JIT. Em seguida, Mauricio Aniche elaborou a modelagem do nosso domínio de ônibus, mostrando alguns princípios de orientação a objetos, para serem complementados pela Cecilia, que demonstrou o uso das coleções do Java.

Adriano Almeida explicou um pouco de MVC para codificar com o VRaptor, e depois Alberto Souza demonstrar onde JSF se enquadra. Guilherme Silveira fez código ao vivo com Hibernate, persistindo o nosso modelo de Onibus. No final, Hanneli passou o conceito de cloud, praticando do OpenShift, para então Erich Egert codificar o que precisava em uma aplicação Android. O evento terminou com divertidas lightning talks e o sorteio de um Playstation 3 e outros brindes.

Foi uma comemoração de 10 anos do GUJ, 8 anos da Caelum e recuperar um evento focado a quem está adquirindo suas primeiras experiências na plataforma. Nos vemos nos próximos eventos. Se você está começando com Java, não deixe de ver nossas apostilas e cursos.

CDI é a especificação do Java EE 6 que cuida da parte de injeção de dependências. E, além de ser oficial e estar incluída em todos os servidores de aplicação, é tão boa e produtiva que já tem gente questionando o papel do Spring nos dias de hoje.

O CDI se encaixa muito bem em todo tipo de projeto Java. Se você usa JSF2, usar CDI é natural, como mostramos no nosso curso FJ-26. Mas mesmo para aplicações Web simples, com apenas Servlets, o CDI é um grande ganho.

Habilitando CDI

Habilitar o CDI no projeto é muito simples. Se você já está usando um servidor Java EE 6, basta criar um arquivo vazio chamado beans.xml na pasta META-INF do seu projeto (ou WEB-INF num projeto web). Esse é um simples arquivo de marcação e apenas sua presença já faz com que o servidor habilite o suporte a CDI e escaneie suas classes automaticamente.

Se você estiver usando Tomcat, Jetty ou outro servidor antes do Java EE 6, ainda é possível habilitar o CDI copiando e configurando o JAR de alguma de suas implementações. Vamos usar o Weld, a implementação de referência e a mais usada (já embutida no JBoss e no Glassfish).

No caso do Tomcat, os passos de configuração são:

• Baixar a última versão do Weld no site dele
• Copiar o weld-servlet.jar pra pasta WEB-INF/lib
• Criar um arquivo META-INF/context.xml
• Acrescentar as configurações do Weld no web.xml

Feito isso, basta criar o tal arquivo META-INF/beans.xml vazio no projeto.

Tudo são beans

Com o CDI habilitado, praticamente todas as classes do projeto são consideradas managed beans e, portanto, passíveis de injeção e de serem injetadas. Podemos usar com CDI toda classe pública com um construtor público padrão ou algum que receba parâmetros e esteja anotado com @Inject.

Aliás, essa anotação @Inject é a base de todo o CDI: é ela quem permite a injeção de dependências e devemos usá-la nos pontos que queremos injeção automática, sejam construtores, setters ou atributos privados.

Essa anotação, embora usada com CDI, faz parte na verdade de uma outra especificação, a JSR330. Essa é uma especificação bastante simples, com apenas algumas anotações relacionadas à injeção de dependências no pacote javax.inject. A ideia é ter um conjunto básico de recursos para injeção a serem suportados em todos os frameworks do tipo – além do CDI, Spring, Google Guice, PicoContainer e outros frameworks suportam essas anotações.

Primeira injeção

Imagine que temos uma classe ProdutoDAO que cuida de persistir objetos Produto:

public class ProdutoDAO {
   public void adiciona(Produto produto) {
      // ... implementação
   }
}

Essa classe simples, sem nenhuma configuração particular, pode ter objetos injetados em qualquer outro ponto da aplicação. Basta usar a anotação @Inject:

public class ProdutoController {
    @Inject private ProdutoDAO dao;

    public String inserir() {
        Produto p = // ...
        dao.adiciona(p);
        return "Produto adicionado!";
    }
}

Poderíamos também ter feito a própria classe ProdutoDAO receber um EntityManager da JPA para trabalhar com a persistência:

public class ProdutoDAO {
   @Inject private EntityManager manager;

   public void adiciona(Produto produto) {
      manager.persist(produto);
   }
}

Produção de objetos

Sempre que encontrar um ponto de injeção, o CDI vai tentar instanciar a classe sendo referenciada. No caso do DAO anterior, ao criá-lo, o CDI vai tentar dar new em EntityManager.

Mas EntityManager, assim como vários outros objetos, não pode ser criado tão facilmente assim. A criação de um EntityManager exige a chamada do método createEntityManager no EntityManagerFactory correspondente. É um objeto com um processo de fabricação particular.

Nos Design Patterns, sempre que encontramos esse tipo de cenário, criamos uma Factory para aquele objeto. É um simples método que encapsula a criação não-trivial do objeto em questão. Com CDI é a mesma coisa.

Vamos criar um método em uma classe qualquer do sistema que cuide da produção de objetos EntityManager. E podemos indicar ao CDI que queremos que ele use esse método sempre que alguém pedir a injeção de um EntityManager. Fazemos isso com a anotação @Produces:

public class ProdutorEntityManager {
   private static EntityManagerFactory factory = Persistence.createEntiyManagerFactory("default");

   @Produces
   public EntityManager criaEntityManager() {
      return factory.createEntityManager();
   }
}

Agora, todos os pontos de injeção que precisarem de EntityManager irão invocar essa fábrica anotada com @Produces.

Escopos

Mas quantos EntityManagers vamos criar com o código acima? Por padrão, toda dependência no CDI possui um escopo chamado Dependant. Isso é: será instanciada tantas vezes quanto quem estiver chamando for. Certamente não é o que queremos com nosso EntityManager.

É usual criar um EntityManager por requisição em uma aplicação Web. Podemos indicar isso apenas anotando o método produtor com @RequestScoped:

public class ProdutorEntityManager {

   @Produces @RequestScoped
   public EntityManager criaEntityManager() {
      // ...
   }
}

Agora, um novo EntityManager será criado associado a um request. Se mais de uma classe pedir um EntityManager durante o mesmo request, a mesma instância será passada, evitando desperdício de recursos. Outros escopos comuns são @SessionScoped e @ApplicationScoped.

Mais: como definimos o escopo da dependência, temos agora uma visão clara de seu ciclo de vida. O objeto durará apenas um request, e será descartado quando o request acabar.

O CDI nos deixa, inclusive, executar algo na fase de descarte da dependência, ao final da requsição. No nossa caso, será muito útil para chamar o close no EntityManager. Basta criar um método que receba a dependência a ser descartada e anotar o parâmetro com @Disposes:

public class ProdutorEntityManager {

   @Produces @RequestScoped
   public EntityManager criaEntityManager() {
      // ...
   }

   public void finaliza(@Disposes EntityManager manager) {
      manager.close();
   }
}

O método finaliza será chamado automaticamente pelo CDI ao final do request e fará o fechamento do EntityManager.

Use CDI no seu próximo projeto

O CDI é extremamente completo e poderoso. Esse artigo mostrou apenas o básico e o início do trabalho. Mas seu container de injeção typesafe com anotações simples e produtivas tem muitos outros recursos.

Aqui mesmo no blog já mostramos como fazer a produção de dependências de tipos genéricos. Além disso, há recursos como qualifiers, interceptadores, decorators, eventos e muito mais. Mostramos várias dessas funcionalidades no curso FJ-26 da Caelum, inclusive com o JBoss Seam 3, uma ótima companhia para o CDI.

E você, o que acha do CDI? Tem usado em seus projetos?

Como funciona exatamente o new no JavaScript? Podemos utilizá-lo na frente de uma invocação de uma função. Curiosamente, de qualquer função. Quando usado, o new cria um novo objeto e o atribui a palavra chave this de dentro do escopo da função invocada. Podemos então adicionar atributos a esse objeto:

var Pessoa = function(nome, email) {
    console.log("criando nova pessoa");
    console.log(typeof(this));
    this.nome =  nome;
    this.email = email;
}

var joao = new Pessoa("João da Silva",  "joao@da.silva"); // criando nova pessoa, object
console.log(joao.nome); // João da Silva
console.log(joao.email); // joao@da.silva

Apesar de não existir nenhuma instrução de retorno explícita na função Pessoa, é possível armazenar em joao uma referência para o objeto criado no momento da invocação. O operador new garante que o objeto referenciado pela palavra chave this seja retornado ao término da função.

Mas e se houver uma instrução de retorno explícita? Nesse caso o retorno é influenciado pelo operador new. Se o tipo do retorno for diferente de object então será retornado o objeto referenciado por this. Com isso em mente, veja no exemplo a seguir como o operador new é capaz de interferir no retorno de uma função. Vamos criar uma função que retorna um objeto do tipo string. Primeiro ela será invocada através do padrão simples e depois usando o new, veja que o objeto retornado muda de acordo com o padrão de invocação:

var Curso = function(nome) {
    this.nome = nome;
    return "curso "+ nome;
}

// Invocando como função
var stringParaCS01 =  Curso("CS01");
typeof(stringParaCS01); // "string"
console.log(stringParaCS01); // curso CS01

// Invocando como construtor
var objetoParaWD47 = new Curso("WD47");
typeof(objetoParaWD47); // object
console.log(objetoParaWD47.nome); // WD47

Quando a função referenciada por Curso foi criada, a intenção era usá-la sempre como uma função construtora. Mas nada nos impediu de usar o padrão simples de invocação com essa função. A única pista que temos de que ela deve ser usada como um construtor é a convenção de usar a primeira letra maiúscula no nome da referência. Curso, Pessoa indica que queremos que as funções sejam usadas para criar objetos, diferente de alert, log, etc.

Esse é um ponto que precisa de nossa atenção. Considere o caso da função Pessoa que adiciona atributos ao this quando invocada. Se por um acaso em algum momento esquecermos de que ela é na verdade uma construtora, e a invocarmos de forma simples: var p = Pessoa(), serão criadas as variáveis nome e email em window! Isso porque, como vimos no post anterior, quando uma função é invocada de forma simples, a palavra chave this é associada com window.

Essa ambiguidade das funções criadas para serem construtoras é o alvo de uma das críticas quanto ao uso do operador new feita pelo Douglas Crockford, em seu excelente livro JavaScript The Good Parts.

Mas e se a função retornar um objeto do tipo object explicitamente, usando a palavra chave return? Nesse caso um novo objeto será criado, atribuído ao this, mas não será retornando ao final da execução. No exemplo a seguir vemos que apesar de atributos serem criados no objeto referenciado por this, eles não são acessíveis fora da função, já que o retorno é um outro objeto:

var Curso = function(nome, duracao) {
    this.duracao = duracao;
    var novoCurso = {"nome" :  nome, "horario" : "8h00"};
    return novoCurso;
}

var wd47 = new Curso("WD47", 20);
typeof(wd47); // object
typeof(wd47.duracao); // undefined
console.log(wd47.nome); // WD47

É um bom momento para lembrar que uma instância de Array no JavaScript, é na verdade do tipo object, podemos verificar isso através do seguinte código:

var novoArray = new Array();
typeof(novoArray); // object
var outroArray = ["oi"];
typeof(outroArray); // object

Portanto se sua função construtora retornar um Array, o uso do operador new na invocação não vai interferir no retorno.

Mas por que se preocupar em usar uma função para criar objetos se é possível (e comum) cria-los com a notação literal? Na notação literal, não temos como garantir consistência do estado do objeto no momento de sua criação. Mesmo que todas as pessoas precisem ter um email válido, podemos escrever:

var ricardo = {
    nome: "Ricardo Valeriano",
    email: "ricardovaleriano" // email invalido!
}

Já com uma função construtora Pessoa, esses dados seriam necessariamente passados a ela:

ricardo = new Pessoa("Ricardo", "ricardovaleriano");

Sabemos que quando uma função é invocada através do operador new, um instância de object é criada e atribuída a this. Sendo assim podemos ter algum tipo de processamento envolvido na criação de um objeto e uma função construtora permite isolar essa lógica caso ela se torne complexa:

var Pessoa = function(nome, email) {
    this.nome =  nome;
    if (notValid(email)) this.email = "invalido";
    else this.email = email;
}

Um outro aspecto importantíssimo sobre os objetos criados pelas funções construtoras tem um link para o protótipo da função que o criou. Essa é uma característica marcante da linguagem, explorada por frameworks como o jQuery para aumentar suas capacidades. A forma como o JavaScript lida com protótipos permite adicionar métodos em todos os objetos de determinado tipo, mesmo que esse tipo seja nativo da linguagem como é o caso de uma string.

Para entender melhor vamos alterar o protóptio da função Pessoa para garantir que, se um email não for passado como parâmetro no momento da criação, a pessoa seja criada com o email padrão contato@caelum.com.br. Para isso vamos alterar o protótipo de Pessoa, adicionando o atributo email com o valor padrão desejado no protótipo. Também vamos adicionar uma verificação em nossa função Pessoa: só iremos atribuir o parâmetro email para o atributo email em this caso esse atributo tenha sido passado como parâmetro:

var Pessoa = function(nome, email) {
     this.nome =  nome;

     // verifica se o e-mail foi preenchido
     if (email) {
          this.email = email;
     }
}

Pessoa.prototype.email = "contato@caelum.com.br"

var ricardo = new Pessoa("Ricardo");
console.log(ricardo.email); // contato@caelum.com.br

var joao = new Pessoa("Joao da Silva", "joao@da.silva");
console.log(joao.email); // joao@da.silva

Perfeito! Usando essa característica da linguagem podemos alterar o protótipo das que constroem os tipos nativos do JavaScript, como as funções String, Array, Number ou outra qualquer. Qualquer atributo ou função adicionado ao protótipo de uma dessas funções ficará disponível em qualquer objeto do tipo gerado por elas. Vamos alterar o prototype da função construtora String e adicionar uma função a ele. A partir desse momento qualquer string criada tem disponível a função adicionada ao protótipo, veja:

String.prototype.paraNumero = function() {
  if(this == "um") {
    return 1;
  }
}

console.log("um".paraNumero()); // 1

Existem muitos outros detalhes envolvidos com o uso de protóptios em JavaScript, alguns deles abordados no curso WD-47 da Caelum. Nos vemos por lá!

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. A 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.