Compartilhar via

Como: Adicionar páginas móveis ao seu Web Forms do ASP.NET ou seu aplicativo do MVC

  • Artigo

Aplica-se a

  • ASP.NET Web Forms versão 4.0
  • ASP.NET MVC versão 3.0

Resumo

Este Como descrever várias maneiras de fornecer páginas otimizadas para dispositivos móveis de seu aplicativo ASP.NET Web Forms/MVC e sugere problemas de arquitetura e design a serem considerados ao direcionar uma ampla gama de dispositivos. Este documento também explica por que os controles móveis ASP.NET de ASP.NET 2.0 a 3.5 agora estão obsoletos e discute algumas alternativas modernas.

Sumário

  • Visão geral
  • Opções de arquitetura
  • Detecção de navegador e dispositivo
  • Como ASP.NET Web Forms aplicativos podem apresentar páginas específicas para dispositivos móveis
  • Como ASP.NET aplicativos MVC podem apresentar páginas específicas para dispositivos móveis
  • Recursos adicionais

Para obter exemplos de código para download que demonstram as técnicas deste white paper para ASP.NET Web Forms e MVC, consulte Aplicativos Móveis & Sites com ASP.NET.

Visão geral

Os dispositivos móveis – smartphones, feature phones e tablets – continuam crescendo em popularidade como um meio de acessar a Web. Para muitos desenvolvedores web e empresas orientadas à Web, isso significa que é cada vez mais importante fornecer uma ótima experiência de navegação para os visitantes que usam esses dispositivos.

Como versões anteriores do ASP.NET navegadores móveis com suporte

ASP.NET versões 2.0 a 3.5 incluíam ASP.NET Controles Móveis: um conjunto de controles de servidor para dispositivos móveis no assembly System.Web.Mobile.dll e no namespace System.Web.UI.MobileControls . O assembly ainda está incluído no ASP.NET 4, mas foi preterido. Os desenvolvedores são aconselhados a migrar para abordagens mais modernas, como as descritas neste artigo.

A razão pela qual ASP.NET Controles Móveis foram marcados como obsoletos é que seu design é orientado em torno dos telefones celulares que eram comuns por volta de 2005 e anteriores. Os controles são projetados principalmente para renderizar a marcação WML ou cHTML (em vez de HTML regular) para os navegadores WAP daquela época. Mas WAP, WML e cHTML não são mais relevantes para a maioria dos projetos, porque o HTML agora se tornou a linguagem de marcação onipresente para navegadores móveis e de desktop.

Os desafios de dar suporte a dispositivos móveis hoje

Embora os navegadores móveis agora ofereçam suporte quase universal ao HTML, você ainda enfrentará muitos desafios ao tentar criar ótimas experiências de navegação móvel:

  • Tamanho da tela – os dispositivos móveis variam drasticamente na forma, e suas telas geralmente são muito menores do que os monitores da área de trabalho. Portanto, talvez seja necessário criar layouts de página completamente diferentes para eles.
  • Métodos de entrada – alguns dispositivos têm teclados, outros têm canetas, outros usam toque. Talvez seja necessário considerar vários mecanismos de navegação e métodos de entrada de dados.
  • Conformidade com padrões – muitos navegadores móveis não dão suporte aos padrões HTML, CSS ou JavaScript mais recentes.
  • Largura de banda – o desempenho da rede de dados celulares varia descontroladamente e alguns usuários finais têm tarifas cobradas pelo megabyte.

Não há uma solução de tamanho único; seu aplicativo terá que parecer e se comportar de forma diferente de acordo com o dispositivo que o acessa. Dependendo do nível de suporte móvel desejado, esse pode ser um desafio maior para os desenvolvedores da Web do que a "guerra de navegadores" da área de trabalho já foi.

Os desenvolvedores que se aproximam do suporte ao navegador móvel pela primeira vez geralmente acham que é importante dar suporte aos smartphones mais recentes e sofisticados (por exemplo, Windows Phone 7, iPhone ou Android), talvez porque os desenvolvedores geralmente possuem esses dispositivos pessoalmente. No entanto, telefones mais baratos ainda são extremamente populares, e seus proprietários os usam para navegar na Web , especialmente em países e regiões onde os telefones celulares são mais fáceis de obter do que uma conexão de banda larga. Sua empresa precisará decidir qual intervalo de dispositivos dar suporte considerando seus clientes prováveis. Se você está construindo um folheto online para um spa de saúde de luxo, você pode tomar uma decisão de negócios apenas para direcionar smartphones avançados, enquanto se você está criando um sistema de reserva de ingressos para um cinema, você provavelmente precisa levar em conta visitantes com telefones de recursos menos poderosos.

Opções de arquitetura

