Este artigo foi traduzido por máquina.

Navegação móvel

Crie uma experiência de navegação móvel melhor

Steven Sanderson

Quem acessa a Web através de um dispositivo móvel nos dias de hoje? Em 2005, você teria retratado o usuário médio da Internet móvel como um nerd, afluente ocidental — provavelmente um desenvolvedor de software — que levaria tempo para conectar seu celular volumoso para uma rede de dados lenta para suportar uma experiência de navegação dolorosamente limitada — e pagar o dólar superior para o privilégio. Em outras palavras, um caso de limite.

Agora, acesso Web móvel disparou para o mainstream global. E não me refiro apenas a adolescentes, alunos e ex-gente mostrando mutuamente seus smartphones e tablet dispositivos em cada loja de café em toda a Europa e América do Norte. Hoje existem cerca de 1 mil milhões de euros assinaturas ativas de banda larga móveis, suficiente para cerca de um em cada sete pessoas no planeta (e apenas dois em sete utilizam regularmente a Internet por qualquer meio). Dispositivos móveis estão em vias de se tornar a única maneira mais comum para acessar a Web dentro de cinco anos. Já, em alguns dos países mais rápido crescimento — especialmente Índia — celulares são a única maneira para muitas pessoas a ficar on-line. Mesmo na América, 25 por cento dos usuários da Web móveis dizer "nunca" ou "raramente" acessarem a Web usando um PC tradicional. (Para as fontes de informações, consulte "Acesso à Web móvel".)

Claramente, se você estiver criando um site público, você precisa pensar sobre suporte a navegadores móveis.

Por que a navegação móvel é diferente

Como você sabe, apenas sobre cada navegador móvel oferece suporte a alguma forma de HTML. Muitos, especialmente em dispositivos high-end, como iPhones e Windows Phone 7, suportem para os mais recentes padrões HTML, CSS e JavaScript e processam pixel-perfect cópias do que você veria em um navegador de PC tradicional.

A opção mais barata para suporte a navegadores móveis, em seguida, é não fazer nada. Você apenas pode servir as mesmas páginas orientada a área de trabalho para todos os dispositivos e confiar em navegadores móveis para lidar com eles. Mas escolhendo essa opção leva a uma experiência de navegação móvel muito pobre, por várias razões:

• Telas de telemóvel são pequenas. Alguns navegadores móveis, tais como o Opera Mini, lidar com páginas de área de trabalho-largura reformatando dinamicamente os estilos e layout de página. A aparência resultante é raramente que seu designer tinha em mente. Outros navegadores móveis, tais como o Safari para iPhone ou Internet Explorer para Windows Phone 7, renderizar páginas de largura da área de trabalho e, em seguida, forçar o usuário a ampliar e reduzir e deslocar-se para ler o texto. Este é um teste de paciência dos seus visitantes.
• Redes de dados móveis muitas vezes são lentos. Não presuma que os visitantes têm a mesma largura de banda como usuários de banda larga de linha fixa. Eles ainda podem estar pagando por megabyte, para que sites heavyweight não será populares.
• Dispositivos móveis muitas vezes não têm um mouse ou teclado. Mecanismos de interação de usuário desktop familiar sempre não fazem sentido em dispositivos móveis. Por exemplo, clicando em botões ou links de pequeno pode ser difícil e propenso a erros nos dispositivos de toque, e o conceito de "mouse" não pode sequer existe.

Assim, se você deseja fornecer uma excelente experiência de navegação móvel, é hora de aplicar suas habilidades de engenharia e contabilizar as diferenças entre tipos de dispositivos principais.

Suporte móvel em ASP.NET

Há dois aspectos fundamentais para suporte a navegadores móveis:

