Cutting Edge
Desenvolvimento de site para celular, Parte 2: Projetar
Há alguns mitos sobre o desenvolvimento de site para celular que se originam da ideia de que uma solução para celular é um desdobramento de um site para desktop existente. Acho que o termo desdobramento é bastante apropriado para descrever o relacionamento entre um site para celular e um site para desktop. O problema crucial diz respeito aos detalhes de como você realmente desdobra o site para celular do site para desktop completo.
Você quer proporcionar aos usuários a melhor experiência de navegação para o dispositivo que eles têm, seja um PC normal, um smartphone, um tablet ou um telefone celular antigo. (Estou ignorando uma família emergente de dispositivos de tela grande como smart TVs, que exigirão sua própria renderização ad-hoc no futuro próximo.) Você também quer apresentar aos usuários um conjunto de páginas que podem ser mais bem visualizadas no dispositivo solicitante. Como você selecionaria a marcação que melhor se adapta a um determinado dispositivo? Em minha opinião, esse é um ponto sensível e merece um pouco de atenção e análise para evitar que você acredite nos mitos e ignore as condições do mundo real.
O mito de um site único
A maioria dos desenvolvedores reconhecem a necessidade de se ter um site para celular e um site para desktop que pareçam diferentes um do outro. Os tamanhos de tela são diferentes, a capacidade de computação é diferente e os casos de uso, especialmente, serão menos e muito diferentes em um site para celular. No entanto, a ideia de se criar apenas um site que automaticamente se ajuste a diferentes resoluções é atraente para muitos desenvolvedores. Mas também pode ser um caminho perigoso com mais contras do que prós. Realisticamente, o equilíbrio de prós e contras dependerá da natureza do aplicativo: quanto mais sofisticado for o site, mais contras e menos prós. Exatamente, o que significa ter um único site que se adapte a diversos dispositivos? Muitos desenvolvedores têm más lembranças de quando, apenas alguns anos atrás, se não ainda hoje, criar um site era uma questão de se livrar da bagunça de diferentes navegadores (desktop) e recursos de renderização diferentes. Por essa razão, a maioria dos desenvolvedores dão as boas-vindas à ideia de um único site que os usuários podem visitar com qualquer dispositivo (laptops, tablets, telefones, leitores eletrônicos, smart TVs, etc.), mas com uma experiência diferente.
O ponto é que com navegadores de desktop a maior parte das diferenças está no espaço de renderização. Em vez disso, os dispositivos móveis adicionam uma dimensão a mais ao problema: recursos diferentes. Assim, o objetivo deve ser criar um site que automaticamente forneça a experiência mais apropriada a diferentes dispositivos em vez de uma ênfase excessiva na renderização mais apropriada do conteúdo.
Parece uma diferença sutil? Bem, a adaptação do lado do cliente versus a adaptação do lado do servidor de conteúdo móvel é um ponto aberto atualmente.
Para mim, a ideia de apenas um site que forneça o mesmo conteúdo ao qual o navegador se ajusta de acordo com o dispositivo sendo utilizado não funciona como regra, mas pode funcionar como exceção. O mito do site único está baseado na capacidade do navegador de selecionar automaticamente a mais apropriada folha de estilos CSS dadas algumas características físicas do dispositivo. Vamos descobrir mais.
Consultas de mídia do CSS
Introduzidas com o CSS3, as consultas de mídia são um recurso do navegador destinadas a simplificar o projeto de sites que podem ser consumidos por meio de dispositivos de diferentes tamanhos de tela. Deve ser observado que o termo dispositivo nesse contexto específico também inclui laptops e PCs desktop. Por essa razão, o tamanho de tela pode variar de 24 polegadas de um monitor de desktop a 3 polegadas da maioria dos smartphones.
A ideia por trás das consultas de mídia do CSS é que você crie um site com um único conjunto de funções e, em seguida, aplique diferentes estilos de CSS a ele carregando uma folha de estilo diferente para mídias diferentes. O grande aperfeiçoamento trazido pelo CSS3 é que a mídia da página de tela agora pode ser restrita a todos os dispositivos que correspondam a um conjunto de determinadas regras. Vejamos um exemplo de uma consulta de mídia:
<link type="text/css"
rel="stylesheet"
href="downlevel.css"
media="only screen and (max-device-width: 320px)">
Uma vez colocada em uma página da Web (ou exibição ASP.NET MVC), a marcação anterior vinculará o arquivo downlevel.css apenas se a página for exibida por meio de um navegador com uma largura de 320 pixels ou menor. Usar alguns dos elementos anteriores permite otimizar a renderização de qualquer página em dispositivos de diferentes tamanhos de tela. Felizmente, a regra da folha de estilo é aplicada dinamicamente e também ajusta o conteúdo da página quando o usuário redimensiona a janela do navegador no desktop.
Deve ser observado que em consultas de mídia do CSS, não há verificação explícita do tipo de navegador, se ele é móvel ou de desktop; tudo o que importa é a largura efetiva da tela. No entanto, ao usar uma consulta de mídia para filtrar navegadores com uma largura maior que 320 pixels, você está certamente selecionando todos os dispositivos móveis e telefones celulares com esse tamanho de tela.
A palavra-chave only da consulta de mídia deve ser adicionada com o único propósito de ocultar a instrução de consulta de mídia de navegadores que não dão suporte às consultas de mídia. Na realidade, esses navegadores não entendem o tipo de mídia e, felizmente, continuam com sua renderização. É um pensamento comum atualmente que simplesmente adicionar consultas de mídia a um site o torna pronto para clientes móveis. Minha opinião é um pouco diferente. As consultas de mídia do CSS tornam o conteúdo da página mais adequado aos dispositivos móveis, mas não ajudam de maneira nenhuma na otimização do site móvel para outros aspectos críticos como o número de solicitações HTTP por página e a quantidade de dados baixados.
Além disso, as consultas de mídia podem discernir apenas um número limitado de propriedades do navegador. A documentação completa sobre consultas de mídia pode ser encontrada em bit.ly/yOuW7q.
As propriedades das consultas de mídia do CSS dizem algo sobre o dispositivo, mas não tudo o que você talvez precise saber. Por exemplo, você não tem nenhuma pista sobre o sistema operacional, se o dispositivo é móvel ou não, se é um tablet ou uma smart TV ou talvez ou bot. Da mesma forma, com consultas de mídia do CSS, você não tem nenhuma ideia se o navegador solicitante dá suporte à manipulação de Asynchronous JavaScript and XML e Document Object Model, como ele lida com HTML5 e jQuery Mobile, ou qual tipo de marcação ele prefere.
Sendo um recurso do CSS, as consultas de mídia são processadas pelo subsistema CSS do navegador. Resulta que as consultas de mídia podem selecionar apenas um conjunto de estilos de elemento que ocultam ou redimensionam alguns elementos que são muito grandes ou que podem ser reduzidos em uma tela pequena. Com as consultas de mídia do CSS, você ainda paga os custos de baixar e manter esses elementos na memória mesmo quando eles não estão sendo exibidos. Você pode usar JavaScript nas páginas para baixar de forma programática ou configurar imagens. Dessa maneira, elementos pesados podem ser gerenciados de forma mais otimizada. No entanto, esse trabalho extra depende de você.
Por último, mas não menos importante, as consultas de mídia exigem um navegador que dê suporte a CSS3. Isso significa que as consultas de mídia do CSS funcionam muito bem na maioria dos smartphones, mas não em dispositivos antigos, e nem mesmo no Windows Phone 7. Você pode optar por uma solução para todos os navegadores para as consultas de mídia obtendo um plug-in do jQuery em bit.ly/JcwwFY. No entanto, nesse caso também, não há garantia de que o navegador móvel no qual você talvez esteja usando esse plug-in possa realmente executar jQuery.
De modo geral, as consultas de mídia do CSS não são uma tecnologia destinada especificamente ao desenvolvimento para celular. No entanto, a flexibilidade das consultas de mídia do CSS torna-as atraentes de usar para fornecer uma única base de código a diferentes dispositivos. Elas podem ser um solução em alguns casos, mas as consultas de mídia do CSS não são o caminho a seguir para simplesmente nenhum cenário.
Diversos serviços
O caminho no lado do servidor do desenvolvimento para celular é baseado na ideia de que o site recebe uma solicitação, obtém o agente do usuário e usa essas informações para descobrir os recursos efetivos do navegador. Em seguida, armado com esse conhecimento, o site de maneira inteligente decide qual seria o conteúdo mais apropriado para o dispositivo solicitante.
Como você descobriria sobre os recursos do navegador? No momento, a estratégia mais efetiva parece ser usar um DDR (Device Description Repository), ou seja, um banco de dados que armazena quase todas as propriedades possíveis de quase todos os dispositivos, e isso é constantemente atualizado à medida que novos dispositivos chegam ao mercado. De que maneira um DDR é diferente de um objeto Request.Browser do ASP.NET? De certa forma, o objeto Request.Browser pode ser visto como um DDR simples que contém boas informações sobre navegadores de desktop, mas não particularmente informações precisas sobre dispositivos móveis.
O número de modelos diferentes de dispositivos móveis está na ordem de milhares e em crescimento. As propriedades que um desenvolvedor pode achar interessantes para cada perfil de dispositivo em um caso de uso específico pode variar de forma significativa, mas se a união de todas elas for considerada, você poderá facilmente chegar a poucas centenas. Que opções você tem hoje para obter informações precisas sobre o dispositivo?
O DDR chamado WURFL (Wireless Universal Resource File) é um banco de dados XML que atualmente contém mais de 15.000 perfis de dispositivos móveis e combina meio milhão de cadeias de caracteres de agente do usuário. Cada perfil contém mais de 500 recursos. WURFL é uma estrutura de software livre lançada sob um esquema clássico de licença dupla, AGPL v3 e comercial. WURFL está também disponível como um serviço em nuvem e alguns planos básicos, limitados a algumas propriedades, são gratuitos. Para obter mais informações, visite scientiamobile.com. WURFL não é o único DDR lá, mas WURFL pode ser considerado o padrão de fato. Entre outras coisas, WURFL é empregado na plataforma móvel do Facebook e do Google. WURFL tem APIs para o PHP, Java e o Microsoft .NET Framework, e conecta-se perfeitamente a aplicativos ASP.NET via o NuGet.
No que diz respeito à plataforma ASP.NET, uma outra solução DDR interessante é o 51Degrees (51degrees.codeplex.com). O 51Degrees contava originalmente com o WURFL como a fonte de informações sobre dispositivos, mas foi relançado recentemente com uma nova arquitetura e vocabulário internos. O 51Degrees é uma iniciativa puramente comercial, mas oferece uma versão gratuita da estrutura limitada a quatro propriedades: isMobile, ScreenPixelWidth, ScreenPixelHeight e LayoutEngine, que se referem ao mecanismo de renderização do navegador. No que diz respeito às suas ofertas gratuitas, o WURFL e o 51Degrees são quase equivalentes, exceto o licenciamento.
Compreendendo os desejos e as necessidades
O desenvolvimento para celular diz respeito, principalmente, à compreensão do que seus clientes desejam e necessitam. Esse é um ponto crucial e é resolvido quando você tem uma seleção bem escolhida de casos de uso. Para sites móveis especificamente, estimo que obter uma boa seleção de casos de uso para implementar é a maior parte do trabalho. Além disso, o desenvolvimento para celular exige reconhecer que a navegação móvel é diferente. Isso significa que ter apenas um site que se transforma em diferentes renderizações para dispositivos diferentes é seu objetivo, mas não será obtido gratuitamente só com a mágica de alguns arquivos do CSS. CSS não contém quase nenhuma lógica, e talvez você queira ter lógica envolvida ao decidir que conteúdo fornecer a uma determinada classe de dispositivos.
No próximo artigo, discutirei como alternar de um site de desktop para um site móvel, entregando assim dois sites, mas possivelmente uma experiência para o usuário. Posteriormente, vou me aprofundar na segmentação de navegador e nas alternativas para consultas de mídia.
Dino Esposito é o autor de “Architecting Mobile Solutions for the Enterprise” (Microsoft Press, 2012) e “Programming ASP.NET MVC 3” (Microsoft Press, 2011) e coautor de “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2008). Residente na Itália, Esposito é um palestrante sempre presente em eventos do setor no mundo inteiro. Siga-o no Twitter em twitter.com/despos.
Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Steve Sanderson