Windows Phone - Introdução ao jQuery móvel

Artigo
01/28/2013

Wallace McClure

Desenvolvedor, tecnologia Web, Windows Phone

Não há dúvida. Aonde quer que desenvolvedores olhem e com quem quer que falem, mobilidade está no topo da lista. Converse com um executivo de nível C e a conversa se volta para mobilidade, e a pergunta "Como consigo isso?" surge. Fale com outros desenvolvedores e eles lhe dirão que estão visando dispositivos móveis. A mobilidade se tornou um grande negócio conforme os smartphones dominaram o mercado para o consumidor.

Nos anos que levaram ao foco atual em aplicativos e dispositivos móveis,, desenvolvedores Web vêm acrescentando mais e mais funcionalidade no lado do servidor a seus aplicativos. Você pode ver isso no uso de bibliotecas JavaScript como o jQuery no lado do cliente.

Com o crescimento do mercado de dispositivos móveis, a capacidade de se criarem aplicativos executados entre plataformas é muito importante para desenvolvedores e empresas que tentam manter suas despesas sob controle. Há um conjunto de aplicativos, principalmente na área de consumo de conteúdo (pense na Amazon.com), que são bem executados em um navegador Web móvel. Infelizmente, existem diferenças entre navegadores Web em vários dispositivos móveis. O objetivo da biblioteca jQuery Mobile (JQM) é fornecer suporte entre navegadores para permitir que desenvolvedores criem aplicativos que possam ser executados nos vários navegadores Web móveis e fornecer a mesma interface de usuário—ou pelo menos uma bastante similar.

A biblioteca jQuery Mobile foi introduzida em um lançamento alfa no terceiro trimestre de 2010 e liberada para fabricação em novembro de 2011. Enquanto escrevo este artigo, a versão do jQuery Mobile é 1.1.1. Quando você o ler, o jQuery Mobile quase com certeza já terá chegado à versão 1.2.0. A biblioteca foi adotada pela Microsoft, Adobe e outras empresas para desenvolvimento Web móvel. Em agosto de 2011, o jQM tinha uma fatia de 32 por cento do mercado em comparação com outras estruturas JavaScript móveis como WebKit e jQTouch. Essa participação no mercado é impressionante, já que começou do zero pouco mais de 12 meses antes e a versão 1.0 é a primeira versão oficialmente suportada.

Guia de introdução

Vamos começar examinando os conceitos básicos de uma página do jQuery Mobile, como mostrado no código abaixo.

<!DOCTYPE html>
<html>
<head>
<title>jQuery Mobile</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="stylesheet"
href="http://code.jquery.com/mobile/1.1.1/jquery.mobile-1.1.1.min.css" />
<script src="http://code.jquery.com/jquery-1.7.1.min.js" type="text/javascript"></script>
<script src="http://code.jquery.com/mobile/1.1.1/jquery.mobile-1.1.1.min.js"
type="text/javascript"></script>
</head>
<body>
<div data-role="page" data-theme="c">
<div data-role="header">
<h1>jQuery Mobile</h1>
</div>
<div data-role="content">
<p>jQuery Mobile is an HTML, Javascript, mobile library that you will like.
ASP.NET web pages make it easy to build powerful .NET based applications
for the web.
</p>
</div>
<div data-role="footer">
<h4>Friday, July 27, 2012 - Copyright SDI</h4>
</div>
</div>
<body>
<html>

Você deve observar várias coisas.

O doctype (tipo de documento) é o padrão para uma página Web HTML5.
O viewport (visor) está definido em uma metamarca. O viewport é usado pelo navegador para determinar a quantidade de uma página Web a exibir na tela. Dispositivos móveis, por padrão, assumem que as páginas têm 900 pixels de largura, o que "espreme" uma página Web para uma tela daquele tamanho. No código acima, o navegador está definido com a largura da tela do dispositivo.
Uma folha de estilo CSS é carregada para uso pelo jQM.
A biblioteca jQM é carregada e usada pelo jQM.
O arquivo .sj jQM é carregado.
O arquivo .css e os dois arquivos JavaScript são carregados a partir da rede de distribuição de conteúdo (CDN) do jQuery.
A página contém seções de cabeçalho, conteúdo e rodapé.