1. Detectar um determinado visitante é utilizando a que tipo de dispositivo. ASP.NET possui suporte interno para detecção de navegador. Na próxima seção, irá examinar esse mecanismo, e como ele pode ser personalizado e estendido.
2. Produzir saída que funciona bem no dispositivo detectado. Se você verificar através da lista anterior de desafios, você vai perceber que estes não são coisas que seu 
platform de tecnologia pode manipular automaticamente. Suporte móvel é principalmente uma questão de design da experiência (UX) do usuário, não principalmente uma questão de marcação. Neste artigo descreverei meios técnicos para produzir saídas diferentes para diferentes dispositivos, mas é ainda para você a projetar e implementar diferentes layouts e fluxos de trabalho do usuário para celulares.

Note que até por volta de ASP.NET 2.0, lançado em 2005, produzindo saída para trabalhar em dispositivos móveis foi uma questão de marcação, como dispositivos comuns naquela época usados protocolos de especialista e linguagens de marcação, incluindo WAP e WML, cHTML. ASP.NET 2.0 contidos "Mobile controles" para dar suporte a esses formatos. No entanto, esses formatos são agora totalmente obsoletos, porque todos os principais navegadores agora usam HTML, então o ASP.NET Mobile controles também são obsoletos.

Detecção de navegador

O núcleo do ASP.Plataforma NET, que serve de base para Web Forms e Model-View-Controller (MVC), possui suporte interno para detecção de navegador. Você pode encontrar ou não um visitante está usando um navegador móvel usando a propriedade Request.Browser.IsMobileDevice Boolean. No entanto, você deve entender como esta detecção funciona para estar ciente das limitações de precisão que podem afetá-lo.

ASP.NET determina que tipo de navegador está fazendo uma solicitação e quais são os recursos que o navegador tem (tamanho de tela, o suporte de JavaScript e assim por diante), comparando a entrada seqüência de cabeçalho userAgent solicitar contra uma série de expressões regulares em arquivos XML que descrevem navegadores comuns.

Essas expressões regulares — e obter informações sobre recursos de dispositivo correspondente — são armazenados em um conjunto de arquivos. browser na pasta C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers (ou o equivalente da instalação). Por exemplo, o arquivo iphone.browser padrão inclui o código mostrado na Figura 1.

Figura 1 O arquivo iphone.browser