Antes de chegarmos aos detalhes técnicos específicos do ASP.NET Web Forms ou do MVC, observe que os desenvolvedores da Web em geral têm três main opções possíveis para dar suporte a navegadores móveis:

  1. Não fazer nada – Você pode simplesmente criar um aplicativo Web padrão orientado à área de trabalho e contar com navegadores móveis para renderizá-lo de forma aceitável.

    • Vantagem: é a opção mais barata para implementar e manter – sem trabalho extra

    • Desvantagem: oferece a pior experiência do usuário final:

      • Os smartphones mais recentes podem renderizar seu HTML, bem como um navegador da área de trabalho, mas os usuários ainda serão forçados a ampliar e rolar horizontal e verticalmente para consumir seu conteúdo em uma tela pequena. Isso está longe de ser o ideal.
      • Dispositivos e telefones de recursos mais antigos podem não renderizar sua marcação de maneira satisfatória.
      • Mesmo nos dispositivos tablet mais recentes (cujas telas podem ser tão grandes quanto telas de laptop), diferentes regras de interação se aplicam. A entrada baseada em toque funciona melhor com botões maiores e links distribuídos mais distantes, e não há como passar o mouse sobre um menu suspenso.

  2. Resolver o problema no cliente – Com o uso cuidadoso do CSS e o aprimoramento progressivo , você pode criar marcação, estilos e scripts que se adaptem a qualquer navegador que os esteja executando. Por exemplo, com consultas de mídia CSS 3, você pode criar um layout de várias colunas que se transforma em um layout de coluna única em dispositivos cujas telas são mais estreitas do que um limite escolhido.

    • Vantagem: otimiza a renderização para o dispositivo específico em uso, mesmo para dispositivos futuros desconhecidos de acordo com as características de tela e entrada que eles têm
    • Vantagem: permite compartilhar facilmente a lógica do lado do servidor em todos os tipos de dispositivo – duplicação mínima de código ou esforço
    • Desvantagem: os dispositivos móveis são tão diferentes dos dispositivos desktop que você pode realmente querer que suas páginas móveis sejam completamente diferentes das páginas da área de trabalho, mostrando informações diferentes. Essas variações podem ser ineficientes ou impossíveis de serem alcançadas de forma robusta apenas por meio do CSS, especialmente considerando o quão inconsistentemente os dispositivos mais antigos interpretam as regras de CSS. Isso é particularmente verdadeiro para atributos CSS 3.
    • Desvantagem: não oferece suporte para diferentes fluxos de trabalho e lógica do lado do servidor para dispositivos diferentes. Você não pode, por exemplo, implementar um fluxo de trabalho simplificado de check-out de carrinho de compras para usuários móveis apenas por meio do CSS.
    • Desvantagem: uso de largura de banda ineficiente. Talvez o servidor precise transmitir a marcação e os estilos que se aplicam a todos os dispositivos possíveis, embora o dispositivo de destino use apenas um subconjunto dessas informações.

  3. Resolver o problema no servidor – Se o servidor souber qual dispositivo está acessando - ou pelo menos as características desse dispositivo, como o tamanho da tela e o método de entrada e se ele é um dispositivo móvel - ele poderá executar uma lógica diferente e gerar uma marcação HTML diferente.

    • Vantagem: Flexibilidade máxima. Não há limite para o quanto você pode variar sua lógica do lado do servidor para dispositivos móveis ou otimizar sua marcação para o layout desejado e específico do dispositivo.
    • Vantagem: Uso eficiente de largura de banda. Você só precisa transmitir as informações de marcação e estilo que o dispositivo de destino usará.
    • Desvantagem: Às vezes, força a repetição de esforço ou código (por exemplo, fazendo com que você crie cópias semelhantes, mas ligeiramente diferentes de suas páginas de Web Forms ou exibições MVC). Sempre que possível, você fatorará a lógica comum em uma camada ou serviço subjacente, mas ainda assim, algumas partes do código ou marcação da interface do usuário podem ter que ser duplicadas e mantidas em paralelo.
    • Desvantagem: A detecção de dispositivo não é trivial. Ele requer uma lista ou um banco de dados de tipos de dispositivo conhecidos e suas características (que nem sempre podem estar perfeitamente atualizadas) e não tem garantia de corresponder com precisão a cada solicitação de entrada. Este documento descreve algumas opções e suas armadilhas posteriormente.

Para obter os melhores resultados, a maioria dos desenvolvedores acha que precisa combinar opções (2) e (3). Pequenas diferenças estilísticas são melhor acomodadas no cliente usando CSS ou até mesmo JavaScript, enquanto as principais diferenças em dados, fluxo de trabalho ou marcação são implementadas com mais eficiência no código do lado do servidor.

Este artigo se concentra em técnicas do lado do servidor

Como ASP.NET Web Forms e MVC são principalmente tecnologias do lado do servidor, este white paper se concentrará em técnicas do lado do servidor que permitem produzir marcação e lógica diferentes para navegadores móveis. É claro que você também pode combinar isso com qualquer técnica do lado do cliente (por exemplo, consultas de mídia CSS 3, JavaScript de aprimoramento progressivo), mas isso é mais uma questão de design da Web do que ASP.NET desenvolvimento.

Detecção de navegador e dispositivo