Certamente você está imaginando o que o jQM dá realmente aos desenvolvedores. Se examinar a página criada pelo código acima em um navegador móvel, o conteúdo é exibido com seções de cabeçalho, conteúdo (ou corpo principal) e de rodapé. Logicamente, o conteúdo é exibido como mostrado na Figura 1.

JJ916264.BF0C497EB0A11AA33CAD2DDEC2F16041(pt-br,MSDN.10).png

Organização básica de uma página em jQM

Atributos

Atributos são uma das primeiras coisas que desenvolvedores notam sobre o jQM. A rigor, os atributos data-* que desenvolvedores veem são parte da especificação HTML5. O nome do recurso é "atributos de dados personalizados" e é definido pela especificação do W3C. Isso permite que desenvolvedores adicionem um atributo personalizado a uma marca ao mesmo tempo em que mantêm uma página jQM móvel válida. O valor para desenvolvedores e que isso permite ao jQM definir atributos personalizados para uma página móvel. O jQM pode então tomar esses atributos personalizados e agir de acordo com eles. Por exemplo, uma marca <div/> com o atributo cabeçalho por ser estilizado automaticamente pela biblioteca sem o desenvolvedor precisar fazer nada Além de definir estilos para um atributo, essa abordagem declarativa permite que ferramentas de desenvolvimento de software adicionem funcionalidade e melhorem a experiência de desenvolvimento.

Você pode estar se perguntando "Ótimo, que tipos de atributos estão disponíveis?" No código mostrado acima, note que os valores de atributos de página, cabeçalho, conteúdo e rodapé estão definidos. Nos referimos a eles como uma função. (O conceito de uma página, cabeçalho, conteúdo e rodapé é bastante autoexplicativo, portanto não o discutirei mais.) No jQM, uma função é definida pelo atributo data-role. Algumas das outras funções vistas em jQM incluem as seguintes.

Navbar define uma barra de navegação, que é tipicamente exibida dentro de um cabeçalho.
A função button exibe um botão, tipicamente utilizando um link <a href>.
listview é o equivalente móvel de tabelas com grades de dados que fazem parte da metáfora Web de área de trabalho.

Modelo móvel jQuery

Aplicativos geralmente têm muitas páginas associadas. Pode-se encontrar muita discussão sobre se colocarem página móveis em um único arquivo—e motivos válidos para tal—, mas a verdade é que tentar colocar seu aplicativo completo em uma única página não é realista. Se o Twitter não consegue acertar isso, provavelmente você também não tem os recursos necessários para fazê-lo 100% certo.

Vejamos como isso funciona para desenvolvedores em ASP.NET. Primeiro, pense nas várias pilhas de renderização ASP.NET que pode usar. Existe o ASP.NET WebForms, que existe desde a versão 1.0 do Microsoft .NET Framework. O WebForms foi um grande aperfeiçoamento do ASP clássico. Infelizmente para o mundo móvel, o viewstate e o controle limitado sobre a saída HTML são um problema para desenvolvedores, então deixaremos essa tecnologia de lado. (Não é difícil resolver essas questões, mas elas demandam muito mais trabalho do que este artigo pode descrever.)

A maioria dos desenvolvedores vai querer usar uma tecnologia diferente, uma que lhes dê mais controle sobre a situação. Felizmente, a Microsoft tem outras opções. Elas são as plataformas ASP.NET MVC e ASP.NET Web Pages. As duas abordagens usam o mecanismo de visualização Razor para fornecer a linguagem de desenvolvimento no lado do servidor que apresentará o HTML resultante. Há outros mecanismos de visualização disponíveis, mas este artigo lida com "o que há na caixa ASP.NET".

O código abaixo mostra um modelo que usa o mecanismo de visualização Razor.

