Guerra dos navegadores do Android e iPhone, Parte 1: O WebKit é a salvação!

Construa um aplicativo de monitoramento de rede para navegador

Os dispositivos móveis exercem hoje um papel cada vez mais crescente em nossa vida. Nós os usamos para nos comunicarmos. Nós os usamos para navegar. Nós os usamos até como lanterna de mão. Enquanto os aplicativos personalizados são extremamente populares para as plataformas do iPhone e do Android, há uma oportunidade nos aplicativos móveis da Web. Este artigo é o primeiro de uma série de dois artigos sobre desenvolvimentos de aplicativos baseados em navegador para iPhone e Android. Ao longo do caminho, construiremos um aplicativo de monitoramento de rede simples que seja executado dentro dos limites do desktop e dos dois navegadores móveis.

Frank Ableson, Software designer

Frank Ableson é um empreendedor e desenvolvedor de software no norte de Nova Jersey, especializado em software de aplicativo móvel e embutido. Atualmente ele está escrevendo um livro sobre o desenvolvimento de aplicativo do Android para a Manning Publications. Seu interesse profissional é em sistemas embutidos, comunicações sem fio e eletrônicos automotivos. Seus maiores fãs são sua esposa, Nikki, e seus filhos.



28/Dez/2009

Apresentação

Juntas, as plataformas do iPhone e do Android possuem mais de 100.000 títulos de aplicativos disponíveis para download em suas respectivas lojas de aplicativos. Os aplicativos nativos são aqueles criados com um SDK de plataforma e depois compilados e instalados em um dispositivo. Esses aplicativos nativos fornecem acesso completo às capacidades inerentes de um dispositivo, incluindo recursos como rede sem fio, Bluetooth, armazenamento de dados, medidor de aceleração, bússola e outros encantos no dispositivo que os tornam tão atrativos. Apesar de os aplicativos nativos ou personalizados serem extremamente populares para as plataformas do iPhone e do Android, há uma oportunidade enorme para os aplicativos móveis da Web. A tecnologia móvel chegou à maturidade — e, com ela: a Web Móvel.

Este artigo é o primeiro de uma série de duas partes sobre desenvolvimento de aplicativos baseados em navegador para iPhone e Android, cujo objetivo é ajudar a desenvolver seus próprios aplicativos móveis da Web. Os aplicativos móveis da Web podem ser mais do que a renderização de um Web site em um dispositivo móvel. Veremos algumas das principais tecnologias e técnicas que tornam o desenvolvimento da Web móvel uma disciplina obrigatória.

A Web se tornou a plataforma escolhida porque resolve muitos dos problemas que tradicionalmente atormentam desenvolvedores de aplicativo e administradores de sistema. Algumas destas soluções:

  • Os aplicativos da Web são fáceis de implementar — Apenas instale ou os copie para o servidor e os seus clientes indicarão a seus navegadores a URL correta.
  • Os aplicativos da Web escalam bem com server farms em centros de dados de alto desempenho e são atendidos por ferramentas de gerenciamento de Web site prontamente disponíveis.
  • Os aplicativos da Web centralizam o armazenamento de dados, simplificando, portanto, os planos de recuperação de desastre.
  • A combinação de HTML, Cascading Style Sheets (CSS), JavaScript e imagens gráficas fornecem uma experiência impressionante de interface do usuário que excede em muito as capacidades dos SDKs nativos (falta de uma experiência de jogos imersiva e completa) e a maioria das experiências do aplicativo não garantem experiência de jogos ou em cabine.
  • A maioria dos aplicativos requer elementos de UI fáceis de usar para guiar os usuários por uma série de operações cotidianas.

O aspecto mais atraente do modelo de distribuição de aplicativo da Web é a habilidade de tornar o software um serviço orientado a assinatura, o que é um verdadeiro teorema ganhar-ganhar. "Como?", você se pergunta. Vamos dar uma olhada rápida.

Os modelos de implementação da Web permitem que os clientes experimentem antes de comprarem, com risco e custo mínimos. Se o cliente gosta do teste, continuar com o serviço é só uma questão de transação de cartão de crédito (ou PayPal). Os fornecedores de software se beneficiam porque as atualizações do sistema são simplificadas, reduzindo os custos de suporte e, por fim, minimizando os custos transferidos para o cliente. E, ainda, o modelo software as a service (SaaS) permite que os clientes obtenham os benefícios do software sem um investimento inicial alto, — trazendo o retorno sobre o investimento financeiro em um mês, em vez de em algum momento de um futuro nebuloso.

Parece ótimo. O que funciona para a Web funciona para móvel, certo? Bem, até que o iPhone apareceu, a resposta era um sonoro não. Por que isso acontece?

A verdade é que a experiência de navegador móvel da Web tem deixado muito a desejar. Mas tudo isso tem mudado, graças à tecnologia conhecida como WebKit, que deixou sua marca na tecnologia móvel em massa através do iPhone.

