Este artigo foi traduzido por máquina.
Cutting Edge
Desenvolvimento de site para celular, Parte 3: Solicitações de roteamento
.jpg "Dino Esposito")
Mais frequentemente do que não, um site móvel é o subconjunto de um site maior, construído para um público da área de trabalho. Um usuário de desktop frequentemente visita seu site usando, por exemplo, um laptop com tela de alta resolução e poder de computação significante. Além disso, o usuário conta com conectividade estável e não está particularmente preocupado com a esgotar a bateria. Todos estes parâmetros fazem uma enorme diferença para arquitetos e desenvolvedores de Web sites, bem como especialistas do domínio. Quando se trata de sites móveis, a parte mais difícil não é a codificação mas descobrir os casos de uso de código — e, antes disso, os casos de negócio para o qual você quer ter um site móvel (ou um aplicativo móvel).
O site móvel existe para tornar mais fácil para usuários em movimento consumir os serviços mais relevantes que você já expõe através do site principal. Então vamos supor que temos um conjunto bem-definido de casos de uso e estamos prontos para iniciar a codificação e produzir algumas boas marcações. Mas, acima de tudo, como podemos chegar a site móvel?
Acredito firmemente que um site para celular deve ser um site independente, o que corresponde a um aplicativo de IIS distinto. Isso simplifica a experiência de desenvolvimento. Você se concentrar apenas em casos de uso móvel. Você otimizar o processamento e a camada de aplicação somente para casos de uso móvel. Você lidar apenas com tecnologias e ferramentas relacionadas com cenários móveis. Finalmente, você testá-lo mais facilmente.
Por outro lado, como um usuário, eu odeio ter que digitar uma URL distinta apenas para ver a versão móvel de um site em que estou interessado. Não seria ótimo se você pode apenas digitar ou indicador www.contoso.com e deixe o site descobrir se você está vindo de um dispositivo móvel ou laptop? Uma vez que sua origem é verificada, o site possivelmente poderia redirecioná-lo para o site móvel. Aplicar tal estratégia pode oferecer uma experiência agradável, mas isso requer alguns pressupostos e ter algumas máquinas no lugar.
Encaminhamento de usuários à direita do Site
Vamos supor que existem dois sites distintos — digamos, www.contoso.com e m.contoso.com. O usuário, no entanto, não é esperado para saber sobre o m-site; Ela só sabe sobre o Web site principal. Então ela digita www.contoso.com no seu dispositivo móvel. Algum código hospedado no site principal intercepta a solicitação e examina a seqüência de caracteres de agente do usuário. Se a solicitação é proveniente de um navegador de desktop, não acontece nada e o pedido continua como de costume. Se o navegador solicitante é hospedado em um dispositivo móvel, o usuário é redirecionado para uma página de aterragem onde ela pediu para escolher entre o site completo e o site móvel. Figura 1 oferece uma exibição gráfica da estratégia que estou descrevendo.
Figura 1 estratégia de roteamento de usuários para o Site mais apropriado
Mais geralmente, ambos os sites têm um interceptor que filtra qualquer solicitações de entrada e redireciona para uma página de destino, se o dispositivo solicitante não é compatível com o tipo de site. Para manter as coisas ainda mais simples, você também pode deixar laptops exibir páginas móveis se explicitamente solicitada e hospedar apenas uma página de aterragem para quando o site principal é solicitado a partir de um dispositivo móvel.
Esta estratégia só explica o que fazer na primeira solicitação para um site — normalmente direcionado para a página inicial. Para solicitações sucessivas que o usuário pode fazer como ela trabalha com o site, você não quer o interceptador para chutar novamente e mostrar a página inicial. Vamos ver como implementar essa estratégia.
Um módulo de HTTP para rotear solicitações de
No ASP.NET, a maneira padrão de interceptar as solicitações de entrada é instalar um módulo HTTP. Para cada solicitação interceptada, o módulo HTTP irá examinar a seqüência de agente do usuário e determinar se o navegador está hospedado em um dispositivo móvel. Se o navegador é executado em um dispositivo móvel, o módulo HTTP redireciona o usuário para uma página de destino determinado; Se não, ele simplesmente vai deixar o pedido passar e processado como de costume. Figura 2 mostra o código fonte de um módulo HTTP de exemplo para rotear solicitações de móveis para uma página de aterragem (móvel).
Figura 2 Mobile Router componente implementado como um módulo HTTP
public class MobileRouterModule : IHttpModule
{
private const String ForceFullSiteCookieName = "FullSiteMode";
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.BeginRequest += OnBeginRequest;
}
private static void OnBeginRequest(Object sender, EventArgs e)
{
var app = sender as HttpApplication;
if (app == null)
throw new ArgumentNullException("sender");
// Check whether it is a mobile site
var isMobileDevice = IsMobileUserAgent(app);
// The mobile user confirmed to view the desktop site
if (isMobileDevice && ForceFullSite(app))
{
app.Response.AppendCookie(new HttpCookie(ForceFullSiteCookieName));
return;
}
// The mobile user is navigating through the desktop site
if (isMobileDevice && HasFullSiteCookie(app))
return;
// The mobile user is attempting to view a desktop page
if (isMobileDevice)
ToMobileLandingPage(app);
}
}
Existem basicamente três cenários de caso de uso. É quando o usuário com um dispositivo móvel chega a uma página de aterragem e confirma que ela quer ver o site completo. Outro cenário é quando o usuário móvel solicita uma página do site completo porque ela está seguindo um link em uma das páginas do site completo. Dito de outra forma, o usuário móvel recebeu a página inicial, confirmado ela quer ver o site completo e agora é navegar através do site. Finalmente, o terceiro cenário é quando o usuário móvel está a tentar visitar o site completo pela primeira vez em que sessão de navegador. Nos dois primeiros casos, o módulo HTTP permite que o pedido passe. Neste último caso, ele simplesmente redireciona o usuário móvel para uma página de aterragem ad hoc.
A página inicial será uma página otimizada para mobile que mostra uma mensagem para o usuário e oferece links para a página inicial do site de área de trabalho ou do site móvel. Figura 3 mostra uma página de amostra. Você pode experimentá-lo ao vivo, apontando seu próprio dispositivo para easycourt.net/contosoen.
Figura 3 página de exemplo para um Site móvel**
A URL para trás a "Mobile site" link aponta para a página inicial do site móvel. O outro link aponta para a página inicial do site completo com um parâmetro de seqüência de caracteres de consulta extra. O nome e a função desse parâmetro são até você, mas o nome poderia ser algo como isto: https://www.contoso.com?mode=Full.
Este parâmetro será verificado pelo módulo HTTP por meio de uma das funções mencionadas no Figura 2, conforme mostrado aqui:
private static Boolean ForceFullSite(HttpApplication app)
{
var full = app.Context.Request.QueryString["mode"];
if (!String.IsNullOrEmpty(full))
return String.Equals(full, "full",
StringComparison.InvariantCultureIgnoreCase);
return false;
}
Você vê em Figura 2 que a escolha do usuário é armazenada em um cookie. Isso significa que um usuário que escolheu expressamente para navegar até o site completo com um dispositivo móvel não ser incomodado por mais tempo com uma página de destino, enquanto o cookie está disponível.
Antes de discutir a estrutura da página inicial mais detalhadamente, deixe-me especificar como o módulo HTTP compreende se o usuário clicou para ver o site completo ou é navegar o site completo. Em Figura 2 você ver que o código a seguir é usado para verificar se o cookie para visualizar o site completo é encontrado:
private static Boolean HasFullSiteCookie(HttpApplication app)
{
var cookie = app.Context.Request.Cookies[FullSiteModeCookie];
return cookie != null;
}
Se não houver nenhum cookie e nenhum parâmetro de seqüência de caracteres de consulta, o usuário que acessar o site de área de trabalho a partir de um dispositivo móvel simplesmente é redirecionado para a página inicial:
private static void ToMobileLandingPage(HttpApplication app)
{
var landingPage = ConfigurationManager.AppSettings["MobileLandingPage"];
if (!String.IsNullOrEmpty(landingPage))
app.Context.Response.Redirect(landingPage);
}
O ponto chave é que o usuário pode ser redirecionado para a página inicial apenas na primeira vez que ela tenta acessar um determinado site de área de trabalho a partir de um dispositivo móvel. Daquele ponto, outros eventuais pedidos tem informações extras que impede que o módulo HTTP de redirecionamento.
Detecção de dispositivos móveis
De todo o código que você vê em Figura 2, somente uma parte continua a explicar: como detectar se o dispositivo solicitante é um dispositivo móvel. Isto pode ser conseguido de diferentes maneiras e com diferentes níveis de confiabilidade. Por exemplo, você pode simplesmente confiar em algum código como o mostrado na Figura 4. Ele tenta consultar a seqüência de agente do usuário para algumas palavras-chave somente móvel.
Figura 4 consultar a seqüência de caracteres de agente do usuário para Mobile somente palavras-chave
private static Boolean HasAnyMobileKeyword(String userAgent)
{
string ua = userAgent.ToLower();
return (ua.Contains("midp") ||
ua.Contains("mobile") ||
ua.Contains("android") ||
ua.Contains("samsung") ||
ua.Contains("nokia") ||
ua.Contains("phone") ||
ua.Contains("opera mini") ||
ua.Contains("opera mobi") ||
ua.Contains("blackberry") ||
ua.Contains("symbian") ||
ua.Contains("j2me") ||
ua.Contains("windows ce") ||
ua.Contains("vodafone") ||
ua.Contains("ipad;") ||
ua.Contains("maemo") ||
ua.Contains("palm") ||
ua.Contains("fennec") ||
ua.Contains("wireless") ||
ua.Contains("htc") ||
ua.Contains("nintendo") ||
ua.Contains("zunewp7") ||
ua.Contains("silk");
}
A lista de palavras-chave não é exaustiva, mas é bastante representativo do universo móvel. Este código pode ser estendido à vontade para fazê-lo funcionar melhor e melhor tal como aparecem novos dispositivos e usuários móveis mais começam a visitar seu site. Mas isso é precisamente o ponto. Você está disposto a atualizar constantemente este pedaço de código? Não ter que rever esse código é apenas um dos benefícios que oferece um repositório de descrição de dispositivo (DDR). Uma DDR é uma biblioteca construída em cima de um banco de dados que contém seqüências de agente de usuário. Tudo uma DDR faz é analisar o agente do usuário e retorna uma lista de recursos conhecidos. Eu disse "conhecido" e não "detectado" porque esse é precisamente o caso. Uma DDR Obtém informações estaticamente a partir de um banco de dados atualizado com freqüência. Ele não detecta as capacidades do dispositivo. No entanto, esta é uma vantagem das soluções DDR, ao invés de uma limitação! Por trás de DDR não há intervenção humana e trabalho humano estabelece se um determinado dispositivo tem um recurso determinado. Alguns recursos podem ser detectados através de algoritmos, mas o valor retornado não é sempre inteiramente confiável. Alguns outros recursos — a maioria, na verdade — não pode ser detectado através de algoritmos, mas pode ser útil saber para decidir inteligentemente que marcação para servir a um determinado dispositivo.
DDRs populares para o espaço do ASP.NET são Wireless Universal Resource File, ou WURFL e 51degrees, como discutido na minha coluna anterior (msdn.microsoft.com/magazine/jj190798). Porque ambos estes quadros têm uma oferta gratuita de uso limitado (principalmente baseados em nuvem), você pode querer escolher um deles, mesmo se você só precisa determinar se um dispositivo é móvel ou não. Pelo menos você vai salvar o encargo de atualizar com freqüência sua função de IsMobile para manter-se com novos dispositivos e casos de canto.
Otimizar para diferentes dispositivos
Resumindo, acredito que sites da Web deve oferecer um conjunto otimizado de páginas para dispositivos diferentes, sejam eles smartphones, tablets e notebooks. Isto é melhor conseguido se você pode oferecer diferentes sites ou pelo menos fisicamente diferentes pontos de vista que você pode gerenciar e manter separadamente. No entanto, esta separação deve ser sempre transparente para os visitantes do site. O site deve ser acessível através de uma URL exclusiva. Você pode deixar a plataforma subjacente fazer a magia da compreensão do tipo de dispositivo e alterne para a visualização mais adequada. Na minha próxima coluna, usarei DDRs para discutir uma implementação de pontos de vista diferente para diferentes dispositivos.
Dino Esposito é o autor de "Arquitetura móvel soluções para a empresa" (Microsoft Press, 2012) e "programação ASP.NET MVC 3" (Microsoft Press, 2011) e co-autor do livro "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: Camila Rodrigues de Oliveira