<!DOCTYPE html>
<html>
<head>
<title>@Page.Title</title>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="stylesheet"
href="http://code.jquery.com/mobile/1.1.1/jquery.mobile-1.1.1.min.css" />
<script src="http://code.jquery.com/jquery-1.7.1.min.js" type="text/javascript"></script>
@if (IsSectionDefined("Head"))
{
@RenderSection("Head", false);
}
<script src="http://code.jquery.com/mobile/1.1.1/jquery.mobile-1.1.1.min.js"
type="text/javascript"></script>
</head>
<body>
<div data-role="page">
<div data-role="header">
@if (IsSectionDefined("HeaderSection")) {
@RenderSection("HeaderSection", false)
}
else {
<h1>@Page.Title</h1>
}
</div>
<div data-role="content">
<p>@RenderBody()</p>
</div>
<div data-role="footer">
@if (IsSectionDefined("FooterSection")) {
@RenderSection("FooterSection", false)
}
else {
<h4>@DateTime.UtcNow.ToLongDateString() - Copyright SDI</h4>
}
</div>
</div>
<body>
<html>

No arquivo de layout, note várias coisas.

Os arquivos jQM .css, jQuery .js e jQM .js são todos carregados a partir de uma CDN. Carregar de uma CDN ajuda desenvolvedores, pois, com a popularidade do jQM, há uma grande probabilidade de que bibliotecas jQM já sejam armazenadas no cache por outro aplicativo Web na máquina do usuário. Se as bibliotecas já estiverem carregadas, você notará um aumento no desempenho sobre o carregamento dessas bibliotecas a partir o servidor Web de seu aplicativo. No mundo móvel,. largura de banda, latência e conectividade geral são recursos preciosos. Tudo que se possa fazer para melhorar o desempenho é bom. Um motivo secundário, e ligeiramente mais egoísta, é que carregar arquivos a partir de um servidor de aplicativos consome uma certa quantidade de largura de banda. Largura de banda custa dinheiro em algum nível, portanto podem-se poupar fundos de desenvolvimento usando-se a CDN de outra pessoa. Como uma observação marginal, não quero discutir CDNs em muitos detalhes neste artigo. Três CDNs populares com que estou familiarizado são as da Google, do jQuery e da Microsoft. Dave Ward tem uma postagem de blog ótima sobre CDNs. Você encontrará um link na lista de referências no final deste artigo.
A configuração da estrutura de página básica. Existem seções para um cabeçalho, conteúdo e rodapé. Cada uma dessas seções de conteúdo tem um conjunto correspondente de código no lado do servidor. Se a página de conteúdo não tiver uma HeaderSection definida, uma padrão é enviada ao usuário. A mesma abordagem ocorre com a FooterSection. Cada uma dessas seções é opcional. O corpo da página é a única seção obrigatória para nosso modelo. O corpo de nossa página de conteúdo será exibido nessa área.
Note o título e a seção do cabeçalho. O motivo para a seção do cabeçalho é que o evento mobileinit deve ser criado antes que o arquivo .js do jQM seja carregado. Você saberá mais sobre o evento mobileinit mais adiante neste artigo.

Controles e HTML móveis

Desenvolvedores podem usar uma variedade de novos elementos de forma no mundo HTML móvel. Eles vêm da especificação HTML5. Aqui estão alguns dos tipos de entrada da especificação:

range—usada para inserir um valor numérico com valores mínimo e máximo.
tel—usada para inserir um número de telefone. O usuário vê um teclado otimizado para números para a digitação.
url—esse é um tipo de entrada de URL através do qual um campo de texto é apresentado ao usuário. O usuário vê um teclado otimizado para URL para a digitação.
search—o tipo de entrada de pesquisa.
number—o tipo de entrada de número para se inserir um valor numérico a partir do teclado.
date, datetime, time, datetime-local, month e week—esses são uma série de controles associados com data e hora que fazem parte da especificação HTML5.

Junto com esses controles estão uma série de atributos que desenvolvedores podem usar para fornecer assistência adicional ao usuário e controle ao desenvolvedor.

Uso automático de maiúsculas—o atributo autocapitalize pode ser usado para definir o uso padrão de maiúsculas em uma caixa de texto. Isso pode ser útil para usuários quando digitam um nome próprio.
Autocorreção—o atributo autocorrect pode ser usado para ativar ou desativar a capacidade de correção automática em uma caixa de texto.
Espaço reservado—o atributo placeholder fornece uma descrição ao usuário sobre o que ele deve inserir em uma caixa de texto.