O iPhone passou da linha de largada para o cliente da Web móvel Nº 1 no mundo, em alguns poucos anos. Por quê? Porque o WebKit, junto com uma conectividade à internet confiável, torna o trabalho da Web para móvel — muito mais do que quaisquer outras opções de navegador atual. O restante do mercado de trabalho móvel tem prestado atenção a isso e está usando o WebKit, observando-o ou dando desculpas.

Então, o que é o WebKit?


WebKit e HTML5

O WebKit é o mecanismo de navegação por trás do navegador Mobile Safari encontrado no iPhone, assim como a tecnologia por trás do navegador no Android. O WebKit também está encontrando seu caminho para outras configurações móveis, mas vamos manter nossa discussão nas plataformas do iPhone e do Android.

O WebKit é um projeto de software livre que retorna às suas raízes do K Desktop Environment (KDE). O projeto do WebKit tornou possível o moderno aplicativo da Web para dispositivos móveis. Apesar de as capacidades do dispositivo e o fator forma serem extremamente importantes, os usuários móveis crescem em conteúdo. Se o único conteúdo disponível para um usuário móvel é um pequeno subconjunto do conteúdo geral disponível na internet, a experiência será no máximo de segunda categoria.

A maioria de nós prefere viver vidas integradas — se usamos um Web site em casa no laptop, o mesmo conteúdo deveria estar acessível quando estivéssemos sentados no trem. Conteúdo é o aplicativo matador. Independentemente de onde estejamos e do que estivermos fazendo, queremos acesso aos nossos dados. O WebKit permite um conteúdo rico nas plataformas do iPhone e do Android.

Vale a pena notar que o WebKit também é usado no desktop no navegador Safari, que é o navegador padrão da plataforma do Mac OS X. Seja discutindo a versão de desktop ou o mecanismo do navegador no iPhone ou Android, o WebKit está na frente no que diz respeito a suporte a recurso HTML e CSS. Na realidade, o WebKit suporta estilos CSS que estão como ainda não adotados por outros navegadores — os recursos sendo considerados pela especificação HTML5.

A especificação HTML5 é uma coleta de rascunhos técnicos que cobre uma variedade de tecnologias baseadas em navegador, incluindo armazenamento apto a SQL do lado cliente, transições, transformação, tradução e muito mais. A HTML5 está em andamento há algum tempo, e, embora ainda não completa, quando seu conjunto de recursos se firmar com o principal suporte de plataforma de navegador, o início com poucos recursos dos aplicativos da Web serão nada mais do que uma vaga lembrança. O desenvolvimento de aplicativo da Web será dominante — e não apenas na área de cobertura do navegador do desktop tradicional, mas também no espaço móvel. A tecnologia móvel será uma ideia de início, em vez de uma ideia tardia.


Considerações sobre aplicativos móveis da Web

Para acessar tecnologias de desenvolvimento da Web, o desenvolvedor de aplicativo de hoje tem poucas escolhas à disposição. Primeiro, o aplicativo pode ser escrito estritamente como arquivos HTML, CSS e JavaScript em um servidor. É claro que o conteúdo HTML pode se originar de arquivos HTML estáticos ou ser gerado dinamicamente de qualquer uma das inúmeras tecnologias do lado do servidor, como PHP, ASP.NET, Java Servlets, etc. Todas essas tecnologias podem ser reduzidas ao termo HTML para simplificar — isso não é realmente relevante para essa discussão — e, o mais importante, o navegador movido pelo WebKit interpreta e renderiza o HTML no dispositivo móvel.

O usuário acessa o aplicativo da Web no dispositivo móvel (ou seja, iPhone ou Android) ao abrir o aplicativo do navegador e inserir a URL do servidor desejado: http://yourcompanyname.com/applicationurl.

Um aplicativo da Web móvel em particular se ajustará a algum lugar em uma sequência contínua, abrangendo de um Web site genérico a um aplicativo da Web móvel altamente específico de plataforma.

Renderização de Web site genérico

O mecanismo de renderização no WebKit, junto com a UI altamente intuitiva encontrada nas plataformas do iPhone e do Android, permite que praticamente qualquer Web site baseado em HTML seja visualizado no dispositivo. As páginas da Web são renderizadas corretamente, diferente da experiência histórica de navegador móvel, em que o conteúdo fica escondido ou simplesmente não é mostrado. Quando a página carrega, o conteúdo será frequentemente ampliado até o fim, de modo que a página inteira fique visível, embora bem pequena e potencialmente em uma escala ilegível, como mostrado na Figura 1. No entanto, a página pode ser prontamente rolada, exibida em panorama, pressionada e ampliada, fornecendo acesso ao conteúdo completo. Por padrão, o navegador usa uma porta de visualização, ou dimensão lógica, de 980 pixels de largura.