O principal pré-requisito para todas as técnicas do lado do servidor para dar suporte a dispositivos móveis é saber qual dispositivo seu visitante está usando. Na verdade, ainda melhor do que saber que o fabricante e o número do modelo desse dispositivo estão conhecendo as características do dispositivo. As características podem incluir:

  • É um dispositivo móvel?
  • Método de entrada (mouse/teclado, toque, teclado, joystick, ...)
  • Tamanho da tela (fisicamente e em pixels)
  • Formatos de mídia e dados com suporte
  • Etc.

É melhor tomar decisões com base em características do que no número do modelo, pois você estará melhor equipado para lidar com dispositivos futuros.

Usando o ASP. Suporte interno à detecção de navegador do NET

ASP.NET Web Forms e desenvolvedores de MVC podem descobrir imediatamente características importantes de um navegador visitante inspecionando as propriedades do objeto Request.Browser. Por exemplo, consulte

  • Request.Browser.IsMobileDevice
  • Request.Browser.MobileDeviceManufacturer, Request.Browser.MobileDeviceModel
  • Request.Browser.ScreenPixelsWidth
  • Request.Browser.SupportsXmlHttp
  • ...e muitas outras

Nos bastidores, a plataforma ASP.NET corresponde ao cabeçalho HTTP do Agente de Usuário (UA) de entrada em relação a expressões regulares em um conjunto de arquivos XML de Definição do Navegador. Por padrão, a plataforma inclui definições para muitos dispositivos móveis comuns e você pode adicionar arquivos de definição de navegador personalizados para outras pessoas que deseja reconhecer. Para obter mais detalhes, consulte a página msdn ASP.NET controles de servidor Web e recursos do navegador.

Usando o banco de dados de dispositivo WURFL por meio do 51Degrees.mobi Foundation

Enquanto ASP. O suporte interno à detecção de navegador do NET será suficiente para muitos aplicativos, há dois casos main em que pode não ser suficiente:

  • Você deseja reconhecer os dispositivos mais recentes (sem criar manualmente arquivos de Definição de Navegador para eles). Observe que os arquivos de Definição do Navegador do .NET 4 não são recentes o suficiente para reconhecer Windows Phone 7, telefones Android, navegadores Opera Mobile ou iPads da Apple.
  • Você precisa de informações mais detalhadas sobre os recursos do dispositivo. Talvez seja necessário saber sobre o método de entrada de um dispositivo (por exemplo, toque versus teclado) ou quais formatos de áudio o navegador dá suporte. Essas informações não estão disponíveis nos arquivos de Definição de Navegador padrão.

O projeto WURFL (Wireless Universal Resource File) mantém informações muito mais atualizadas e detalhadas sobre dispositivos móveis em uso atualmente.

A ótima notícia para os desenvolvedores do .NET é que o ASP. O recurso de detecção de navegador do NET é extensível, portanto, é possível aprimorá-lo para superar esses problemas. Por exemplo, você pode adicionar a biblioteca código aberto 51Degrees.mobi Foundation ao seu projeto. É um provedor de recursos de navegador ou IHttpModule ASP.NET (utilizável em aplicativos Web Forms e MVC), que lê diretamente os dados WURFL e os conecta ao ASP. O mecanismo de detecção de navegador interno do NET. Depois de instalar o módulo, o Request.Browser de repente conterá informações muito mais precisas e detalhadas: ele reconhecerá corretamente muitos dos dispositivos mencionados anteriormente e listará seus recursos (incluindo recursos adicionais, como o método de entrada). Consulte a documentação do projeto para obter mais detalhes.

Como Web Forms aplicativos podem apresentar páginas específicas para dispositivos móveis

Por padrão, veja como um novo aplicativo Web Forms é exibido em dispositivos móveis comuns:

Captura de tela de dois aplicativos Web Forms, conforme exibido no Windows Phone 7 e no Opera Mobile.

Claramente, nenhum layout parece muito amigável para dispositivos móveis – esta página foi projetada para um monitor grande e orientado para paisagem, não para uma tela pequena orientada a retratos. Então, o que você pode fazer sobre isso?

Conforme discutido anteriormente neste artigo, há muitas maneiras de adaptar suas páginas para dispositivos móveis. Algumas técnicas são baseadas em servidor, outras são executadas no cliente.

Criando uma página de master específica para dispositivos móveis

Dependendo de seus requisitos, você pode usar a mesma Web Forms para todos os visitantes, mas tem duas páginas master separadas: uma para visitantes da área de trabalho, outra para visitantes móveis. Isso oferece a flexibilidade de alterar a folha de estilos do CSS ou sua marcação HTML de nível superior para atender a dispositivos móveis, sem forçar você a duplicar qualquer lógica de página.

Isso é fácil de fazer. Por exemplo, você pode adicionar um manipulador PreInit, como o seguinte a um Formulário da Web:

protected void Page_PreInit(object sender, EventArgs e)
{
    if (Request.Browser.IsMobileDevice)
        MasterPageFile = "~/Mobile.Master";
}