Você pode estar imaginado por que um desenvolvedor precisa se preocupar com esses controles. E é uma pergunta muito válida. Se desenvolvedores tirarem proveito desses controles e atributos novos, a estrutura do jQM fornecerá os estilos necessários aos controles para que sejam exibidos com a aparência de um controle nativo. Por exemplo, dê uma olhada no código a seguir.

<input type="text" placeholder="input" />
<input type="range" min="0" max="100" value="50" />
<input type="tel" value="555-1212" />
<a href="Default.cshtml" data-role="button">Save Data</a>

Neste código, o atributo placeholder é usado em um controle de entrada de texto. O jQM fornece algum estilo, como os cantos arrendondados mostrados na Figura 2. O controle range é um controle HTML5 e será estilizado como o uma controle deslizante pelo jQM. O tipo de controle tel é um controle de número telefônico. No iPhone, selecionar o número resulta em uma ligação. No Android 4.0.3 (usado na captura de tela), o navegador embutido não suporta o tipo de entrada tel, mas note que quando o tipo de entrada tel é selecionado, o teclado otimizado para telefone é exibido. Finalmente, temos uma marca <a> que tem o atributo data-role=”button”. O resultado é que a marca <a> é estilizada como um botão pelo jQM.

JJ916264.A1CFEBAEA05362E9B81D468EA15B7CB6(pt-br,MSDN.10).png

Figura 2. JQM Provided Styling

Nem todos os elementos de forma são suportados por todos os navegadores Web móveis. Se um desenvolvedor usar um elemento de forma não suportado, o navegador usará o padrão de exibir um elemento de campo de forma de texto no lugar do controle não suportado. O desenvolvedor pode lidar com essa situação determinando se o navegador fornece o suporte necessário. Para essa tarefa, a biblioteca Javascript Modernizr é muito popular.

Observação

Os novos controles móveis no HTML5 não fazem parte do jQuery Mobile. Eu os mencionei aqui, pois o HTML5 foi amplamente implementado (pelo menos parcialmente) em dispositivos móveis. Então o jQM pode tomar esses controles, atributos e outros elementos e atualizar sua exibição. Por exemplo, o jQM toma o controle de entrada type=”range” e exibe um controle deslizante com uma caixa de texto que tem o valor atual do controle deslizante.

Se você não quiser toda a estilização fornecida pelo jQM, definir o atributo data-role="none" em uma marca desativa a estilização do jQM para aquele controle.

Como o jQuery Mobile aplica estilização e aparência?

O jQM tem uma abordagem simples à estilização. Por padrão, o jQM faz o seguinte:

Toma a abordagem mais leve possível, o que significa que desenvolvedores e designers não têm de lutar com um sistema de estilização complexo.
Permite que a renderização nativa do navegador tenha precedência.
Adiciona preenchimento para leitura mais fácil. O preenchimento acrescentado deve ser de uma quantidade relativamente pequena.
Usa o sistema de temas jQM para aplicar um "visual" para fontes e cores. (Você saberá mais sobre temas mais adiante no artigo.)

O jQM também implementa "aprimoramento progressivo" e "degradação normal”. Isso significa que, quando um aplicativo é executado em um navegador avançado, ele suportará as capacidades mais avançadas do navegador e, quando for executado em um navegador menos avançado, o jQM dimensionará os recursos que utilizar.

Controle listview

Junto com os tipos de entrada HTML5, o jQM fornece um novo controle chamado listview, que fornece uma visualização de dados e navegação. Tipicamente, dados em um listview são vinculados de alguma forma, ou no servidor (e depois enviados ao dispositivo móvel) ou criados através de uma chamada a um serviço Web através de AJAX.

Aqui está um código simples para um listwiew:

<ul data-role="listview">
<li><a href="Default.cshtml">Windows 8</a></li>
<li><a href="Default.cshtml">Windows Phone</a></li>
<li><a href="Default.cshtml">Windows RT</a></li>
</ul>

Note que uma lista não ordenada é usada junto com uma série de itens de lista. O atributo data-role para a lista não ordenada é definido como listview. Através da configuração do atributo data-role, o jQM entende que o controle é um listview e fornece a aparência do UITableView do iOS.