Figura 1. Página da Web ampliada até o fim no carregamento
The content will often be zoomed all the way out such that the entire page is visible, albeit very small

Ao mesmo tempo em que isso fornece acesso à página inteira e é um grande aprimoramento da experiência de Web móvel histórica, mais pode ser feito para melhorar a experiência móvel.

Tecnologia móvel fácil

Para acabar com a sequência contínua da página da Web genérica em direção a uma tecnologia móvel fácil, o aplicativo da Web pode ser modificado em algumas áreas.

Apesar de a página ser renderizada apropriadamente no WebKit, há algumas diferenças entre um dispositivo centrado em mouse, como um laptop ou um computador desktop, em comparação a um dispositivo centrado no toque, como um iPhone ou smartphone Android. As principais áreas de divergência incluem o tamanho físico das áreas "clicáveis", a falta de "estilos pop-up" e uma sequência de evento totalmente diferente. Aqui está um rápido resumo daquilo que se deve ter em mente ao fazer o design de um Web site que será visualizado por usuários móveis:

  • O navegador do iPhone/Android irá renderizar a tela de modo muito legível— muito melhor do que em navegadores móveis típicos — portanto, não se apresse em fazer uma versão móvel diluída do seu site.
  • Os dedos são maiores do que os ponteiros do mouse. Tenha isso em mente quando for fazer o design de navegação clicável — não coloque links muito próximos um do outro porque o usuário não será capaz de pressionar um link sem pressionar o link ao lado.
  • Estilos pop-up não funcionam porque você "não passa o mouse" com seu dedo da mesma maneira que faria com um ponteiro de mouse.
  • Eventos como mover o mouse para baixo, mover o mouse, etc. são simplesmente diferentes em dispositivos baseados em toque. Alguns desses eventos irão disparar, mas não confie que terão a mesma sequência que vê nos navegadores de desktop.

Os detalhes disso são publicados em iPhone in Action (consulte Recursos). Para o nosso objetivo, focaremos mais naquilo que o WebKit pode fazer, em vez de naquilo que ele não pode fazer.

Vamos ver o desafio mais óbvio ao se fazer um Web site fácil para um visitante de iPhone ou Android: o tamanho da tela. O tamanho real da tela móvel em uso hoje é de 320 x 480. Observe que ele também pode ser de 320 x 480 se os usuários escolherem visualizar o conteúdo da Web na orientação paisagem. Como vimos na Figura 1, o WebKit irá renderizar páginas da Web orientadas a desktop muito bem, embora o texto possa ser pequeno demais para que se leia o conteúdo efetivamente sem ter de pressionar e ampliar. Então, o que faremos em relação a isso?

A maneira mais direta e não intrusiva para o desktop de acomodar o usuário móvel é através do uso de uma metatag especial: porta de visualização.

A metatag é uma tag HTML colocada no elemento principal de um documento HTML. Aqui está um exemplo simples do uso da tag de porta de visualização: <meta name="viewport" content="width=device-width" />. Quando essa metatag é adicionada a uma página HTML, vemos que a página é escalada de forma mais apropriada para o dispositivo móvel, como mostrado na Figura 2. A tag é simplesmente ignorada por navegadores que não a suportam.

Figura 2. Página escalada de forma apropriada para dispositivos móveis
When this metatag is added to an HTML page, we see that the page is scaled more appropriately for the mobile device

Em alguns casos, pode-se desejar pré-escalar a janela para um valor específico, como mostrado na Figura 3.

Figura 3. Pré-escalação da janela
It may be desirable to pre-scale the window to a particular value

Para definir uma escala específica, o atributo content da metatag de porta de visualização é definido para um valor explícito: <meta name="viewport" content="width=device-width, initial-scale=1.0 user-scalable=yes" />. Mudando o valor inicial da escala, a tela pode ser ampliada ou reduzida conforme desejado. Definir o valor para algo entre 1,0 e 1,3 é apropriado para as plataformas do iPhone e do Android, respectivamente. A metatag de porta de visualização também suporta escala mínima e escala máxima, que podem ser usadas para limitar quanto controle um usuário tem sobre a renderização da página.

Apesar de o fator forma do iPhone não ter mudado desde que estreou com um layout de 320 x 480, o Android promete ter características físicas mais variadas à medida que mais dispositivos chegarem ao mercado, de múltiplos fabricantes, destinados a diferentes populações de usuários. Essa variação potencial no tamanho da tela, fator forma e resolução são coisas para se ter em mente ao desenvolver aplicativos e direcionar dispositivos móveis como o Android.