<browsers>
  <!-- Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ 
       (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 -->
  <gateway id="IPhone" parentID="Safari">
    <identification>
      <userAgent match="iPhone" />
    </identification>
    <capabilities>
      <capability name="mobileDeviceModel" value="IPhone" />
      <capability name="mobileDeviceManufacturer" value="Apple" />
      <capability name="isMobileDevice" value="true" />
      <capability name="canInitiateVoiceCall" value="true" />
    </capabilities>
  </gateway>
  ...
</browsers>

No arquivo, o seguinte elemento define a expressão regular a ser comparado com entrada seqüências de cabeçalho userAgent:

<userAgent match="iPhone" />

Uma vez que o sistema encontra uma correspondência expressão regular userAgent, o restante dos dados XML especifica o tipo e capacidades do dispositivo.

A limitação deste sistema é clara: só pode detectar dispositivos móveis que foram conhecidos e descritos nestes arquivos quando ASP.NET 4.0 foi lançado. Infelizmente, isso não inclui comuns navegadores modernos, como o Opera Mobile ou o navegador padrão para o Google Android. Request.browser.IsMobileDevice incorretamente será definido como false para esses navegadores.

Personalizar e melhorar a detecção de navegador

Você tem duas opções principais para superar as limitações do mecanismo de detecção de navegador padrão:

1. Você pode fornecer seus próprios arquivos. browser para representar os dispositivos mais recentes.
2. Você pode usar uma biblioteca de detecção de navegador de terceiros.

Para tirar a primeira opção, botão direito do mouse no nome do projeto no Solution Explorer do Visual Studio e escolha Add | Adicione ASP.Pasta NET | App_Browsers. Você pode adicionar arquivos. browser para essa pasta; por exemplo, ao copiar um arquivo existente de sua pasta de C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers e, em seguida, editando sua identificação regular expressão e dispositivo capacidade descrição para representar o navegador desejado.

Se você não quiser ser responsável pelo controle de todas as centenas de recém lançado navegadores móveis e manter seus arquivos. browser atualizado, você pode tomar a segunda opção e usar uma biblioteca de detecção de navegador de terceiros.

Atualmente, o que eu estou recomendando é 51degrees.Mobi Foundation, uma biblioteca de código aberto (Licença MPL) hospedada no CodePlex na 51degrees.codeplex.com. Esta biblioteca não usa arquivos. browser. Em vez disso, ele identifica os dispositivos por correspondência-los no banco de dados do arquivo de recurso Universal Wireless (WURFL), que pode ser aplicativos livre usados gratuitamente em ambos comercial e não comercial. Para obter mais informações sobre WURFL, consulte wurfl.sourceforge.net.

A maneira mais fácil para instalar o 51degrees.Mobi Foundation em projetos Web Forms ou MVC é usando o Gerenciador de pacotes NuGet. Se você estiver executando o ASP.NET MVC 3, você já tem NuGet. Se não, você pode usar o Visual Studio Extension Manager (que está no menu Ferramentas) para procurar e instalar o NuGet. Depois de ter NuGet, vá para ferramentas | O Gerenciador de pacotes biblioteca | Console do Gerenciador de pacotes e, em seguida, execute o seguinte comando na consola:

Pacote de instalação 51Degrees.mobi

Isso adiciona ao seu projeto:

• Uma cópia recente do banco de dados WURFL para seu projeto em /App_Data/wurfl.xml.gz
• Uma referência a FiftyOne.Foundation.dll, assembly principal da biblioteca
• Entradas de Web. config para habilitar 51degrees.Mobi Foundation

51degrees.Fundação mobi plugado e aprimora o ASP.NET API padrão do Request.Browser. Apenas por ter o pacote instalado, você obterá resultados muito mais precisos de Request.Browser.IsMobileDevice, porque as versões recentes do banco de dados WURFL podem detectar comum navegadores móveis de hoje, incluindo o Opera Mobile e o navegador do Google Android.

Note que o 51degrees padrão.Configurações mobi Foundation Web. config também configurá-lo para redirecionar todas as solicitações de navegadores móveis para o URL ~ / Mobile/Default.aspx. Em muitos casos — e especialmente para ASP.Aplicativos NET MVC — que não vai ser o comportamento desejado. Você pode desabilitar o redirecionamento por comentar para fora ou excluir o <redirect/> elemento que o pacote adiciona ao arquivo Web. config e, em seguida, você também pode excluir seu arquivo /Mobile/Default.aspx se você quiser.

Estilo para Mobiles

Agora que você tem uma idéia de como detectar navegadores móveis com fiabilidade, eu vou mostrar uma maneira chave para controlar como as páginas são processadas por navegadores móveis. Depois disso, vou descrever algumas opções de arquiteturais para variar a marcação processada por tipo de dispositivo.

Muitos navegadores móveis modernos, incluindo Safari para iOS e Internet Explorer para Windows Phone 7, tentam fazer processado páginas olhar apenas como o fazem em um navegador de desktop. Eles sabem que a maioria das páginas são projetados para telas de cerca de 1.000 pixels de largura e o designer tem provavelmente não contabilizados larguras muito menores.

Para resolver isso, eles normalmente processam a página em uma tela virtual conhecida como uma "viewport", geralmente cerca de 1000 pixels virtuais de largura. O navegador pode, em seguida, expandir a exibição visual de que tela virtual arbitrariamente, permitindo que o usuário ampliar e reduzir e deslocar-se. Este arranjo é ilustrado na Figura 2.

Figura 2 navegador móvel a uma página de largura da área de trabalho para uma porta de visualização Virtual de renderização

Enquanto isso permite que a página processar como o designer que se destina, sofre o inconveniente de usabilidade significativos que, quando o usuário está suficientemente ampliado para ler o texto, ele não pode ver a largura total da página e deve rolar horizontalmente para fazê-lo.

Controlando a largura do Viewport

Se você realmente projetou páginas para o pequeno ecrã, você não que que eles para ser dispostas em uma porta de visualização virtual cerca de 1000 pixels de largura. Em vez disso, você suas páginas para ser dispostos em um visor que é a mesma largura que a tela real, para que ele caiba perfeitamente horizontalmente com nenhum zoom necessários.

Muitos dos mais populares navegadores móveis oferecem suporte uma fora do padrão "viewport" meta tag que permite controlar a largura do viewport virtual. Por exemplo, se você adicionar o seguinte para sua página <head> seção, o navegador irá dispor a página em um visor 320 pixels de largura:

    <meta name="viewport" content="width=320"/>

Isto é normalmente um ajuste muito melhor para telefones móveis.

Tenha em mente que alguns dispositivos móveis têm telas com resolução horizontal muito maior. Por exemplo, o iPhone 4 tem 640 pixels físicos por linha. No entanto, ainda faz sentido usar uma porta de visualização virtual de cerca de 320 pixels; caso contrário, o texto resultante será muito pequeno para ler sem aumentar o zoom.

Se desejar, você pode deixar o viewport virtual variam em tamanho de acordo com o dispositivo está sendo usado, usando a seguinte sintaxe:

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

Observe que alguns dispositivos móveis não vai dar-lhe uma largura de dispositivo literal. Eles interpretam "dispositivo-largura" como significando "a largura do viewport virtual que pensa que o fabricante dá o resultado mais agradável". Assim, por exemplo, iPhone 4 define largura de dispositivo como 320 pixels, apesar de sua maior resolução física.

Recomendações de marcação

Sempre que você estiver criando páginas para navegadores móveis:

• Use a tag meta viewport para o viewport ajustar a largura horizontal da tela.
• Ajuste seus layouts de página, estilos CSS e afins para contabilizar essa largura estreita. Se os visitantes não precisam de zoom ou rolar horizontalmente, sua página se sente mais como um aplicativo nativo projetado para o seu dispositivo — uma experiência muito melhor.
• Certifique-se de seus links e botões são grandes o suficiente para ser aproveitado a. Ponta dos dedos é muito maiores do que a ponta de um ponteiro do mouse.
• Minimize os requisitos de largura de banda, não usando imagens de muito alta resolução ou arquivos JavaScript maciços.

Opções de arquiteturais

Você já viu como detectar navegadores móveis, e eu forneci algumas recomendações para marcação que melhor lhes convier. Agora vou descrever três opções simples para estruturar seu aplicativo para produzir saída diferente para tipos diferentes do navegador:

1. Mostrar e ocultar camadas da marcação de acordo com o tipo de navegador.
2. Páginas mestras de acordo com o tipo de navegador de comutação.
3. Apresentando conteúdo totalmente diferente de acordo com o tipo de navegador.

Cada um deles tem suas vantagens e limitações, portanto cabe a você escolher uma abordagem que se adapte às suas necessidades.

Mostrar e ocultar marcação

Se você só precisará incluir ou excluir referências de arquivo CSS de acordo com o tipo de navegador e meta tags, isso é extremamente simple. Por exemplo, em uma página mestra de formulários da Web, você pode adicionar uma instrução "if" dentro de seu <head> seção:

    <head runat="server">
      <title>My site</title>
      <link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />
    
      <% if (Request.Browser.IsMobileDevice) { %>
        <meta name="viewport" content="width=device-width"/>
        <link href="~/Styles/MobileSite.css" rel="stylesheet" type="text/css" />
      <% } %>
    </head>

O equivalente para um layout de barbear para um ASP.NET MVC 3 aplicativo tem esta aparência:

    <head>
      <title>@ViewBag.Title</title>
      <link href="@Url.Content(
        "~/Content/Site.css")" rel="stylesheet" type="text/css" />
      @if (Request.Browser.IsMobileDevice) {
        <meta name="viewport" content="width=device-width"/>
        <link href="@Url.Content(
          "~/Styles/MobileSite.css")" rel="stylesheet" type="text/css" />
        }
    </head>