Você pode ver a saída do código listview na Figura 3. Há os três links exibidos no código e também um acessório de imagem mostrando que, ao tocar o item, o usuário será redirecionado para a URL definida no <a href>. Por fim, dependendo do dispositivo em que o usuário executar o código, um item listview é sobreado conforme o usuário arrasta um dedo pelo controle.

JJ916264.CB99D5256B49B5301C2EB19E556828A2(pt-br,MSDN.10).png

Figura 3. Um listview simples exibido no emulador de Windows Phone

Agora vejamos um exemplo ligeiramente mais complicado de um listview. Aqui, acrescentaremos separadores, um controle de pesquisa e instruções no controle de pesquisa.

<ul id="listViewMore" data-filter="true"
data-filter-placeholder="Search OSs" data-role="listview"
data-autodividers="true">
<li data-role="list-divider">A</li>
<li><a href="Default.cshtml">Android</a></li>
<li data-role="list-divider">I</li>
<li><a href="Default.cshtml">iPhone</a></li>
<li><a href="Default.cshtml">iPad</a></li>
<li data-role="list-divider">L</li>
<li><a href="Default.cshtml">Linux</a></li>
<li data-role="list-divider">W</li>
<li><a href="Default.cshtml">Windows 8</a></li>
<li><a href="Default.cshtml">Windows Phone</a></li>
<li><a href="Default.cshtml">Windows RT</a></li>
</ul>

Neste listview, definir o atributo data-filter como true ativa o controle de pesquisa e o associa com o listview. Um ótimo recurso embutido é que digitar o controle de pesquisa atualiza automaticamente o listview com os registros que corresponderem aos critérios de pesquisa. Definir o o valor data-filter-placeholder resulta em um espaço reservado sendo exibido em dispositivos que suportem o atributo placeholder. O código também usa o atributo data-autodividers. Definir esse valor como true cria um divisor automaticamente. O divisor é criado usando a primeira letra da exibição. Pessoalmente, descobri que isso não é confiável. Descobri que definir o atributo data-role de um item de lista como "list-divider" era muito mais confiável.

A Figura 4 mostra as configurações mais avançadas do listview exibido em um dispositivo Android, tomadas em uma sessão do emulador de Android x86 executado no navegador nativo.

JJ916264.5B18470A2E164A6AFBB42CECF98034DE(pt-br,MSDN.10).png

Figura 4. Listview com divisores e pesquisa em um dispositivo Android.

Observação