Além das diferenças físicas de um dispositivo Android para o outro, a experiência tem mostrado que o software do Android tem exercido mais controle sobre a renderização de páginas por meio de configurações do navegador no dispositivo. Apesar de estável, a plataforma do Android também é muito fluida. As configurações em um dispositivo em particular provavelmente diferem do ambiente de desenvolvimento, dependendo do nível do SDK e do fabricante. A Figura 4 mostra uma captura de tela da página de configurações de um aplicativo de navegador tirada da V1.6 do Emulador do Android. A tela de configurações permite que o usuário configure um dispositivo para um nível de zoom predefinido (longe, perto, médio) ou solicite que o dispositivo auto-ajuste páginas.

Figura 4. Página de configurações do Emulador do Android
Image shows a screenshot of the settings page from the browser application taken from V1.6 of the Android Emulator

No mundo móvel, a maior constante é a mudança, de modo que isso promete ser uma espécie de paisagem mutável. Por exemplo, as configurações para o navegador do Sprint Hero possuem um conjunto inteiramente diferente de opções no que diz respeito à renderização de página. O Hero é construído sobre o Android V1.5 mais uma série de aprimoramentos fornecidos pela HTC. Felizmente, essas configurações serão substituídas pela metatag de porta de visualização, se esta estiver presente na sua página da Web.

Até aqui, vimos o WebKit renderizar uma página da Web normal bastante bem, apesar de um pouco pequena e difícil de ler sem um pouco de zoom. A seguir, exercemos controle sobre a experiência do usuário, controlando como a página é vista no dispositivo através do uso da metatag de porta de visualização. Isso tornou a página mais fácil de ler e navegar. Mas, e se quisermos ir adiante e fazer com que o Web site pareça um aplicativo móvel?

Feito para móvel

Agora vamos dar uma olhada em uma estratégia de design ao direcionar para um público móvel. Como um estudo de caso rápido, vamos analisar a página de login do serviço de e-mail Gmail do Google.

Primeiro, vamos dar uma olhada na experiência do navegador do desktop na Figura 5.

Figura 5. Navegador do desktop
Image shows the desktop browser experience

A tela principal do desktop possui conteúdo de informação à esquerda e uma área de assinatura à direita. Compare a visualização do desktop com a visualização específica para móvel na Figura 6, tirada do iPhone.

Figura 6. Visualização específica para móvel do iPhone
Screenshot shows the mobile-specific view from the iPhone

A tela mostrada na Figura 6 é certamente direcionada a um usuário móvel. O usuário é diretamente avisado sobre aquilo que é necessário para seguir adiante com o aplicativo — sem necessidade de pressionar, ampliar ou rolar.

A seguir, vamos dar uma olhada na funcionalidade do aplicativo do GMail móvel ao ler uma mensagem. Devido ao espaço limitado disponível para o aplicativo, a janela de leitura de mensagens tem pouca oportunidade de apresentar botões ou navegação. Qualquer espaço dedicado a navegação tira espaço do conteúdo de leitura. E também não queremos cair na armadilha de ter múltiplos quadros ou elementos de rolagem div se pudermos evitar. O GMail móvel resolve esse problema fornecendo um simples menu flutuante que aparece sempre que a página parar de rolar. O menu possui três botões: Archive, Delete, e More. Selecionando o botão More, itens adicionais do menu são exibidos, como mostrado na Figura 7.

Figura 7. Menu flutuante
Selecting the More button displays additional menu items

Esse é um aplicativo que foi feito para móvel.

Outra coisa para se ter em mente é que não queremos diluir a experiência móvel para visitantes que estão executando navegadores muito capazes, como os encontrados nas plataformas do iPhone e do Android. Com esse intuito, veja o que o GMail mostra na parte inferior da página na Figura 8.

Figura 8. Deixando a decisão para o usuário
Image showing the the user decides

Se seu usuário prefere a maior funcionalidade da versão para desktop, deixe que ele a use. Sempre que possível, deixe o usuário decidir.

Agora, vamos supor que você queira construir um aplicativo que usa tecnologias da Web, mas que na verdade se pareça com um aplicativo nativo.

Conteúdo específico para plataforma

A próxima etapa é criar um conteúdo destinado específico para plataforma, formatando uma página para que ela se pareça o máximo possível com uma página nativa para a plataforma de destino, em vez de um Web site genérico. O que queremos dizer com nativo?

Antes de entrar nas especificidades de como uma página da Web parece um aplicativo nativo para uma plataforma em particular, vamos fazer uma visita pelas diferenças visuais entre as plataformas do iPhone e Android — deixando de lado por agora suas fortes relações baseadas em navegador.

O iPhone possui uma aparência distinta. Mostre a alguém uma captura de tela de um iPhone e, a menos que estejam vivendo sob uma rocha, há uma boa chance de que a imagem será identificada como vinda de um iPhone. Mostre à mesma pessoa uma captura de tela de um dispositivo Android e o resultado provavelmente será diferente. Por que isso acontece? Há algumas razões para isso. A principal razão é o fato de que ele está no mercado há mais tempo, e ele possui um grande número de seguidores que o cultuam. Lembram-se das pessoas em fila durante horas para pagar um bom dinheiro por um recurso limitado do iPhone V1? Tenha um iPhone ou não, a Apple é um ícone no mercado de trabalho de hoje. E o Android?