Agora, crie uma página de master chamada Mobile.Master na pasta de nível superior do aplicativo e ela será usada quando um dispositivo móvel for detectado. Sua página de master móvel pode referenciar uma folha de estilos CSS específica do dispositivo móvel, se necessário. Os visitantes da área de trabalho ainda verão sua página de master padrão, não a móvel.

Criando Web Forms independentes específicas para dispositivos móveis

Para obter flexibilidade máxima, você pode ir muito além de apenas ter páginas master separadas para diferentes tipos de dispositivo. Você pode implementar dois conjuntos totalmente separados de Web Forms páginas : um conjunto para navegadores de área de trabalho, outro conjunto para dispositivos móveis. Isso funciona melhor se você quiser apresentar informações ou fluxos de trabalho muito diferentes para visitantes móveis. O restante desta seção descreve essa abordagem em detalhes.

Supondo que você já tenha um aplicativo Web Forms projetado para navegadores de área de trabalho, a maneira mais fácil de continuar é criar uma subpasta chamada "Móvel" em seu projeto e criar suas páginas móveis lá. Você pode construir um sub-site inteiro, com suas próprias páginas master, folhas de estilo e páginas, usando todas as mesmas técnicas que usaria para qualquer outro aplicativo Web Forms. Você não precisa necessariamente produzir um equivalente móvel para cada página em seu site de área de trabalho; você pode escolher qual subconjunto de funcionalidade faz sentido para visitantes móveis.

Suas páginas móveis podem compartilhar recursos estáticos comuns (como imagens, JavaScript ou arquivos CSS) com suas páginas regulares, se desejar. Como sua pasta "Mobile" não será marcada como um aplicativo separado quando hospedada no IIS (é apenas uma subpasta simples de Web Forms páginas), ela também compartilhará todas as mesmas configurações, dados de sessão e outras infraestruturas que as páginas da área de trabalho.

Observação

Como essa abordagem geralmente envolve alguma duplicação de código (as páginas móveis provavelmente compartilharão algumas semelhanças com páginas da área de trabalho), é importante considerar qualquer lógica de negócios comum ou código de acesso a dados em uma camada ou serviço subjacente compartilhado. Caso contrário, você dobrará o esforço de criar e manter seu aplicativo.

Redirecionando visitantes móveis para suas páginas móveis

Geralmente, é conveniente redirecionar os visitantes móveis para as páginas móveis apenas na primeira solicitação em sua sessão de navegação (e não em todas as solicitações em sua sessão), porque:

  • Você pode permitir facilmente que os visitantes móveis acessem suas páginas da área de trabalho se desejarem– basta colocar um link na página master que vai para "Versão da área de trabalho". O visitante não será redirecionado de volta para uma página móvel, pois não é mais a primeira solicitação em sua sessão.
  • Ele evita o risco de interferir em solicitações para quaisquer recursos dinâmicos compartilhados entre área de trabalho e partes móveis do seu site (por exemplo, se você tiver um Formulário web comum que tanto a área de trabalho quanto as partes móveis do seu site exibem em um IFRAME ou em determinados manipuladores do Ajax)

Para fazer isso, você pode colocar sua lógica de redirecionamento em um método Session_Start . Por exemplo, adicione o seguinte método ao arquivo Global.asax.cs:

void Session_Start(object sender, EventArgs e)
{
    // Redirect mobile users to the mobile home page
    HttpRequest httpRequest = HttpContext.Current.Request;
    if (httpRequest.Browser.IsMobileDevice)
    {
        string path = httpRequest.Url.PathAndQuery;
        bool isOnMobilePage = path.StartsWith("/Mobile/", 
                               StringComparison.OrdinalIgnoreCase);
        if (!isOnMobilePage)
        {
            string redirectTo = "~/Mobile/";

            // Could also add special logic to redirect from certain 
            // recognized pages to the mobile equivalents of those 
            // pages (where they exist). For example,
            // if (HttpContext.Current.Handler is UserRegistration)
            //     redirectTo = "~/Mobile/Register.aspx";

            HttpContext.Current.Response.Redirect(redirectTo);
        }
    }
}

Configurando a Autenticação de Formulários para respeitar suas páginas móveis