Esta é uma técnica extremamente básica, mas podem ser adequada se você pode se adaptar a sua marcação existente para caber na tela pequena puramente adicionando regras CSS adicionais em um arquivo separado de MobileStyles.css. Naturalmente, você pode usar o mesmo mecanismo em outros lugares em suas páginas-mestre e modos de exibição para modificar a saída por tipo de navegador.

Essa técnica funciona melhor se você está construindo um site totalmente novo e pode projetar sua marcação para que se adapte às telas móveis e de desktop, dependendo apenas do CSS usado. Nesse caso, o esforço de desenvolvimento adicional necessário é muito baixo. Para muitos sites Esta técnica simples não será suficiente, mas existem duas alternativas: alternar a página mestra ou apresentar conteúdo diferente.

Páginas mestras de comutação

Você pode ser capaz de manter suas páginas de conteúdo existentes inalteradas e apenas adaptar o layout para o pequeno ecrã usando uma outra página mestra ou layout. Por exemplo, se você estiver criando um aplicativo de formulários da Web, você poderia definir uma classe base de página padrão que alterna a página mestra dinamicamente:

public class PageBase : Page
    {
      protected override void OnPreInit(EventArgs e)
      {
        if (Request.Browser.IsMobileDevice)
            MasterPageFile = "~/Mobile.Master";
      }
    }