Se um aplicativo precisar adicionar dados dinamicamente a um listview, você pode precisar invocar o método refresh no listview. Isso é feito pelo método javascript $(“#listid”).listview(‘refresh’);
Nesta amostra de código, “#listid” é a ID do listview que o programa precisa atualizar e é mostrado em notação jQuery padrão.

Navegação

Navegação é muito importante em aplicativos móveis. Por exemplo, não há espaço suficiente na tela para um grande botão Voltar no alto do aplicativo. Em iOS, aplicativos tipicamente implementam um botão do estilo Voltar no cabeçalho. Em Android, dispositivos têm um botão Voltar no hardware ou no software que os usuários podem selecionar facilmente para retornar à tela anterior. Como essa navegação deveria acontecer em um aplicativo jQM? O jQM facilita aos aplicativos fornecerem sua própria navegação, mas, reconhecidamente, isso dá ao aplicativo a aparência de um aplicativo iOS por padrão.

Dê uma olhada no código a seguir dentro de um cabeçalho. O resultado é mostrado na Figura 5.

<a href="Default.cshtml" data-icon="check">Save</a>
<h1>Edit Contact</h1>
<a href="Default.cshtml" data-icon="delete" data-theme="b">Exit</a>

Note os atributos data-icon definidos no código. Há uma série de ícones pré-definidos. Na Figura 5, as marcações <a> são automaticamente convertidas em botões com cantos arredondados.

JJ916264.BF98C3D7868CFD9817B5C95533E7F801(pt-br,MSDN.10).png

Botões de navegação criados em jQM

Para um botão fora do cabeçalho, você pode aplicar o atributo data-role="button” a uma marca <a>. Acrescentar o atributo data-rel=”back” a um link no cabeçalho cria um botão Cancelar.

Carregamento de página e AJAX

Para navegar entre páginas, o jQM usa a marca <a>. Isso é HTML padrão, então o que pode ser tão empolgante a respeito? Bem, o jQM toma as marcações <a> de um aplicativo e fornece algumas melhorias à experiência de navegação proporcionada aos usuários.

Primeiro, quando o usuário navega entre páginas em um aplicativo Web executado na área de trabalho, tipicamente há um clarão e a tela fica em branco por um curto período enquanto o conteúdo é carregado. Em um aplicativo móvel executado em um dispositivo móvel, não há clarões enquanto as telas são carregadas. Geralmente, ocorre uma pequena animação e um indicador é exibido enquanto a tela recupera quaisquer dados que precisar exibir ao usuário. Não seria ótimo se um aplicativo Web móvel pudesse fornecer a tela e transições diretas de um aplicativo móvel nativo?

Felizmente, o jQM fornece a infraestrutura para suportar a experiência nativa de aplicativo móvel em aplicativos Web móveis. O jQM não oferece isso para todas as páginas, então vejamos os vários casos. Em um aplicativo Web móvel, há a tendência de haver vários tipos de links:

Links dentro de uma página do aplicativo levando a uma página diferente
Links dentro de uma página do aplicativo levando a uma página diferente do mesmo arquivo físico
Links para outros aplicativos jQM
Links para aplicativos não jQM
Links móveis especiais, como os para um número telefônico para ligar para outra pessoa.

Para os propósitos desta discussão, me concentrarei na navegação entre páginas do mesmo aplicativo. Um exemplo simples: Começamos na página 1. Quando o usuário clica no link para a página 2, vê uma sequência de transição curta, por padrão um símbolo giratório, e depois a página 2. Um exame da URL mostra que contém a página 1 seguida por um hash (#) e depois uma referência à página 2. A mágica do carregamento da página é feita para via jQM, carregada por uma solicitação AJAX.

Agora, o que acontece quando se quer carregar uma página, mas não através de uma solicitação AJAX? Há duas maneiras (possivelmente mais) de se desabilitar o carregamento de uma página baseado em AJAX. Para se fazer isso via código, adicione o atributo data-rel=”external” a uma marca <a>. Isso força um link a ser usado como um link externo absoluto em jQM. Além disso, adicione o atributo data-ajax=”false” a um link. Isso força o jQM a agir como se o link fosse um link externo absoluto.

Temas de exibição e amostras de cor

Você já pode ter notado que as escolhas de cor padrão do jQM são tediosas e muito parecidas com o iOS. Desenvolvedores têm a oportunidade de mudar esse comportamento através dos temas de cor. No jQM, um tema define as cores do texto e do fundo, gradientes e fontes usados para exibir conteúdo. Se você tiver familiaridade com o sistema UI ThemeRoller do jQuery, trabalhar com temas jQM será bastante fácil.

O sistema de temas jQM vem com cinco amostras pré-definidas identificadas como A, B, C, D e E (veja a Figura 6):

O tema A tem o nível mais alto de prioridade visual. Os usuários verão um uso expressivo do preto nesse tema.
O tema B tem uma quantidade secundária de prioridade visual. Os usuários verão um uso expressivo do azul nesse tema.
O tema C tem uma quantidade básica secundária de prioridade visual. Os usuários verão um uso expressivo do cinza nesse tema.
O tema D tem um nível secundário alternativo. A diferença entre os temas C e D é uma ligeira variação nas cores de fundo, que podem não ser distinguível na figura ou em dispositivos. Cabe ao desenvolvedor ver se há alguma diferença em sua situação específica.
O tema E é uma amostra de destaque.

JJ916264.C988DD70EDBA9DED6DAC514E0E2B26B3(pt-br,MSDN.10).png

Figura 6. Variações no sistema de temas jQM

Além disso, você pode criar seus próprios temas usando o jQM ThemeRoller, disponível em http://jquerymobile.com/themeroller/.

Eventos e configuração do jQM Mobile

Se você estiver familiarizado com o jQuery, tem familiaridade com o evento .ready de documentos. Esse evento dispara quando o documento de uma página é carregado e é muitíssimo valioso quando uma página Web é inicialmente carregada. A página então pode criar qualquer conteúdo dinâmico na inicialização. No mundo móvel, isso se torna ainda mais valioso, porque os usuários têm uma quantidade limitada de largura de banda e precisamos de eficiência em nossa utilização de dados.

O jQM carrega páginas de forma diferente do jQuery. No jQuery, o navegador é responsável apenas pelo carregamento de páginas. Com o jQM, as páginas são carregadas pelo navegador via jQM, o que eu já abordei em uma seção anterior. O efeito para o desenvolvedor é que não há garantias de que o evento .ready de um documento seja invocado quando uma página é carregada via jQM. Para ajudar a lidar com isso, o jQM expõe um evento chamado mobileinit. O evento mobileinit é disparado quando uma página é carregada via jQM e apresentada ao usuário. O evento mobileinit é tratado no elemento document e vinculado usando o método de vinculação do jQuery, como se pode ver aqui.

<script language="javascript" type="text/javascript">
$(document).bind('mobileinit', function () {
// Put your initialization code here
alert("jQM has been successfully initialized.");
});
</script>

Depois do evento mobileinit, há muitos outros que podem ser tratados, inclusive

Na criação, carregamento ou exibição de uma página.
Widgets podem expor um evento quando seu layout mudar.
Eventos de orientação que lidam com como dispositivos móveis podem ser movidos e girados.
Eventos de gesto, para que o usuário possa executar eventos de toque.
Eventos de clique virtual, que são uma série de eventos que ajudam a lidar com os eventos touchstart e touchmove sem se precisar trabalhar com detalhes específicos de uma determinada plataforma.

Uma vez disparado o evento mobileinit do jQM, um novo objeto, $.mobile, fica disponível a partir do objeto principal $ do jQuery. Dentro do objeto $.mobile, desenvolvedores podem alterar muitas das configurações padrão no jQM.

Observação

O evento mobileinit deve ser configurado antes que o arquivo .js do jQuery Mobile seja carregado.

Eventos de página

Cada página jQM tem um conjunto de eventos de criação, carregamento e exibição:

pagebeforeload, pageload e pageloadfailed são disparados quando uma página externa é carregada.
pagebeforechange, pagechange e pagechangefailed são eventos de alteração de página. Esses eventos são disparados quando um usuário está navegando entre páginas nos aplicativos.
pagebeforeshow, pagebeforehide, pageshow e pagehide são eventos de transição de página. Esses eventos são disparados antes, durante e depois de uma transição e são nomeados.
pagebeforecreate, pagecreate e pageinit são para inicialização de página.
pageremove pode ser disparado e depois tratado quando uma página é removida do DOM.
O código abaixo mostra alguns exemplos. Neste trecho de código, há vários pontos a observar:
O código força o AJAX a ser habilitado. Se o AJAX não for habilitado, alguns eventos podem não disparar.
Quando os eventos disparam, a função para lidar com eles usam dois parâmetros. Esses parâmetros podem retornar dados razoavelmente complexos.
Desenvolvedores de aplicativos provavelmente se interessarão pelos eventos de transição de página.
Para desenvolvedores em ASP.NET WebForms, esses eventos são conceitualmente muito similares a eventos no lado do servidor.
Os eventos pagebeforecreate e pageshow são disparados quando a página com a ID "dois" é carregada. O evento pageload é disparado quando qualquer página é carregada a partir da atual.
$(document).bind("mobileinit", function () {
$.extend($.mobile, {
ajaxEnabled: true
});
$("#two").live("pagebeforecreate", function (event, data) {
alert("pagebeforecreate called");
})
$(document).bind("pageload", function (event, data) {
alert("pageload called");
})
$("#two").live("pageshow", function (event, data) {
alert("pageshow was called");
});
});

Eventos de gestos

Gestos são uma ação bastante comum em ambientes de toque. Arrastar um dedo pela tela é uma operação natural para movimentação entre páginas, navegar entre registros e assim por diante Aqui está uma amostra de código em que um alerta é disparado para um gesto:

$(document).bind("mobileinit", function () {
$(document).live("swiperight", function () {
alert("swipe right");
});
});

Eventos de orientação

Uma das coisas interessantes em dispositivos móveis é que eles não ficam em uma posição fixa na tela. Deixando de lado todas as piadas sobre não segurar o iPhone da forma correta, às vezes o usuário muda a orientação do dispositivo quando usa um aplicativo, o que pode acontecer como resultado de uma movimentação geral do dispositivo, passá-lo para outra pessoa ou algo similar. Por exemplo, o programa College Football Scoreboard da ESPN na temporada 2011 acompanhava a orientação do dispositivo. Se a orientação do dispositivo passasse para paisagem, o placar não se ajustava corretamente, e o usuário recebia uma mensagem para mudar a orientação. Embora um tanto inconveniente, isso era feito através do rastreamento das mudanças de orientação do dispositivo. Rastrear e vincular o evento de orientação no jQM é simples, como se pode ver aqui:

$(window).bind("orientationchange", function (orientation) {
alert(orientation);
})

Observação

Muitos desses eventos não funcionarão da forma apropriada se o carregamento do AJAX estiver desativado.

Resumo

O móvel está definitivamente popular e se tornando cada vez mais importante a cada dia. Como já havia escrito aplicativos Web antes do jQuery Mobile, acredite quando eu digo que o jQM facilitou muito minha vida.

Uma das coisas com que luto é o que deve entrar em um artigo e o que deve ficar de fora. Espero sinceramente que este artigo ofereça as informações necessárias e o ajude a começar trabalhar com desenvolvimento Web móvel com o jQM Mobile.

Internet Explorer e HTML5

Reconhecidamente, o HTML5 ainda é um alvo difícil de acertar. Em maio de 2011, o W3C passou o HTML5 para um status de "última chamada" para confirmar que o padrão era tecnicamente sólido. Em maio de 2012, a especificação HTML5 voltou para o status “trabalho em curso”. Isso significa que ainda há muito trabalho a ser feito. O WHATWG renomeou seu padrão HTML5 como HTML. Para desenvolvedores, há muita confusão sobre o que é e o que não é HTML5.

Embora muitas partes do padrão HTML5 ainda estejam em desenvolvimento, há muitas que são sólidas e implementadas em vários navegadores. Alguns desses recursos incluídos com o lançamento recente do Internet Explorer 10 estão relacionados abaixo. Espero que você esteja tão empolgado quanto eu para colocá-los em uso.

H.264 e marcação de vídeo. Com suporte para o padrão de vídeo h.264, o IE precisa de um plug-in de navegador a menos para exibir vídeo. O H.264 é o padrão de formato que os principais sites adotaram, e o Internet Explorer o suporta. Junto com o suporte para o codec, a marca de vídeo agora é suportada.
Marcação de áudio embutida. O HTML5 fornece suporte para uma marca de áudio embutida no HTML5. O Internet Explorer suporta os codecs mp3 e aac.
Elementos gráficos vetoriais escaláveis (SVG). O SVG permite a criação de elementos gráficos que se dimensionam, pois são desenhados com vetores, não com imagens.
CSS3: CSS é como a Web é formatada. O IE9 suporta CSS3 baseado em padrões, como seletores, namespaces, cor, valores, planos de fundo, bordas e fontes.
AppCache. O AppCache permite que páginas Web armazenem recursos em cache localmente. Isso ajuda desenvolvedores a acelerarem aplicativos, pois recursos podem ser acessados localmente e não a partir de um servidor remoto.
Arrastar e soltar. Suporte para o atributo draggable torna arrastável qualquer elemento HTML em uma página. Além disso, o atributo files foi adicionado ao objeto dataTransfer para permitir suporte a arrastar e soltar para um ou mais arquivos de seu sistema de arquivos local para um site.
Formulários Suporte para os novos tipos de entradas HTML5, novos atributos para os elementos input e progress foram acrescentados.
Histórico. Suporte para a interface Histórico foi adicionado. Isso ajudará a melhorar a pilha do histórico de um site e o controle da URL.

Para uma lista de mais recursos adicionados ao Internet Explorer para suportar HTML, visite esta URL no MSDN na Central de desenvolvedores do Internet Explorer: https://msdn.microsoft.com/en-us/library/ie/hh673546%28v=vs.85%29.aspx.