Observe que a Autenticação de Formulários faz determinadas suposições sobre onde pode redirecionar visitantes durante e após o processo de autenticação:

  • Quando um usuário precisar ser autenticado, a Autenticação de Formulários o redirecionará para a página de logon da área de trabalho, independentemente de ser um usuário da área de trabalho ou móvel (porque ele tem apenas um conceito de uma URL de logon). Supondo que você deseja estilizar sua página de logon móvel de forma diferente, você precisa aprimorar a página de logon da área de trabalho para que ela redirecione os usuários móveis para uma página de logon móvel separada. Por exemplo, adicione o seguinte código à página de logon da área de trabalho code-behind:

    public partial class Login : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        // Ensure that if Forms Authentication forces a mobile user 
        // to log in, we display the mobile login page
        string returnUrl = Request.QueryString["ReturnUrl"];
        if (!String.IsNullOrEmpty(returnUrl) && returnUrl.StartsWith("/Mobile/",
                                                StringComparison.OrdinalIgnoreCase)) 
        {
            Response.Redirect("~/Mobile/Account/Login.aspx?ReturnUrl=" 
                              + HttpUtility.UrlEncode(returnUrl));
        }

        RegisterHyperLink.NavigateUrl = "Register.aspx?ReturnUrl=" 
                                        + HttpUtility.UrlEncode(returnUrl);
    }
}

  • Depois que um usuário fizer logon com êxito, a Autenticação de Formulários, por padrão, redirecionará-os para a home page da área de trabalho (porque ela tem apenas um conceito de uma página padrão). Você precisa aprimorar sua página de logon móvel para que ela seja redirecionada para a home page móvel após um logon bem-sucedido. Por exemplo, adicione o seguinte código à sua página de logon móvel code-behind:

    public partial class Login : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        // Ensure that after logging in, mobile users stay on mobile pages
        string returnUrl = Request.QueryString["ReturnUrl"];
        if (String.IsNullOrEmpty(returnUrl))
        {
            returnUrl = "~/Mobile/";
        }
        LoginUser.DestinationPageUrl = returnUrl;

        // (the following line is already present by default)
        RegisterHyperLink.NavigateUrl = "Register.aspx?ReturnUrl=" 
                                        + HttpUtility.UrlEncode(returnUrl);
    }
}

    Esse código pressupõe que sua página tenha um controle de servidor de logon chamado LoginUser, como no modelo de projeto padrão.

Trabalhando com o cache de saída

Se você estiver usando o cache de saída, tenha cuidado que, por padrão, é possível que um usuário da área de trabalho visite uma determinada URL (fazendo com que sua saída seja armazenada em cache), seguida por um usuário móvel que, em seguida, recebe a saída da área de trabalho armazenada em cache. Esse aviso se aplica se você está apenas variando sua página master por tipo de dispositivo ou implementando Web Forms totalmente separadas por tipo de dispositivo.

Para evitar o problema, você pode instruir ASP.NET a variar a entrada de cache de acordo com se o visitante está usando um dispositivo móvel. Adicione um parâmetro VaryByCustom à declaração OutputCache da página da seguinte maneira:

<%@ OutputCache VaryByParam="*" Duration="60" VaryByCustom="isMobileDevice" %>

Em seguida, defina isMobileDevice como um parâmetro de cache personalizado adicionando a seguinte substituição de método ao arquivo Global.asax.cs:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase))
        return context.Request.Browser.IsMobileDevice.ToString();

    return base.GetVaryByCustomString(context, custom);
}

Isso garantirá que os visitantes móveis da página não recebam a saída colocada anteriormente no cache por um visitante da área de trabalho.

Um exemplo de trabalho

Para ver essas técnicas em ação, baixe os exemplos de código deste white paper. O aplicativo de exemplo Web Forms redireciona automaticamente os usuários móveis para um conjunto de páginas específicas do dispositivo móvel em uma subpasta chamada Mobile. A marcação e o estilo dessas páginas são melhor otimizados para navegadores móveis, como você pode ver nas seguintes capturas de tela:

Captura de tela de dois aplicativos de Web Forms móveis, conforme exibido no Windows Phone 7 e no Opera Mobile.

Para obter mais dicas sobre como otimizar sua marcação e CSS para navegadores móveis, consulte a seção "Estilo de páginas móveis para navegadores móveis" mais adiante neste documento.

Como ASP.NET aplicativos MVC podem apresentar páginas específicas para dispositivos móveis

Como o padrão Model-View-Controller separa a lógica do aplicativo (em controladores) da lógica de apresentação (em exibições), você pode escolher entre qualquer uma das seguintes abordagens para lidar com o suporte móvel no código do lado do servidor:

  1. Use os mesmos controladores e exibições para navegadores móveis e desktop, mas renderize os modos de exibição com layouts razor diferentes dependendo do tipo de dispositivo. Essa opção funciona melhor se você estiver exibindo dados idênticos em todos os dispositivos, mas simplesmente quiser fornecer diferentes folhas de estilo CSS ou alterar alguns elementos HTML de nível superior para dispositivos móveis.
  2. Use os mesmos controladores para navegadores móveis e desktop, mas renderize exibições diferentes dependendo do tipo de dispositivo. Essa opção funciona melhor se você estiver exibindo aproximadamente os mesmos dados e fornecendo os mesmos fluxos de trabalho para os usuários finais, mas quiser renderizar uma marcação HTML muito diferente para se adequar ao dispositivo que está sendo usado.
  3. Crie áreas separadas para navegadores móveis e de área de trabalho, implementando controladores e exibições independentes para cada um. Essa opção funciona melhor se você estiver exibindo telas muito diferentes, contendo informações diferentes e levando o usuário por meio de diferentes fluxos de trabalho otimizados para seu tipo de dispositivo. Isso pode significar alguma repetição de código, mas você pode minimizar isso fatorando a lógica comum em uma camada ou serviço subjacente.

Se você quiser usar a primeira opção e variar apenas o layout razor por tipo de dispositivo, é muito fácil. Basta modificar o arquivo _ViewStart.cshtml da seguinte maneira:

