Como adaptar seu site para telas retina

Telas com alta densidade de pixels, chamadas pela Apple de "telas Retina", já são uma realidade. Temos smartphones, tablets e notebooks com essa incrível resolução.

Se considerarmos a porcentagem de visitantes utilizando essas telas, pode parecer pouco, mas esse é um número que só vai crescer a cada dia. Como diz o Marco Arment, esses visitantes representam o futuro. Não é como a porcentagem de pessoas utilizando o Internet Explorer 6, que só tende a diminuir, nesse caso o número só vai aumentar.

Agora, como adequar seu site para essas telas? Como primeiro passo, siga esse guia. A biblioteca Retina.js pode lhe ajudar a prover imagens de alta resolução apenas em dispositivos compatíveis, economizando largura de banda para os outros dispositivos.

Alterar as imagens do site é apenas o primeiro passo. Com isso feito, cabe a você identificar as áreas que não estão com boa aparência. Talvez trocar a fonte utilizada, ajustar outros elementos do site... mas isso só vendo o site em uma tela Retina pra poder dizer.

Validando bindings usando Reflection

Em um projeto que estou trabalhando percebi a facilidade de criar problemas de binding. Basicamente, ao renomear uma simples propriedade do modelo os bindings ligados a ela param de funcionar. O pior disso é que, para saber que há um problema neles, só mesmo executando as telas uma a uma. Nenhum erro de compilação é gerado.

Pra resolver esse problema, resolvi criar um teste que seja executado automaticamente no build e verifique qualquer problema nos bindings.

Relacionando o componente ao modelo

Fazer a validação do binding a princípio é bastante simples, basta buscar cada propriedade do componente que está ligada ao modelo e verificar se o modelo contém a propriedade com o nome definido no componente. Por exemplo, em um ComboBox, pegamos o nome definido no DisplayMember e buscamos no modelo se existe uma propriedade com o nome correspondente.
Porém, há um pequeno problema, no componente não há nenhuma informação dizendo qual o modelo ao qual ele está relacionado. Sem essa informação, não tem como fazer a validação.

Nesse ponto procurei criar uma forma de descobrir qual modelo está relacionado ao componente.

A convenção

O projeto está sendo desenvolvido em WinForms e adotamos o padrão MVP, mais especificamente o Passive View. Como você já deve saber, no MVP temos a camada de View (exibição) separada do Presenter (lógica da tela). A view apenas recebe os dados a serem exibidos.

Olhando a view pude ver um padrão na atribuição de valores utilizados no binding:

class View 
{ 
  public IEnumerable<Usuario> Usuarios 
  { 
    set{ algumGrid.DataSource = value; }
  } 
}

Fica claro que, ao fazer um binding temos:

• uma propriedade do tipo IEnumerable<T>;
• a propriedade permite escrita (contém um set);
• dentro da propriedade atribuímos o valor ao DataSource do componente.

Com essas informações já temos uma base de como podemos verificar o binding.

Buscando o modelo correspondente ao componente

Com essa convenção, é possível descobrir quais componentes fazem binding e qual o modelo correspondente. Para isso temos de fazer duas coisas:

1. buscar todas as propriedades das telas que sejam do tipo IEnumerable<T> e que contenham um set;
2. para cada propriedade, obter o componente para o qual está sendo atribuído o valor.

O primeiro passo é bastante simples, via reflection conseguimos ter essa informação:

private IEnumerable<PropertyInfo> GetProperties(Type type)
{
  return type.GetProperties()
      .Where(x => x.CanWrite && EhLista(x))
}

private bool EhLista(PropertyInfo propertyInfo)
{
  return TipoEhEnumerable(propertyInfo.PropertyType) ||
    propertyInfo.PropertyType.GetInterfaces().Any(x => TipoEhEnumerable(x));
}

private bool TipoEhEnumerable(Type type)
{
  return type.IsGenericType && type.GetGenericTypeDefinition() == typeof(IEnumerable<>);
}

O segundo passo é um pouco mais complicado. Precisamos analisar o código executado, buscando o componente ao qual é atribuído o valor. Via reflection não temos acesso fácil ao código que está sendo executado, para isso foi necessário uma biblioteca externa. Basicamente, foi necessário analisar o MSIL à procura do componente.

Finalmente, Validando os bindings

Agora que já temos todas as informações necessárias, fazer a validação dos bindings é simples. Basta pegar cada propriedade do componente que faz o binding e verificar se o campo existe no modelo. Essa verificação varia conforme o componente, por exemplo, em um ComboBox simplesmente verificamos o DisplayMember e o ValueMember. Em um grid, por sua vez, é necessário verificar essas propriedades para cada uma das colunas.

Tendo a validação pronta, bastou criar um teste que busca os problemas de binding e reporta cada erro encontrado.

Código fonte de exemplo

Pra entender melhor isso, o mais fácil é olhar o código fonte.  Disponibilizei o código no GitHub, nesse repositório.

Caso você ainda não conheça o Git, recomendo a leitura desse artigo.

Criando um protótipo rapidamente com Balsamiq Mockups

Frequentemente precisamos criar um protótipo de tela, seja simplesmente para mostrar uma idéia ou para mostrar para o cliente e verificar se é isso mesmo que ele deseja.

Nesse momento temos duas opções:

• Criar o protótipo real, exatamente da maneira como será o resultado final;
• Criar um esboço, destacando apenas aquilo que nos interessa;

Eu evito ao máximo ter que criar um protótipo fiel a realidade, primeiramente pelo trabalho, mas principalmente porquê isso acaba virando um compromisso. Na hora de implementar somos obrigados a seguir a risca aquele protótipo, e como bem sabemos, na hora de implementar nem sempre podemos seguir a risca o que desenhamos.

Minha primeira opção ao criar um esboço é o bom e velho papel e caneta, ou um quadro branco se disponível. Porém, na maioria das vezes isso não é suficiente, precisamos enviar a imagem por e-mail a outras pessoas, anexá-la a documentos, etc. Nesse caso, como não tenho habilidades artísticas e tampouco sei trabalhar muito bem com ferramentas de edição gráfica acabo optando pelo Paint. Bem, o Paint até que é rápido pra se desenhar, fácil, mas deus queira que eu não tenha que refazer algo!!

Descobri agora um software muito bom para isso, é o Balsamiq Mockups. Simplesmente ótimo! É exatamente aquilo que eu procuro ao criar um esboço. As principais características que posso destacar são:

• Bastante intuitivo – em poucos minutos usando a ferramenta já sabemos como tudo funciona;
• Rápido de criar;
• Facilmente alterável – cada elemento na tela é um “componente", podemos modificá-los a qualquer momento;
• Não requer habilidades artísticas;
• E principalmente, tem cara de esboço. Não precisamos nos ater a detalhes. Nos focamos no fundamental apenas.

O mais legal é que já criaram até um site com vários componentes e layouts comuns, como por exemplo a figura abaixo:


A única coisa que talvez esteja faltando é a possibilidade de criar nossas próprias bibliotecas de componentes. Porém, pelo visto, isso já está sendo desenvolvido.

No site do fabricante você encontra maiores informações do produto: Balsamiq.