Em seguida, para qualquer página cujo layout deve variar por tipo de dispositivo, defina sua classe code-behind para herdar de PageBase em vez do habitual UI. Você pode então criar uma página mestra no /Mobile.Master cujo layout e estilo CSS são otimizados para devicess móveis.

É ainda mais fácil para ASP.NET MVC 3 desenvolvedores usando Razor layouts — você pode fazer todos os seus modos de exibição alternar layouts dinamicamente, editando o arquivo /Views/Shared/_Layout.cshtml para conter o seguinte:

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

Em seguida, adicione um novo arquivo de layout de navalha no /Views/Shared/_MobileLayout.cshtml e modificar sua estrutura e estilos CSS de acordo com o dispositivo móvel como você deseja.

Isso dá mais flexibilidade do que a técnica anterior de diferentes segmentos de marcação ocasionais sozinhos e CSS, mas ainda tem a limitação de que tanto páginas móveis e de desktop devem mostrar essencialmente as mesmas informações e usar os mesmos mecanismos de interação.

Apresentar conteúdo diferente

Para alguns aplicativos, você não será capaz de se adaptar suas páginas de área de trabalho de acordo com dispositivos móveis usando apenas CSS diferentes ou páginas mestras e layouts porque:

• Seus requisitos de negócios podem ser demasiado exigente. Se você quer uma experiência móvel verdadeiramente Lisa, talvez precise exibir diferentes (talvez menos) informações para dispositivos móveis e possivelmente guiar o usuário através de fluxos de trabalho diferentes. Por exemplo, o processo de registro de usuário pode ter menos etapas e recolher menos informações para visitantes móveis. Isso é mais do que uma questão de CSS.
• Você pode trabalhar com código herdado que não é passível de alteração desse tipo. Por exemplo, sua marcação existente pode conter estilos e tamanhos de elemento codificado. Modificar esta usando CSS ou outra página mestra pode ser impossível, ou talvez apenas tornar as coisas mais complicadas e menos passível de manutenção.

Em ambos os casos, a melhor solução é usar totalmente separados de lógica e marcação para tipos de dispositivos diferentes. A desvantagem é que você, em seguida, tem duas versões para manter, mas o principal benefício é que o comportamento dos dois pode variar independentemente de qualquer maneira que você quer. Para desenvolvedores Web Forms, a implementação é geralmente um conjunto de páginas ASPX de mobile-específicos e para desenvolvedores MVC, isso normalmente significa criar uma nova área para exibições e controladores de mobile-específicos. De qualquer forma, você vai precisar alguma lógica para redirecionar a entrada visitantes para a página correta dependendo do seu tipo de dispositivo.