O Android é relativamente novo e é, em muitos aspectos, o anti-iPhone, já que mais ou menos abraça a comunidade de software livre. O Android será usado em múltiplos dispositivos (telefones e outros dispositivos do tipo ferramenta). Por ora, vamos manter nossa discussão nos telefones móveis para manter as coisas o mais simples possível.

A o longo do tempo, o número de dispositivos para o Android provavelmente passará o iPhone no mundo inteiro. Isso porque os dispositivos mantidos pelo Android estão sendo produzidos por múltiplos fabricantes e estarão disponíveis em múltiplas redes de transportadoras no mundo todo. Com um número maior de jogadores participando do mercado do Android, certamente haverá fragmentação em termos de aparência. Já vimos isso com a interface SenseUI da HTC. Essa aparência atraente não está disponível no SDK principal do Android e não é compatível com todos os dispositivos. A Motorola, o Google e a Verizon se juntaram para criar um novo dispositivo do Android: o DROID. E o primeiro dispositivo comercial do Android executado na plataforma 2.0.

Compare a diversidade do Android com a aparência consistente do iPhone. O iPhone é o bem de valor da Apple. A aparência do iPhone pode evoluir com o tempo, mas é muito pouco provável que sofra a fragmentação que o Android já está mostrando ainda no início.

Então, onde encontrar uma aparência nativa?

Antes da Web 2.0, isso seria um desafio real. Tentativas anteriores de suportar múltiplos navegadores cliente (móvel e não móvel) incluíram uma porção de técnicas diferentes, como:

  • Web sites totalmente paralelos
  • Conteúdo gerado dinamicamente baseado em userAgent
  • Servidores proxy que iriam refinar o conteúdo para o dispositivo; a RIM fez uso extensivo e bem-sucedido dessa abordagem para renderização de e-mail no dispositivo

Essas abordagens podem ser aceitáveis para equipes grandes bem fundadas, mas e o resto do mundo? Não temos tempo, talento ou riqueza para mudar para esse tipo de capacidade. E, como já vimos, a Web móvel de ontem era insuficiente, então não queremos chegar até lá, de qualquer modo.

E felizmente, não temos que fazer isso. Na era do WebKit e CSS, essas diferenças podem ser rapidamente adaptadas através do uso de folhas de estilo e pesquisas de mídia. Como dito anteriormente, uma consulta de mídia é uma técnica para se obter informações sobre o cliente. Tradicionalmente, os navegadores enviavam uma cadeia de caractere userAgent, que identificava o navegador, e o servidor fazia o trabalho de calcular o conteúdo a ser enviado para o dispositivo (de acordo com a discussão acima). Com uma pesquisa de mídia, o navegador toma a decisão com base em suas capacidades. Aí vai um exemplo de como se obter uma folha de estilo destinada a smartphone: <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (max-device-width: 480px)" />. E aí está uma pesquisa de mídia direcionada a um computador desktop: <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (min-device-width: 481px)" />.

Internet Explorer V6

À época desse artigo, o Internet Explorer V6 tem cerca de 20 a 30% de participação no mercado, mas incluir o IE V6 está além do escopo deste artigo.

Para saber mais sobre consultas de mídia, consulte o rascunho da especificação (consulte Recursos).

Vamos dar uma olhada em um exemplo, usando essa abordagem no contexto de um aplicativo de exemplo que exibe o status da rede.


Aplicativo de monitoramento de rede

O objetivo desse aplicativo é monitorar múltiplos servidores. Desenvolvedores de software independentes sempre se encontram na situação de suportar múltiplos aplicativos através de múltiplos servidores. E se você está no jogo há algum tempo que seja considerável, é provável que os tipos de servidores e os tipos de aplicativos irão variar. Tudo isso é para dizer que pode não haver uma ferramenta única que possa monitorar prontamente cada aspecto de cada aplicativo que você precisa monitorar. E aí que entra o aplicativo móvel Network Monitor (netmon). Ele não foi projetado para ser exaustivo, mas flexível e prático no seu dispositivo móvel.

O aplicativo netmon contém uma lista dos servidores de interesse. Cada entrada exibe key performance indicators (KPIs). Os KPIs têm sido a base dos estudantes de MBA para medir aspectos chaves da saúde de um negócio. Na terra do hosting de aplicativo da Web alguns KPIs importantes podem incluir:

  • Número de transações em um período de tempo recente:
    • Pedidos
    • Solicitações de catálogo
    • Mensagens de e-mail
    • Visualizações de página
  • Período de tempo desde a última transação:
    • Pedido
    • Documento EDI
    • Mensagem de parceiro de negócio
    • Arquivo FTP do fornecedor
  • O banco de dados está disponível?
  • Data do último backup conhecido
  • Quantidade de dólares em média por pedido
  • Espaço remanescente no disco
  • Largura de banda transferida na última hora, no último dia, no último mês