@{
    Layout = Request.Browser.IsMobileDevice ? "~/Views/Shared/_LayoutMobile.cshtml"
                                            : "~/Views/Shared/_Layout.cshtml";
}

Agora você pode criar um layout específico do dispositivo móvel chamado _LayoutMobile.cshtml com uma estrutura de página e regras CSS otimizadas para dispositivos móveis.

Se você quiser usar a segunda opção para renderizar exibições totalmente diferentes de acordo com o tipo de dispositivo do visitante, consulte a postagem no blog de Scott Hanselman.

O restante deste artigo se concentra na terceira opção – criar controladores e exibições separados para dispositivos móveis – para que você possa controlar exatamente qual subconjunto de funcionalidade é oferecido para visitantes móveis.

Configurando uma área móvel em seu aplicativo MVC ASP.NET

Você pode adicionar uma área chamada "Móvel" a um aplicativo MVC ASP.NET existente da maneira normal: clique com o botão direito do mouse no nome do projeto no Gerenciador de Soluções e escolha Adicionar à Área. Em seguida, você pode adicionar controladores e exibições como faria para qualquer outra área em um aplicativo ASP.NET MVC. Por exemplo, adicione à área móvel um novo controlador chamado HomeController para atuar como uma home page para visitantes móveis.

Garantir que a URL /Mobile atinja a home page móvel

Se você quiser que a URL /Mobile alcance a ação Índice no HomeController dentro da área Móvel, precisará fazer duas pequenas alterações na configuração de roteamento. Primeiro, atualize sua classe MobileAreaRegistration para que HomeController seja o controlador padrão em sua área Móvel, conforme mostrado no seguinte código:

public override void RegisterArea(AreaRegistrationContext context)
{
    // By default there is no "controller" parameter in the following line. 
    // Add one referencing "Home" as shown.
    context.MapRoute(
        "Mobile_default",
        "Mobile/{controller}/{action}/{id}",
        new { controller = "Home", action = "Index", id = UrlParameter.Optional }
    );
}

Isso significa que a home page móvel agora estará localizada em /Mobile, em vez de /Mobile/Home, porque "Home" agora é o nome do controlador implicitamente padrão para páginas móveis.

Em seguida, observe que, adicionando um segundo HomeController ao seu aplicativo (ou seja, o móvel, além do da área de trabalho existente), você terá quebrado sua home page da área de trabalho regular. Ele falhará com o erro "Foram encontrados vários tipos que correspondem ao controlador chamado 'Home'". Para resolve isso, atualize sua configuração de roteamento de nível superior (em Global.asax.cs) para especificar que o HomeController da área de trabalho deve ter prioridade quando houver ambiguidade:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",
        "{controller}/{action}/{id}",
        new { controller = "Home", action = "Index", id = UrlParameter.Optional },
        // Add the namespace of your desktop controllers here
        new[] { "YourApplication.Controllers" } 
    );
}

Agora, o erro desaparecerá e a URL http:// yoursite/ chegará à home page da área de trabalho e http:// susite/móvel/ chegará à home page móvel.

Redirecionando visitantes móveis para sua área móvel

Há muitos pontos de extensibilidade diferentes em ASP.NET MVC, portanto, há muitas maneiras possíveis de injetar lógica de redirecionamento. Uma opção interessante é criar um atributo de filtro, [RedirectMobileDevicesToMobileArea], que executa um redirecionamento se as seguintes condições forem atendidas:

  1. É a primeira solicitação na sessão do usuário (ou seja, Session.IsNewSession é igual a true)
  2. A solicitação vem de um navegador móvel (ou seja, Request.Browser.IsMobileDevice é igual a true)
  3. O usuário ainda não está solicitando um recurso na área móvel (ou seja, a parte do caminho da URL não começa com /Mobile)

O exemplo para download incluído neste white paper inclui uma implementação dessa lógica. Ele é implementado como um filtro de autorização, derivado de AuthorizeAttribute, o que significa que ele pode funcionar corretamente mesmo se você estiver usando o cache de saída (caso contrário, se um visitante da área de trabalho acessar primeiro uma determinada URL, a saída da área de trabalho poderá ser armazenada em cache e, em seguida, atendida para visitantes móveis subsequentes).

Como é um filtro, você pode optar por aplicá-lo a controladores e ações específicos, por exemplo,

public class HomeController : Controller
{
    [RedirectMobileDevicesToMobileArea] // Applies just to this action
    public ActionResult Index()
    {
        // ...
    }
}

… ou você pode aplicá-lo a todos os controladores e ações como um filtro global MVC 3 no arquivo Global.asax.cs:

protected void Application_Start()
{
    // (rest of method unchanged)

    // Using "order" value 1 means it will run after unordered filters
    // associated with specific controllers or actions, so the redirection 
    // location can be overridden for specific actions
    GlobalFilters.Filters.Add(new RedirectMobileDevicesToMobileAreaAttribute(), 1);
}