Para amostras de código apresentando maneiras de implementar a lógica de redirecionamento de uma forma que é compatível com ambos o cache de saída e faz a autenticação de formulários da Web e MVC, consulte o white paper no bit.ly/gHT3Ap.

Conclusões e recomendações finais

Neste artigo, você aprendeu sobre:

• Por que os navegadores móveis são cada vez mais importantes.
• Porque o grande suporte móvel é principalmente uma questão de design UX, marcação não apenas diferentes.
• Como o núcleo do ASP.Plataforma NET detecta navegadores móveis por padrão.
• Como a abordagem de detecção de navegador padrão é limitada, e como você pode estender ou substituí-lo.
• Como navegadores exibir porte desktop páginas móveis em telas pequenas, e como você pode influenciar o que.
• Opções de arquiteturais para o envio de saída diferente para tipos diferentes do navegador.

Ao selecionar uma combinação de técnicas para melhor se adequar ao seu aplicativo e os usuários finais, minhas recomendações principais são priorizarusabilidade e testá-lo. Não faz sentido implementar suporte móvel se ele acaba dando aos usuários uma pior experiência de navegação! Aqui estão algumas coisas a considerar:

Usuários móveis oferecem uma forma de alternar de volta para modo de exibição normal da área de trabalho. Normalmente, isso significa colocar um link na parte superior das páginas dizendo "Alternar para o modo de área de trabalho". A forma como o switch é implementado depende de sua arquitetura; Ele pode simplesmente link para a versão desktop de um determinado URL, ou ele pode definir um cookie que substitui seu mecanismo de detecção de navegador normal.

Esse recurso é especialmente importante se suas páginas móveis mostram menos informações do seus desktop páginas, porque os usuários avançados será frustrados se eles não podem acessar informações ou recursos que eles sabem que devem estar lá.

Não perca a informação ao redirecionar para uma exibição móvel. Em alguns sites da Web, entrados visitantes móveis são redirecionados para a home page móvel, não importa qual página eles foram solicitando. Isso é extremamente frustrante para os usuários e essencialmente quebra quase todos os links de entrada. Se você não tiver uma versão móvel da página que está sendo solicitada, apenas mostre a versão desktop dele.

Valide sua implementação usando dispositivos reais ou emuladores. Seus layouts móvel-friendly, CSS e meta tags não podem ser tratadas como você espera por todos os dispositivos. Você deve testar em dispositivos reais ou emuladores. Para obter uma lista dos emuladores de dispositivos móveis populares, consulte asp.net/mobile/device-simulators.

It's OK para começar pequeno. Você não precisa criar uma versão mobile-otimizado de cada página e o recurso em todo o site, ao mesmo tempo. Para muitas empresas, a maioria do valor virá de ter uma homepage habilitados para dispositivos móveis e talvez alguns outros workflows de usuário chave tais como o registo e navegação de catálogo.

Para alguns aplicativos de intranet, nunca podem ser relevante oferecer suporte a dispositivos móveis. Mas para qualquer site da Internet pública, você certamente precisará considerar navegadores móveis se estiver permanecer relevante nos próximos anos.

Observação: Como uma alternativa para 51degrees.Mobi Foundation, outra opção para usar WURFL dados em ASP.Aplicativos NET é via a WURFL oficial.NET API, disponível em http://wurfl.sourceforge.net/dotNet e em NuGet como um pacote chamado "wurfl_official_api".

Que a API está disponível sob AGPL e licenças comerciais (ver http://www.scientiamobile.com).

Steven Sanderson trabalha para a Microsoft como gerente de programa da equipe que lhe traz ASP.NET MVC, Web Forms, NuGet e outros relacionados à Web bondade.

Graças aos seguinte perito técnico para revisão deste artigo: Scott Hunter