Esses itens e qualquer número de outras partes de dados operacionais servem para pintar um quadro da saúde de um sistema ou aplicativo em particular. Durante as férias, realmente olhamos o número de pedidos colocados em alguns de nossos Web sites. Se o número não estiver crescendo de forma constante hora a hora, damos uma olhada mais de perto.

Como as necessidades e recursos necessários variam em cada aplicativo, o aplicativo netmon precisa ser flexível para acomodar as particularidades de cada aplicativo. Para acomodar esse requisito de flexibilidade, começamos com a estrutura de dados mais básica para representar a saúde de um sistema especifico; na Parte 2, nos preocuparemos com de onde vêm esses dados e como eles se atualizam. Por ora, estamos interessados nas seguintes informações:

  • Nome do Web site
  • URL (home page) do Web site
  • URL para obter atualizações
  • Status: OK ou não?
  • Resumo: Breve descrição da condição; isso será um OK ou uma cadeia de caractere de texto descrevendo o problema de maior prioridade
  • Itens: É uma coleta de pares de nome/valor usada para transmitir estatísticas operacionais atuais ou KPIs para o Web site

Nosso aplicativo listará esses itens de uma forma fácil de navegar, alavancando as capacidades de CSS, jQuery e WebKit para fazer as entradas se manterem. Como mencionado, o objetivo é o de que esse aplicativo seja executado no iPhone, Android e também em uma versão para desktop do Safari.


Construindo o aplicativo

Hoje, as páginas da Web deveriam ser criadas de forma declarativa, fornecendo somente organização e conteúdo. Todo o posicionamento e formatação são obtidos através de Cascading Style Sheets e frequentemente com a ajuda de JavaScript. Na verdade, as bibliotecas JavaScript se tornaram tão conhecidas que estão se tornando a regra, em vez de exceção. No aplicativo de exemplo deste artigo, alavancamos a conhecida estrutura JavaScript da jQuery. Esse aplicativo de exemplo irá renderizar no iPhone, Android e também no desktop. O conteúdo HTML é exatamente o mesmo. As diferenças vêm das folhas de estilo selecionadas. Um aviso: Pouco foco foi dado em fazer a aparência do aplicativo parecer bacana. Na verdade, as cores de fundo estão grosseiramente exageradas para provar um ponto de vista sobre a organização da folha de estilo do aplicativo. Vamos limpar o apelo visual do aplicativo na Parte 2. O HTML é mostrado na Listagem 1.

Listagem 1. HTML para o aplicativo
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="viewport" content="width=device-width" />
<link rel="stylesheet" href="netmon.css" type="text/css" />
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="netmon.js"></script>