O exemplo para download também demonstra como você pode criar subclasses desse atributo que redirecionam para locais específicos em sua área móvel. Isso significa, por exemplo, que você pode:

  • Registre um filtro global, conforme mostrado acima, que envia visitantes móveis para a home page móvel por padrão.
  • Aplique também um filtro especial [RedirectMobileDevicesToMobileProductPage] a uma ação de "exibir produto" que leve os visitantes móveis para a versão móvel de qualquer página de produto que eles haviam solicitado.
  • Aplique também outras subclasses especiais do filtro a ações específicas, redirecionando os visitantes móveis para a página móvel equivalente

Configurando a Autenticação de Formulários para respeitar suas páginas móveis

Se você estiver usando a Autenticação de Formulários, deverá observar que, quando um usuário precisa fazer logon, ele redireciona automaticamente o usuário para uma única URL específica de "logon", que por padrão é /Account/LogOn. Isso significa que os usuários móveis podem ser redirecionados para a ação de "logon" da área de trabalho.

Para evitar esse problema, adicione lógica à ação de "logon" da área de trabalho para que ela redirecione os usuários móveis novamente para uma ação móvel de "logon". Se você estiver usando o modelo de aplicativo padrão ASP.NET MVC, atualize a ação LogOn do AccountController da seguinte maneira:

public ActionResult LogOn()
{
    string returnUrl = Request.QueryString["ReturnUrl"];
    if ((returnUrl != null) && returnUrl.StartsWith("/Mobile/", 
                               StringComparison.OrdinalIgnoreCase)) 
    {
        return RedirectToAction("LogOn", "Account", 
                                new { Area = "Mobile", ReturnUrl = returnUrl });
    }
    return View();
}

… e implemente uma ação de "logon" específica para dispositivos móveis adequada em um controlador chamado AccountController em sua área móvel.

Trabalhando com o cache de saída

Se você estiver usando o filtro [OutputCache], deverá forçar a entrada de cache a variar de acordo com o tipo de dispositivo. Por exemplo, escreva:

[OutputCache(Duration = 60, VaryByParam = "*", VaryByCustom = "isMobileDevice")]

Em seguida, adicione o seguinte método ao arquivo Global.asax.cs:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase))
        return context.Request.Browser.IsMobileDevice.ToString();

    return base.GetVaryByCustomString(context, custom);
}

Isso garantirá que os visitantes móveis da página não recebam a saída colocada anteriormente no cache por um visitante da área de trabalho.

Um exemplo funcional

Para ver essas técnicas em ação, baixe os exemplos associados ao código deste white paper. O exemplo inclui um aplicativo ASP.NET MVC 3 (Release Candidate) aprimorado para dar suporte a dispositivos móveis usando os métodos descritos acima.

Diretrizes e sugestões adicionais

A discussão a seguir aplica-se a desenvolvedores de Web Forms e MVC que estão usando as técnicas abordadas neste documento.

Aprimorando sua lógica de redirecionamento usando o 51Degrees.mobi Foundation

A lógica de redirecionamento mostrada neste documento pode ser perfeitamente suficiente para seu aplicativo, mas não funcionará se você precisar desabilitar sessões ou com navegadores móveis que rejeitam cookies (eles não podem ter sessões), pois não saberá se uma determinada solicitação é a primeira desse visitante.

Você já aprendeu como o código aberto 51Degrees.mobi Foundation pode melhorar a precisão do ASP. Detecção de navegador do NET. Ele também tem a capacidade interna de redirecionar visitantes móveis para locais específicos configurados em Web.config. Ele é capaz de trabalhar sem depender de sessões de ASP.NET (e, portanto, cookies) armazenando um log temporário de hashes de cabeçalhos HTTP e endereços IP dos visitantes, para que ele saiba se cada solicitação é ou não a primeira de um determinado vistor.

O elemento a seguir adicionado à seção fiftyOne do arquivo web.config redirecionará a primeira solicitação de um dispositivo móvel detectado para a página ~/Mobile/Default.aspx. Todas as solicitações para páginas na pasta Móvel não serão redirecionadas, independentemente do tipo de dispositivo. Se o dispositivo móvel estiver inativo por um período de 20 minutos ou mais, o dispositivo será esquecido e as solicitações subsequentes serão tratadas como novas para fins de redirecionamento.

<redirect firstRequestOnly="true"
          mobileHomePageUrl="~/Mobile/Default.aspx"
          timeout="20"
          devicesFile="~/App_Data/Devices.dat"
          mobilePagesRegex="/Mobile/" />

Para obter mais detalhes, consulte a documentação do 51degrees.mobi Foundation.

Observação

Você pode usar o recurso de redirecionamento do 51Degrees.mobi Foundation em ASP.NET aplicativos MVC, mas precisará definir sua configuração de redirecionamento em termos de URLs simples, não em termos de parâmetros de roteamento ou colocando filtros MVC em ações. Isso ocorre porque (no momento da gravação) 51Degrees.mobi Foundation não reconhece filtros ou roteamento.

Desabilitando transcodificadores e servidores proxy