<script type="text/javascript">
   if (navigator.userAgent.indexOf('iPhone') != -1) {
      document.write('<link rel="stylesheet" href="iphone.css" 
type="text/css" />');
   } else if (navigator.userAgent.indexOf('Android') != -1) {
      document.write('<link rel="stylesheet" href="android.css" 
type="text/css" />');
   } else {
      document.write('<link rel="stylesheet" href="desktop.css" 
type="text/css" />');
   }

function setupTestData() {
   try {
      netmon.initialize();
      if (netmon.resources.length > 0) {
         jQuery.each(netmon.resources,function (index, value) {
            $("#mainContent").append(netmon.render(index,value));
         });
         $(".serverentry").click (function() {$(this).find(".serveritems").toggle();});
         $(".serveritems").hide();
      }
   } catch (e) {
      alert(e);
   }
}
   
</script>
   
<title>My Network Resources</title>
</head>
<body onload="setupTestData();">
<div id="mainContainer">
   <div id="header">
      <h1>My Servers</h1>
   </div>
   <div id="mainContent">
   </div>
   <a href="q.php">My User Agent</a>
</div> 
</body>
</html>

Uma rápida olhada no HTML mostra alguns itens que se devem observar:

  • Há dois arquivos JavaScript carregados externamente: um para a biblioteca jQuery e um para as funções de ajuda de nosso aplicativo.
  • O uso da metatag de porta de visualização para ajustar a escala de renderização do conteúdo.
  • Uma folha de estilo principal é carregada: netmon.css.
  • A userAgent é interrogada para determinar qual folha de estilo adicional será carregada: uma para iPhone, uma para Android e uma para Desktop.
  • Quando a página é carregada, os dados são exibidos através da ajuda da jQuery e da função de ajuda do arquivo netmon.js.
  • A distribuição da página contém algumas tags div.
  • Por fim, há um link para uma página para mostrar a cadeia de caractere userAgent. Isso foi colocado por conveniência e para finalidades demonstrativas apenas. Não tem nada a ver com o aplicativo em si.

Antes de entrar na questão das folhas de estilo e do arquivo netmon.js em que todo o trabalho é feito, vamos dar uma olhada no aplicativo em sua forma atual. Lembre-se de que estamos usando três folhas de estilo diferentes direcionadas a três plataformas suportadas. Cada uma é configurada com uma cor de fundo diferente para ajudar no processo de desenvolvimento. A Figura 9 mostra o navegador Safari para Desktop com um fundo azul.

Figura 9. Aplicativo mostrado no navegador Safari no desktop
Screenshot shows the Desktop Safari browser with a blue background

A Figura 10 mostra o aplicativo renderizado no navegador do Android com um fundo vermelho.

Figura 10. Aplicativo no navegador do Android
Screenshot shows the application rendered on the Android broswer with a red background

A Figura 11 mostra o aplicativo renderizado no navegador do iPhone com um fundo verde.

Figura 11. Aplicativo no navegador do iPhone
Screenshot shows the application rendered on the iPhone browser with a green background

A folha de estilo principal está no arquivo chamado netmon.js, mostrado na Listagem 2.

Listagem 2. A folha de estilo principal
body {
   color: #888888;
   font-family: Helvetica;
   font-size:14px;
   margin: 0px;
   padding: 0;
}
.details {
   margin: 0px;
   padding: 0px;
   background-color: white;
   border: solid;
   border-width: 1px;

   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
}
.OK {
   color: #000000;
}
.BAD {
   color: #ff0000;
}
.odd {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#ccc) 
,to(#999));
}
.even {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#999) 
,to(#ccc)); 
}
.serverentry a {
   float: right;
   color: #ffffff;
}
.serveritems{
   color: #000;
}

#header h1 {
   margin: 0;
   padding: 0;
   text-align: center;
   color: #000;
}

As folhas de estilo específicas para plataforma cumprem três objetivos principais:

  1. Mudar o esquema de cores como uma demonstração grosseira do impacto de uma folha de estilo e para demonstrar como é fácil destinar uma folha de estilo específica a uma plataforma em particular na userAgent.
  2. Para ajustar os tamanhos de fonte entre as plataformas desktop e móvel.
  3. Para exercitar a funcionalidade específica do WebKit. Isso é importante se o nosso alvo é um navegador não capaz de suportar o WebKit no desktop, como o Firefox.

Como exemplo, o arquivo iphone.css é mostrado na Listagem 3.

Listagem 3. Arquivo iphone.css
body {
   background-color: #00ff00;
}
.serverentry {
   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
}
.name {
   font-size: 2em;
}
.summary{
   font-size: 1.5em;
}
.serverentry a {
   font-size: 1.5em;
}

Nesse arquivo, vemos que a cor de fundo da tag do corpo é ajustada para verde (#00ff00) e o ajuste fino de alguns tamanhos de fonte para tornar as entradas mais fáceis de serem lidas no dispositivo móvel.

Por últimos, vamos dar uma olhada no netmon.js, que contém uma lista de entradas junto com uma função projetada para renderizar uma entrada, mostrado na Listagem 4. Alguns dados foram omitidos desta listagem para fins de redução, embora uma cópia completa esteja disponível (consulte download).

Listagem 4. netmon.js
var netmon = {
   initialize : function () {
   },
   resources : 
   [
      {
         name : 'msiservices.com',
         homeurl : 'http://msiservices.com',
         pingurl : 'http://msiservices.com/netmon.php',
         status : 'OK',
         summary : 'OK',
         items : 
         [
          {name : 'DiskSpace', value : '22.13 GB'},
          {name : 'Database Up?', value : 'Yes'}
         ]
      },
      {
         name : 'server 2',
         homeurl : 'http://someurl',
         pingurl : 'http://someurl/netmon.jsp',
         status : 'OK',
         summary : 'OK',
         items : 
         [
          {name : 'DiskSpace', value : '100.8 GB'},
          {name : 'Database Up?', value : 'Yes'}
         ]
      },
// additional entries clipped for brevity

   ],
   render : function(index,itm) {
      try {
         var ret = "";
         ret += "<div class='serverentry " + itm.status + " " + (index % 2 == 0 ? 
'even' : 'odd') + "'>";
         ret += "<span class='name'>" + itm.name + 
"</span>&nbsp;&nbsp;<a target='_blank' href='" + itm.homeurl + 
"'>Show</a><br />";
         if (itm.status != "OK") {
            ret += "<span class='summary'>-" + itm.summary + 
"</span><br />";
         }
         
         ret += "<div class='serveritems'>"; 
         jQuery.each(itm.items,function (j,itemdetail) {
            ret += ">>" + itemdetail.name + "=" + itemdetail.value + 
"<br />";
         });
         ret += "</div>";      
         ret += "</div>";
         return ret;
      } catch (e) {
            return "<div class='error'>Error rendering item [" + itm.name + "] 
" + e + "</div>";
      }
   }
};

Quando uma entrada de servidor não está no estado OK, ela é mostrada em vermelho, graças à definição de classe no arquivo CSS. Além disso, quando o status não está OK, exibimos o campo de resumo para fornecer uma visualização rápida do problema. Nas figuras 9 a 11, o problema com o servidor 4 é pouco espaço em disco. Se pressionarmos em uma entrada, podemos ver os detalhes, como mostrado na Figura 12.

Figura 12. Detalhes do servidor 4
Screenshot shows Server 4 details when an entry is tapped

Pressionando o link show à direita de cada entrada, iniciamos a página inicial de cada servidor. Esse é um recurso útil por dois motivos. Primeiro, é uma chateação ter que lembrar cada URL de servidor que nos interessa e, segundo, é uma chateação ainda maior ter que digitar um URL longo em um dispositivo móvel, não importa o quanto o teclado seja bom.

Com o netmon sendo executado perfeitamente em nosso dispositivo móvel, suportar nossos servidores deveria ser uma tarefa mais fácil.

Na Parte 2, iremos completar esse aplicativo, de modo que possamos requisitar mais dados em tempo real e discutir algumas das considerações do lado do servidor sobre construir um aplicativo móvel.

Antes de encerramos, vamos dar uma rápida espiada no que seria necessário para tornar esse aplicativo disponível para download a partir de uma loja de aplicativos.


Levando um aplicativo da Web para o metal

Imagine que o aplicativo de monitoramento de rede está feito. Você o mostra a um amigo e ele o incentiva a vender o aplicativo para outros, para que eles também possam monitorar recursos em suas redes com o seu aplicativo. É possível vender um aplicativo da Web? Um aplicativo da Web certamente pode ser vendido através de assinatura tradicional ou do modelo SaaS, mas e se você quiser empacotar seu "aplicativo da Web" e vendê-lo no mercado de trabalho, como na iTunes App Store ou no Google Marketplace? Para fazer isso, o aplicativo precisa ser compilado como um aplicativo nativo. Felizmente, há uma solução para isso.

Cada uma das plataformas móveis principais possui meios de embutir um navegador em uma visualização ou forma, ou atividade. Cada plataforma possui um termo ligeiramente diferente para essa técnica, mas todos trabalham de forma semelhante: Um controle de navegador é colocado no aplicativo nativo e este pode interagir com ele. No modelo mais simplista, o controle do navegador pode ir para a Web simplesmente por causa de seu conteúdo. Ou, o aplicativo nativo pode interceptar requisitos de link e fornecer seu próprio conteúdo, alavancando, assim, a visualização do browser somente para renderização. Lembre-se de que HTML e CSS são alternativas viáveis para widgets nativos, independentemente da fonte de conteúdo do aplicativo. E alguns aplicativos serão um híbrido dessas duas abordagens. Por exemplo, um aplicativo pode pegar a maior parte de seu conteúdo da Web, mas o "lado nativo" do aplicativo fornece acesso a recursos locais através do Bluetooth.

Há algumas ferramentas disponíveis no mercado só para esse tipo de arquitetura de aplicativo. PhoneGap e Appcelerator são dois líderes nessa área (consulte Recursos).


Resumo

Este artigo serviu como uma introdução aos aplicativos da Web do iPhone e Android, movidos pelo WebKit. Na Parte 2, esse aplicativo exemplificativo é expandido para incorporar atualizações de página ao vivo através da tecnologia de mudança da Web do Ajax.


Download

DescriçãoNomeTamanho
Network app source codeos-androidiphone1-browserwars1sourcecode.zip23KB

Recursos

Aprender

Obter produtos e tecnologias

  • Faça o Download do Android SDK, acesse a referência API, e obtenha as últimas informações sobre o Android.
  • O Android é um software livre, o que significa que você pode obter seu código de origem a partir do Android Open Source Project.
  • PhoneGap é uma ferramenta de desenvolvimento de software livre para construção rápida e fácil de aplicativos móveis JavaScript.
  • Confira o Appcelerator para criar, testar e distribuir aplicativos nativos móveis e de desktop, usando tecnologias da Web.
  • Inove em seu próximo projeto de desenvolvimento em código aberto com o IBM trial software, disponível para download ou em DVD.
  • Faça download das IBM product evaluation versions ou explore the online trials in the IBM SOA Sandbox e utilize as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=459175
ArticleTitle=Guerra dos navegadores do Android e iPhone, Parte 1: O WebKit é a salvação!
publish-date=12282009