As operadoras de rede móvel têm dois objetivos amplos em sua abordagem para a Internet móvel:

  1. Fornecer o máximo de conteúdo relevante possível
  2. Maximizar o número de clientes que podem compartilhar a largura de banda limitada da rede de rádio

Como a maioria das páginas da Web foi projetada para telas grandes do tamanho da área de trabalho e conexões rápidas de banda larga de linha fixa, muitos operadores usam transcodificadores ou servidores proxy que alteram dinamicamente o conteúdo da Web. Eles podem modificar sua marcação HTML ou CSS para atender a telas menores (especialmente para "telefones de recursos" que não têm a capacidade de processamento para lidar com layouts complexos) e podem recompactar suas imagens (reduzindo significativamente sua qualidade) para melhorar as velocidades de entrega de página.

Mas se você se esforçou para produzir uma versão otimizada para dispositivos móveis do seu site, provavelmente não quer que a operadora de rede interfira mais nela. Você pode adicionar a seguinte linha ao evento Page_Load em qualquer ASP.NET Web Form:

Response.Cache.SetNoTransforms();

Ou, para um controlador MVC ASP.NET, você pode adicionar a seguinte substituição de método para que ele se aplique a todas as ações nesse controlador:

protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
    filterContext.HttpContext.Response.Cache.SetNoTransforms();
}

A mensagem HTTP resultante informa transcodificadores e proxies compatíveis com W3C para não alterar o conteúdo. É claro que não há garantia de que as operadoras de rede móvel respeitarão essa mensagem.

Estilo de páginas móveis para navegadores móveis

Está além do escopo deste documento descrever detalhadamente quais tipos de marcação HTML funcionam corretamente ou quais técnicas de design da Web maximizam a usabilidade em dispositivos específicos. Cabe a você encontrar um layout suficientemente simples, otimizado para uma tela de tamanho móvel, sem usar truques de posicionamento HTML ou CSS não confiáveis. Uma técnica importante que vale a pena mencionar, no entanto, é a meta tag do visor.

Determinados navegadores móveis modernos, em um esforço para exibir páginas da Web destinadas a monitores da área de trabalho, renderizam a página em uma tela virtual, também chamada de "visor" (por exemplo, o visor virtual tem 980 pixels de largura no iPhone e 850 pixels de largura no Opera Mobile por padrão) e, em seguida, reduzem o resultado para caber nos pixels físicos da tela. Em seguida, o usuário pode ampliar e aplicar panorâmica ao redor desse visor. Isso tem a vantagem de permitir que o navegador exiba a página em seu layout pretendido, mas também tem a desvantagem de forçar o zoom e o movimento panorâmico, o que é inconveniente para o usuário. Se você estiver projetando para dispositivos móveis, é melhor projetar para uma tela estreita para que nenhuma rolagem horizontal ou zoom seja necessária.

Uma maneira de informar ao navegador móvel qual é a largura do visor por meio da meta tag do visor não padrão. Por exemplo, se você adicionar o seguinte à seção HEAD da página,

<meta name="viewport" content="width=480">

… em seguida, o suporte a navegadores de smartphones colocará a página em uma tela virtual de 480 pixels de largura. Isso significa que, se os elementos HTML definirem suas larguras em termos percentuais, os percentuais serão interpretados em relação a essa largura de 480 pixels, não à largura padrão do visor. Como resultado, é menos provável que o usuário tenha que ampliar e aplicar panorâmica horizontalmente, melhorando consideravelmente a experiência de navegação móvel.

Se você quiser que a largura do visor corresponda aos pixels físicos do dispositivo, especifique o seguinte:

<meta name="viewport" content="width=device-width">

Para que isso funcione corretamente, você não deve forçar explicitamente os elementos a exceder essa largura (por exemplo, usando um atributo de largura ou propriedade CSS), caso contrário, o navegador será forçado a usar um visor maior, independentemente disso. Consulte também: mais detalhes sobre a marca de visor não padrão.

A maioria dos smartphones modernos dá suporte à dupla orientação: eles podem ser mantidos no modo retrato ou paisagem. Portanto, é importante não fazer suposições sobre a largura da tela em pixels. Nem sequer suponha que a largura da tela seja fixa, pois o usuário pode redirecionar seu dispositivo enquanto estiver em sua página.

Dispositivos Windows Mobile e Blackberry mais antigos também podem aceitar as seguintes metamarcas no cabeçalho da página para informá-los que o conteúdo foi otimizado para dispositivos móveis e, portanto, não deve ser transformado.

<meta name="MobileOptimized" content="width" />
<meta name="HandheldFriendly" content="true" />

Recursos adicionais

Para obter uma lista de emuladores e simuladores de dispositivo móvel que você pode usar para testar seu aplicativo Web de ASP.NET móvel, consulte a página Simular dispositivos móveis populares para teste.

Credits

  • Autor principal: Steven Sanderson
  • Revisores / escritores de conteúdo adicionais: James Rosewell, Mikael Söderström, Scott Hanselman, Scott Hunter