Apresentando o Dojo Mobile

A maioria dos celulares no mercado atual tem navegadores da web com todos os recursos e que quase não têm diferença dos navegadores para desktop. Esses navegadores da web remotos podem lidar com a maioria das tecnologias da web recentes como HTML5, CSS3, JavaScript, manipulação de DOM e Ajax.

O Dojo Toolkit evoluiu para o desenvolvimento de aplicativos da web para desktop e , além disso, o Dojo também pode ser executado em navegadores da web remotos. Como o Dojo já fornece diversos widgets úteis, realmente precisamos de algo especial para aplicativos remotos? Sim, por diversas razões:

1. Diferenças do dispositivo de entrada: a maioria dos dispositivos móveis não tem um mouse ou teclado físico. Em vez disso, eles fornecem uma tela de toque que suporta operações com os dedos. Interações do usuário em aplicativos para desktop—operações de arrastar e soltar, ações de mouse sobre item, atalhos de teclado e navegação (passagem usando a tecla TAB ou setas de tecla) e assim por diante—são desafios no dispositivo móvel. Quaisquer widgets de UI para celular deve ser habilitado para toque.
   
   
2. Tamanho de tela menor: A tela de um celular é pequena e o usuário usa um dedo em uma tela de toque. É muito importante projetar apropriadamente a UI para celular. Além disso, o tamanho de tela de um tablet é muito maior do que a tela de um smartphone. Aplicativos da web remotos precisam de uma interface com o usuário que se transforme de acordo com o tamanho de tela ou orientação da tela.
   
   
3. Problemas de desempenho: apesar de a potência de processamento de dispositivos móveis estar aumentando rapidamente, eles ainda têm menos poder de computação do que computadores desktop. Além disso, a largura de banda de rede do celular é muito menor do que a de um desktop; às vezes extremamente menor. Os aplicativos da web para celular devem ter uma área de cobertura extremamente pequena e de alto desempenho.

Dojo Mobile é um conjunto de widgets com base em Dojo para a criação de aplicativos da web remotos. Ele foi apresentado no Dojo 1.5 como dojox.mobile a fim de resolver os problemas mencionados acima. Os problemas de dispositivo de entrada e tamanho da tela, no entanto, pode ser resolvido com uma abordagem tradicional, ou seja, simplesmente aprimorando os widgets Dojo existentes adicionando suporte remoto sem reinventá-los apenas para celular. Mas, obviamente, os problemas de desempenho não podem ser resolvidos dessa maneira. Portanto, uma das tarefas mais importantes (e desafiadoras) para o Dojo Mobile é resolver os problemas de desempenho, especialmente minimizando o tamanho do código.

Voltar para parte superior

Widgets de UI sem imagens

Um dos recursos interessantes do Dojo Mobile é que ele não usa imagens para desenvolver widgets de UI. Navegadores com base em WebKit, que são os navegadores mais populares em dispositivos móveis, suportam CSS3. Recursos do CSS3, como planos de fundo da matiz, caixas de canto arredondadas e transformação de elementos DOM, podem lidar com a representação gráfica sempre usar imagens. Figura 1 mostra alguns dos widgets de UI fornecidos pelo Dojo Mobile. Esses widgets não usam imagens; em vez disso, usam elementos DOM como <div> com estilos CSS para desenvolver suas UIs. O uso de muitas imagens pode aumentar o tamanho total do download e o número de solicitações HTTP para o servidor, causando a degradação do desempenho. O Dojo Mobile evita isso usando recursos CSS3 o máximo possível.

Por outro lado, os aplicativos de usuário podem usar imagens. Figura 2 mostra exemplos fornecidos como arquivos de teste do Dojo Mobile. Como você pode ver, os botões da barra de guias, ícones de item de lista e ícones de contêiner de lista são imagens. O uso excessivo de imagens pode degradar o desempenho, mas isso é uma opção para o aplicativo. O próprio Dojo Mobile não usa imagens e nem força o aplicativo usuário a usar imagens. Além disso, como você verá posteriormente, o Dojo Mobile fornece alguns mecanismos úteis, como os botões DOM e CSS sprite, o que pode reduzir a necessidade de imagens e o número de solicitações HTTP para o servidor.

Voltar para parte superior

CSS Sprite

Quando o uso de imagens é inevitável, há duas maneiras possíveis de minimizar a degradação do desempenho. Uma forma é reduzir o tamanho do arquivo de suas imagens reduzindo o número de cores ou aumentando a taxa de compactação. A outra maneira é reduzir o número de solicitações HTTP para imagens agregando várias imagens de tamanho pequeno em uma única imagem grande. A imagem grande combinada pode ser cortada e ajustada com as propriedades de CSS de modo que possa ser usada como uma das imagens pequenas. Essa técnica é conhecida como CSS Sprite e o Dojo Mobile a suporta.

A Listagem 1 mostra um exemplo de itens de lista, cada um usando um ícone separado. A Figura 3 mostra o resultado. Esse exemplo produz três solicitações HTTP para imagens.

<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-1.png" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-2.png" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-3.png" moveTo="bar">Store</li>
</ul>

Por outro lado, a Listagem 2 mostra um exemplo que usa uma imagem agregada (i-icon-all.png), que é compartilhada pelos itens de lista. Ao especificar valores separados por vírgula (topo, esquerda, largura, altura) para a propriedade iconPos do widget ListItem, é possível reutilizar qualquer área retângula da imagem agregada. Como mostra a Figure 4, o resultado é o mesmo, mas produz somente uma solicitação HTTP para a imagem agregada.

<ul dojoType="dojox.mobile.RoundRectList" iconBase="i-icon-all.png">
  <li dojoType="dojox.mobile.ListItem" iconPos="0,0,29,29" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,29,29,29" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,58,29,29" moveTo="bar">Store</li>
</ul>

O CSS Sprite também pode ser usado para ícones do contêiner de ícones (Figura 5) ou para os botões da barra de guias (Figura 6).

Voltar para parte superior

Botão DOM

O Dojo Mobile fornece botões simples, ícones, marcas de seleção/setas e muito mais, para um item de lista, como mostra a Figura 7. Eles são feitos de elementos <div> com estilos CSS sem imagens e são chamados de botões DOM.

Idealmente, os botões DOM são menores em tamanho de byte, uma vez que são feitos de CSS sem imagens. A Tabela 1 compara os tamanhos de byte de botões e imagens DOM usando DomButtonGreenCircleArrow (quarto de cima para baixo, primeira coluna na Figura 7) como exemplo. Você pode ver que um botão DOM é muito menor do que uma imagem.

Os botões DOM têm a vantagem adicional de não precisar fazer solicitações HTTP adicionais, pois podem ser integrados a um arquivo CSS de tema com a ferramenta de desenvolvimento. Nessa situação, a área de cobertura de um botão DOM é muito menor. A tabela 2 mostra o tamanho de byte de um Botão DOM em um arquivo CSS agregado. Você pode ver que a adição do DomButtonGreenCircleArrow.css aumenta somente 155 bytes.

Estrutura do botão DOM

O Botão DOM é composto de elementos <div> aninhados com estilos CSS aplicados. Conforme mencionado, é possível alcançar uma variedade de representações gráficas usando os recursos ricos do CSS3, como planos de fundo da matiz, caixas de canto arredondadas e transformação de elementos DOM. É possível até mesmo desenhar um círculo ajustando o raio da borda de um elemento <div> quadrado. A Figura 8 mostra um exemplo da estrutura do Botão DOM.

Como usar o Botão DOM

O Botão DOM é simplesmente uma coleção de estilos CSS. Ele não exige um código JavaScript. É possível exibi-lo somente colocando elementos <div> aninhados e aplicando estilos CSS sobre eles. A Listagem 3 mostra o exemplo de código mínimo e a Figura 9 mostra o resultado.

<html>
  <head>
    <link href="themes/common/domButtons/DomButtonBlueCircleMinus.css" rel="stylesheet">
  </head>
  <body>
    <div class="mblDomButtonBlueCircleMinus">
      <div><div><div></div></div></div>
    </div>
  </body>
</html>

Na Lista 3, eu preparei 4 níveis de DIVs aninhados, incluindo o nó raiz do Botão DOM, que tem um nome de classe. No entanto, o número de DIVs que você precisa preparar varia com o tipo de Botão DOM. Para criar automaticamente o número necessário de DIVs, use a função dojox.mobile.createDomButton() do Dojo Mobile, conforme ilustrado na Lista 4.

<div id="btn1" class="mblDomButtonBlueCircleMinus"></div>
----
var node = dojo.byId("btn1");
dojox.mobile.createDomButton(node);

No entanto, aLista 3 e a Lista 4 normalmente não são usadas. Eu as incluí para fins ilustrativos para mostrar o mecanismo do Botão DOM. Em vez disso, alguns dos widgets do Dojo Mobile suportam os Botões DOM. É possível especificar os botões DOM no lugar de ícones de imagens ou botões.

• ListItem: propriedades icon, rightIcon, rightIcon2, arrowClass e checkClass (Figura 10)
• TabBarButton: propriedades icon1 e icon2 (Figura 11)
• ToolBarButton: propriedade icon (Figura 12)

Como criar um Botão DOM personalizado

É possível criar seus próprios Botões DOM personalizados. Veja algumas dicas.

• O nome de classe de um Botão DOM Button PRECISA começar com "mblDomButton". O Dojo Mobile verifica isso para determinar se é um Botão DOM ou não. (Por outro lado, você pode escolher um nome de arquivo CSS e onde colocá-lo.)
• Especifique a largura e a altura do Botão DOM de acordo com seu nó raiz. Ele terá o tamanho de todo o Botão DOM.
• Elementos <div> são aninhados, não irmãos. Portanto, talvez seja necessário aplicar estilos CSS a um nó relativo de seu nó pai.
• Para aplicar estilos CSS a um elemento <div> específico na hierarquia <div>, você pode usar um seletor filho (>).
• Se você quiser suportar navegadores desktop que não são CSS3, crie uma imagem equivalente e um arquivo compat css (*-compat.css).

NaLista 5 e na Lista 6 é mostrado um exemplo de um Botão DOM personalizado. A Figura 13 mostra o resultado.

/* === Red Check Button ==*/
.mblDomButtonMyCheck {
  position: relative;
  width: 29px;
  height: 29px;
}
.mblDomButtonMyCheck > div {
  position: absolute;
  left: 0px;
  top: 8px;
  width: 16px;
  height: 6px;
  font-size: 1px;
  -webkit-transform: scaleX(0.7) rotate(135deg);
  border-width: 3px 4px 0px 0px;
  border-style: solid;
  border-color: red;
}

/* === Red Check Button ==*/
.mblDomButtonMyCheck {
	background-image: url(compat/mblDomButtonMyCheck.png);
	background-repeat: no-repeat;
}
.mblDomButtonMyCheck > div {
	display: none;
}

Voltar para parte superior

Módulo de compatibilidade

O Dojo Mobile é otimizado para navegadores remotos com base em WebKit, mas também suporta navegadores desktop sem base em WebKit. No entanto, ninguém deseja sacrificar o desempenho em dispositivos móveis a fim de suportar navegadores desktop. O código de suporte entre navegadores não deve ser carregado quando um aplicativo executa em dispositivos móveis.

Compilação condicional

Uma abordagem é a compilação condicional, que permite excluir alguns blocos de código desnecessários para celular. O Dojo fornece duas maneiras de compilação condicional, pragmas e has().

Pragmas são diretivas especiais que podem ser usadas para excluir/incluir algumas partes do código, como mostra a Lista 7.

process: function(){
//>>excludeStart("marker1", kwArgs.noIE);
    if(dojo.isIE){
        ....
    }
//>>excludeEnd("marker1");
    ....
}

No exemplo acima, se você desenvolver o código com a opção de condição noIE=true especificada conforme mostra abaixo, o bloco de código cercado por excludeStart e excludeEnd é removido da compilação.

> build profile=myapp action=release noIE=true

Além disso, se você usar os pragmas includeStart/includeEnd o bloco de código ao redor será incluído somente quando houver correspondência da condição.

has() (ou dojo/has ou has.js) é um mecanismo de detecção/teste de recurso, apresentado no Dojo 1.7. Como mostra a Listagem 8, é possível usá-lo para testar se há um recurso específico no ambiente de tempo de execução atual.

process: function(){
    if(has("ie")){
        ....
    }
    ....
}

Se você configurar o array staticHasFeatures em seu perfil de compilação, como mostra abaixo, has("ie") será substituído por 0 e o otimizador do compilador detectará seu bloco de código como um código morto e o bloco será removido da compilação.

staticHasFeatures: {
  'ie': 0
}

Módulo de compatibilidade

A compilação condicional permite que você faça uma compilação otimizada para uma plataforma específica. A compilação, no entanto, tem um problema por não funcionar em outras plataformas. Para suportar outras plataformas, é preciso fazer outras compilações. Para resolver esse problema, o Dojo Mobile usou uma abordagem diferente: o módulo de compatibilidade (ou compat).

O compat inclui códigos que suportam navegadores que não têm base em WebKit. Se o compat for carregado, ele "sobrescreverá" alguns dos métodos de widget que precisam ser corrigidos. Sobrescrever o código mantém os nomes de classe de widget originais e, portanto, não afeta o código do aplicativo do usuário. Por outro lado, sobrescrever o código pela subclassificação dos widgets originais exigiria o uso de nomes de classe de widget recém-definidos. O compat também carrega arquivos *-compat.css, que são correções para os arquivos css originais. No modo compat, as técnicas tradicionais são usadas para renderizar as UIs de widget sem CSS3, como animações com base em JavaScript com dojo.fx, imagens de plano de fundo e muito mais. Para usar o compat para seu aplicativo, carregue "dojox.mobile.compat" usando dojo.require() ou a API require .

Observe que o compat é dividido em duas partes, compat.js e _compat.js. _compat.js inclui todo o código de implementação e o compat.js é um carregador do _compat.js. O compat.js carrega o _compat.js somente quando o navegador atual tem base em WebKit. O compat.js é um pedaço tão pequeno de código que não afeta o desempenho remoto, mesmo se estiver em uma compilação. Dessa forma, em navegadores com base em WebKit, o desempenho não é prejudicado, pois o _compat.js nunca será carregado. Em navegadores que não têm base em WebKit, _compat.js é carregado automaticamente e o Dojo Mobile funciona no modo compat. A tabela 3 mostra a comparação de tamanho de byte entre uma compilação remota sem compat e uma compilação remota com compat. Como você pode ver, a diferença é insignificantemente pequena: 45 bytes.

Dicas de avaliação do desempenho

Conforme descrito acima, em navegadores que não têm base em WebKit, o Dojo Mobile é executado no modo compat, e recursos adicionais, como imagens e/ou *-compat.css, são carregados. Portanto, se você quiser avaliar quais e quantos arquivos estão carregados em um dispositivo móvel, não use navegadores que não têm base em WebKit, como o Firefox ou o Internet Explorer. Depuradores no Google Chrome ou na versão desktop do Safari são ferramentas mais adequadas para monitorar o tráfego de rede para esse fim, uma vez que têm base em WebKit.

Voltar para parte superior

Dependências de módulo

O Dojo fornece muitas APIs úteis e elas são agrupadas como módulos, que são arquivos JavaScript relativamente pequenos. Há inúmeros módulos úteis disponíveis. No entanto, o uso excessivo desses módulos pode resultar em uma área de cobertura muito grande. O Dojo Mobile foi cuidadosamente projetado para ter o mínimo possível de dependências de módulo. Por exemplo, ele não usa, intencionalmente, alguns dos módulos úteis usados normalmente, como dojo.query ou dijit._Templated. Além disso, todos os widgets do Dojo Mobile herdam do dijit._WidgetBase em vez do dijit._Widget. dijit._WidgetBase é uma classe base do dijit._Widget e não inclui alguns dos códigos desnecessários para celular, como o código de suporte de teclado e, portanto, é mais leve do que o dijit._Widget. Além disso, não usa o dijit._base.manager, que era um módulo obrigatório até o Dojo 1.6; em vez disso, ele usa o dijit.registry, que é um subconjunto do dijit._base.manager.

O uso de módulos do dojo como o dojo.query ou o dijit._Templated de aplicativos de usuário com base no Dojo Mobile fica por sua escolha. No entanto, escolha cuidadosamente quais módulos dojo/dijit serão usados com base no desempenho. Por exemplo, se você usar o dojo.query somente uma vez em seu aplicativo, será possível substituí-lo por um código muito menor do que toda a implementação do dojo.query.

A Listagem 9 mostra os módulos dos quais a base do Dojo Mobile depende direta ou indiretamente. Você pode perceber que há menos dependências dos módulos dojo/dijit do que em casos de uso comuns de desktop. Ele depende somente de 11 módulos dojo/_base entre 25 e não tem dependência dos módulos dijit/_base. Se você usar módulos adicionais que não aparecem na Listagem 9, isso aumentará a área de cobertura de seu aplicativo. Quando você usar módulos como esse, escolha-os cuidadosamente.

dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic

Voltar para parte superior

Compilação

Para otimizar o desempenho do tempo de carregamento, a compilação é um processo importante. O Dojo tem um ótimo sistema de compilação, que compacta todo seu JavaScript e CSS em arquivos menores e cria uma versão eficiente de seu aplicativo para o release. A Figura 15 e a Figura 16 mostram a comparação de arquivos transferidos entre um aplicativo sem compilação (código de origem) e um aplicativo compilado. Você pode ver que há uma diferença enorme no número de solicitações e no tamanho total transferido. A próxima seção discute a compilação do Dojo Mobile.

Compilação customBase

A compilação do Dojo tem uma opção chamada customBase. A compilação padrão do Dojo inclui a maioria dos módulos base do Dojo em uma compilação, uma vez que os módulos base do Dojo estão sempre disponíveis sem haver a necessidade explícita deles. No entanto, se você fizer uma compilação com a opção customBase ativada, somente os módulos que estão na cadeia real de dependências serão incluídos na compilação. O Dojo Mobile foi projetado para ter o menos possível de dependências de módulo base do Dojo. A Listagem 10 mostra como especificar a opção customBase no perfil de sua compilação.

dependencies = {
  stripConsole: "normal",

  layers: [
    {
      name: "dojo.js",
      customBase: true,
      dependencies: [
        "dojox.mobile.parser",
        "dojox.mobile",
        "dojox.mobile.compat"
      ]
    },
  ....

Compilador de encerramento

Há dois compiladores (ou compressores) que podem ser usados na ferramenta de compilação do Dojo, o Shrinksafe e o Google Closure Compiler. Shrinksafe é o compilador padrão do Dojo. O Closure acompanha o Dojo desde a versão 1.7. A Tabela 4 mostra uma comparação do tamanho da compilação remota entre o Shrinksafe e o Closure. Como você pode ver, a taxa de compactação do Closure é melhor do que a do Shrinksafe, e o tamanho da compilação do Closure é 20% menor do que o da compilação do Shrinksafe, pelo menos neste exemplo.

O Dojo Mobile foi testado com base no que foi desenvolvido com o Closure. O Closure é recomendado para compilação remota, uma vez que sua saída é menor.

Como compilar no Dojo Mobile

O Dojo Mobile fornece dois arquivos de amostra de perfil: mobile-all.profile.js e mobile.profile.js, que estão na pasta dojo/util/buildscripts/profiles. Para compilar facilmente com esses perfis, use os arquivos simples em lote, disponíveis na pasta dojox/mobile/build.

Na linha de comando, é possível executar o arquivo em lote. Use build.bat para Windows ou build.sh para Linux.

  > build
  Usage: build separate|single [webkit]
    separate  Create mobile.js that includes only dojox.mobile
    single    Create a single dojo.js layer that includes dojox.mobile
    webkit    Enable webkitMobile=true option (Loses PC browser support)

separate usa o mobile.profile.js e cria um mobile.js que inclui SOMENTE os módulos base do dojox.mobile. Ele não inclui a base do dojo ou os módulos base dijit. _compat.js também é criado para suporte de navegado desktop. Além disso, dojo.js é criado, mas é uma compilação base de dojo comum, não uma compilação customBase.

Observe que "a base dojox.mobile" não inclui todos os widgets do Dojo Mobile. Por exemplo, ScrollableView, Carousel, SpinWheel, controles de formulário etc. não estão incluídos na base. Se você quiser tudo isso em sua compilação, basta adicioná-los no array de dependências em um arquivo de perfil. A Listagem 12 mostra todos os módulos aplicados na compilação da base dojox.mobile, mobile.js.

dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

single usa mobile-all.profile.js e cria uma única camada dojo.js que inclui a base dojox.mobile e todos os módulos dojo/dijit dependentes. _compat.js também é criado para suporte de navegadores desktop. Essa compilação permite a opção customBase. Portanto, somente os módulos mínimos da base dojo/dijit estão incluídos no dojo.js resultante. A Listagem 13 mostra todos os módulos aplicados na compilação única.

dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic
dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/parser
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

webkit permite que a opção de compilação webkitMobile=true, que retira pedaços de código desnecessários aos navegadores remotos com base em Webkit. Por exemplo, o código específico do Internet Explorer ou do Firefox é excluído da compilação. Isso reduz o tamanho total do código, mas o módulo de compilação não funcionará em navegadores desktop, mesmo com o módulo de compatibilidade (compat.js).

Observe também que essa opção reduziu uma quantidade considerável de código no Dojo 1.6, mas no Dojo 1.7, a detecção/teste de recursos está mudando para dojo.has e, dessa forma, a opção webkitMobile não tem mais tanto efeito sobre a redução do código.

Voltar para parte superior

Agregação de CSS

O Dojo Mobile tem muitos arquivos CSS na pasta themes. Há um arquivo CSS para cada widget e eles estão disponíveis para cada tema, Android, Blackberry, Custom e iPhone. Além disso, há arquivos CSS para Botões DOM ou animações de transição. Para ajudá-lo a incluir facilmente os arquivos CSS necessários em seu aplicativo, alguns arquivos CSS de ponto de entrada agregam vários arquivos CSS relacionados:

• Arquivo de temas completo (exemplo: themes/iphone/iphone.css)
  Inclui todos os arquivos CSS comuns e os arquivos CSS de temas
  
  
• Arquivo de tema base (exemplo: themes/iphone/base.css)
  Inclui arquivos CSS de tema para módulos base dojox.mobile
  
  
• Botões DOM (themes/common/domButtons.css)
  Inclui todos os Botões DOM
  
  
• Transições (themes/common/transitions.css)
  Inclui todas as animações de transição
  
  

O uso do arquivo de temas completo é o mais fácil, uma vez que inclui tudo. No entanto, isso significa que arquivos CSS não usados podem ser incluídos, e isso pode aumentar a área de cobertura de forma desnecessária. Nesse caso, uma abordagem é usar o arquivo de tema base e arquivos CSS individuais que não estão incluídos no arquivo de tema base.

Os arquivos CSS de ponto de entrada acima são um conjunto da diretiva @import. Se você realizar a compilação Dojo, as instruções de @import serão alinhadas e os arquivos CSS citados serão combinados no arquivo CSS de ponto de entrada. Portanto, o uso de um arquivo CSS de ponto de entrada produz somente uma solicitação HTTP, caso seja compilado. No entanto, se você listou os arquivos CSS em seu aplicativo usando <link> ou @import, como mostra a Listagem 14, as solicitações HTTP seriam feitas para cada uma deles.

<head>
  <link href="../themes/iphone/base.css" rel="stylesheet">
  <link href="../themes/iphone/TabBar.css" rel="stylesheet">
  <link href="../themes/common/SpinWheel.css" rel="stylesheet">
  <link href="../themes/common/domButtons/DomButtonBlueCircleArrow.css" rel="stylesheet">
  ....

Para reduzir o número de solicitações, crie seu próprio CSS de ponto de entrada com referências aos arquivos CSS mínimos necessários usando a diretiva @import, como mostra a Listagem 15. Se você realizar uma compilação do Dojo, será um arquivo CSS alinhado sem referências externas. É possível usá-lo a partir de seu aplicativo, como mostra a Listagem 16.

@import url("../themes/iphone/base.css");
@import url("../themes/iphone/TabBar.css");
@import url("../themes/common/SpinWheel.css");
@import url("../themes/common/domButtons/DomButtonBlueCircleArrow.css");

<link href="myStyles.css" rel="stylesheet">

Conforme descrito acima, é possível reduzir o número de solicitações HTTP para arquivos CSS criando seu próprio arquivo CSS de ponto de entrada e realizando a compilação Dojo.

Voltar para parte superior

Criação dinâmica e carregamento lento

Carregamento lento— uma técnica para carregar módulos somente quando eles são citados pela primeira vez— melhora o desempenho de inicialização do aplicativo. O próprio Dojo Mobile usa a técnica de carregamento lento internamente.

Criando uma visualização dinamicamente

Com a propriedade url do _ItemBase, é possível criar dinamicamente uma nova visualização, logo antes de fazer uma transição de visualização. A Listagem 17 mostra um exemplo de uso da propriedade url . O conteúdo de visualização pode ser um fragmento de HTML (Listagem 18) ou dados de JSON (Listagem 19).

<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" url="view1.html">
    External View #1 (sync)
  </li>
  <li dojoType="dojox.mobile.ListItem" url="view2.json" sync="false">
    External View #2 (async)
  </li>
</ul>

<div dojoType="dojox.mobile.View">
  <h1 dojoType="dojox.mobile.Heading" back="Home" moveTo="foo">view1.html</h1>
  <ul dojoType="dojox.mobile.EdgeToEdgeList">
    <li dojoType="dojox.mobile.ListItem">
      Jack Coleman
    </li>
    <li dojoType="dojox.mobile.ListItem">
      James Evans
    </li>
    <li dojoType="dojox.mobile.ListItem">
      Jason Griffin
    </li>
  </ul>
</div>

{
  "dojox.mobile.View": {
    "dojox.mobile.Heading": {
      "@back": "Home",
      "@moveTo": "foo",
      "@label": "view1.json"
    },
    "dojox.mobile.EdgeToEdgeList": {
      "dojox.mobile.ListItem": [{
        "@label": "Jack Coleman"
      }, {
        "@label": "James Evans"
      }, {
        "@label": "Jason Griffin"
      }]
    }
  }
}

Outra opção é buscar programaticamente o conteúdo de visualização e inseri-lo na visualização de destino. A Listagem 20 mostra um exemplo.

<li dojoType="dojox.mobile.ListItem" moveTo="#" onclick="myAction2(this)">
  Load and Move (async)
</li>
----
function myAction2(li){
   var view2 = dijit.byId("view2"); // destination view
   var listItem = dijit.byNode(li);
   var prog = dojox.mobile.ProgressIndicator.getInstance();
   dojo.body().appendChild(prog.domNode);
   prog.start();
   view2.destroyDescendants();

   var url = "http://..."; // or var url = listItem.url;
   dojo.xhrGet({
       url: url,
       handleAs: "text",
       load: function(response, ioArgs){
           var container = view2.containerNode;
           container.innerHTML = response;
           dojo.parser.parse(container);
           prog.stop();
           listItem.transitionTo("view2");
       }
   });
}

Consulte dojox/mobile/tests/test_list-actions.html para obter detalhes e mais exemplos.

Carregamento lento com IconContainer

IconContainer pode ter vários ícones, cada um deles representa um subaplicativo. Os subaplicativos podem ser formados por um ou mais widgets de Dojo. O carregamento de todo o código de subaplicativo na inicialização pode desacelerar o tempo de inicialização dos principais aplicativos. Para melhorar o desempenho do tempo de inicialização, especifique o parâmetro lazy="true" em IconItem. Em seguida, o analisador do Dojo ignora a instanciação de widgets dentro de IconItem e o IconContainer carrega esses módulos de conteúdo do ícone dinamicamente e os instancia somente quando um ícone é aberto pela primeira vez.

A Listagem 21 é um exemplo de carregamento lento do conteúdo do ícone. Observe que você não precisa exigir explicitamente os módulos de conteúdo do ícone (dijit.CalendarLite no exemplo a seguir). Observe também que, no Dojo 1.7, o carregamento lento é suportado somente no modo de carregador sincronizado, uma vez que o carregamento lento é realizado de forma síncrona usando dojo.require.

<ul dojoType="dojox.mobile.IconContainer">
  <li dojoType="dojox.mobile.IconItem" label="Calendar" lazy="true">
    <div id="cal" dojoType="dijit.CalendarLite"></div>
  </li>
  ....

Carregamento lento com TabBar

Se você precisar de painéis tabulares de carregamento lento, poderá usar o widget TabBar e a mesma técnica descrita em "Criando uma visualização dinamicamente." Para painéis tabulares, também seria necessário um pequeno truque para o primeiro painel tabular, pois não há transição de visualização na inicialização. Você precisa fazer programaticamente uma transição de visualização de uma visualização simulada em branco para o primeiro painel tabulado na inicialização a fim de carregar conteúdo externo no primeiro painel tabulado. A Listagem 22 e a Listagem 23 mostram os mesmos exemplos; o anterior é um exemplo de sincronização, o último é um exemplo assíncrono.

  <script src="../../../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
    dojo.require("dojox.mobile");
    dojo.require("dojox.mobile.parser");
    dojo.require("dojox.mobile.compat");
    dojo.require("dojox.mobile.TabBar");
    dojo.ready(function(){
      setTimeout(function(){
        dijit.byId("tab1").onClick();
      }, 0);
    });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton" url="view1.html">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton" url="view2.html">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton" url="view3.html">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>

  <script src="../../../dojo/dojo.js" djConfig="async: true, parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
  require([
    "dojo/_base/kernel",
    "dijit/registry",
    "dojox/mobile",
    "dojox/mobile/compat",
    "dojox/mobile/parser",
    "dojox/mobile/TabBar"
  ], function(dojo, registry){
    dojo.ready(function(){
      setTimeout(function(){
        registry.byId("tab1").onClick();
      }, 0);
    });
  });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton"
        url="view1.html" sync="false">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton"
        url="view2.html" sync="false">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton"
        url="view3.html" sync="false">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>

Exigindo módulos dinamicamente

A exigência de módulos dinamicamente no tempo de execução é uma boa ideia, uma vez que poderia aprimorar o desempenho do tempo de inicialização. Porém, há um possível problema do qual você precisa saber. Observe a Listagem 24; ela mostra o carregamento de um módulo Dojo programaticamente. Isso funciona, mas se você compilar a Listagem 24, a ferramenta de compilação selecionará automaticamente o módulo necessário e o aplicará em uma compilação e, dessa forma, dojo.require não realiza nada no tempo de execução, uma vez que o módulo já foi carregado no tempo de inicialização.

myHandler: function(e){
  dojo.require("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

Para evitar esse problema, escreva dojo["require"] em vez de dojo.require , como mostra a Listagem 25.

myHandler: function(e){
  dojo["require"]("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

Se seu aplicativo estiver carregando de forma assíncrona, a sintaxe será diferente, como mostra a Listagem 26. Porém, esse também não é um bom exemplo, uma vez que a ferramenta de compilação selecione o módulo especificado inesperadamente se você escrever o código dessa maneira.

myHandler: function(e){
  require(["dijit/CalendarLite"], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

É possível evitar o problema de compilação atribuindo o nome da classe a uma variável, como mostra a Listagem 27.

myHandler: function(e){
  var cls = "dijit/CalendarLite"; // assign to a variable so as not to be in the build
  require([cls], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

Voltar para parte superior

Modo assíncrono

No Dojo 1.7, um novo carregador AMD (Asynchronous Module Definition) é fornecido além do carregador tradicional do Dojo. Os widgets do Dojo Mobile são escritos na nova sintaxe do AMD. Para carregar quaisquer módulos Dojo, é possível usar o tradicional dojo.require (Listagem 28) ou a nova API exigida (Listagem 29).

<script src="../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
<script language="JavaScript" type="text/javascript">
  dojo.require("dojox.mobile");
  dojo.require("dojox.mobile.parser");
  dojo.require("dojox.mobile.compat");
</script>

<script src="../dojo/dojo.js" djConfig="async:true, parseOnLoad:true"></script>
<script language="JavaScript" type="text/javascript">
  require([
    "dojox/mobile",
    "dojox/mobile/parser",
    "dojox/mobile/compat"
  ]);
</script>

A Listagem 28 carrega os módulos de forma síncrona, enquanto a Listagem 29 o faz de forma assíncrona. Em circunstâncias nas quais muitos arquivos JavaScript são carregados, espera-se que o carregamento assíncrono execute melhor do que o carregamento síncrono. No entanto, se os arquivos JavaScript forem combinados em um único arquivo de compilação, talvez não haja muita diferença entre síncrono e assíncrono.

No entanto, há uma diferença maior da qual você precisa estar ciente. A Figura 18 mostra os arquivos transferidos quando test_iPhone-Animation.html, que carrega módulos na forma da Listagem 28, é aberto, e a Figure 19 mostra os arquivos quando test_iPhone-Animation-async.html, que carrega módulos na forma da Listagem 29, é aberto. Como mostra a Tabela 5, no modo de sincronização, 17 arquivos adicionais, 26KB no total, são carregados. Isso ocorre por que o modo de sincronização funciona no modo de compatibilidade com versões anteriores e, dessa forma, carrega alguns módulos necessários a fim de manter a compatibilidade com versões anteriores. Pelo fato de o test_iPhone-Animation-async.html funcionar sem esses módulos adicionais, é óbvio que eles não são usados e não precisam ser carregados. Portanto, mesmo se você escolher cuidadosamente quais módulos usar e otimizar sua compilação usando a opção customBase , o uso de dojo.require() pode prejudicar seus esforços. Você deve usar a API necessária em vez de dojo.require() para otimizar o desempenho de seu aplicativo.

Incidentalmente, mesmo se você usar a sintaxe AMD como a Listagem 29, se você não especificar async:true (o valor padrão é falso), seu aplicativo será executado no modo de compatibilidade e os módulos adicionais serão carregados.

Voltar para parte superior

dojox.mobile.parser

dojox.mobile.parser é um pequeno subconjunto de dojo.parser. Ele foi desenvolvido para reduzir puramente o tamanho total do código. Ele não tem recursos extras específicos para celular com relação ao dojo.parser, portanto não há motivos para usar o dojox.mobile.parser em vez do dojo.parser. Você pode escolher aquele que você gostar. Alguns dos recursos avançados do dojo.parser, como <script type="dojo/method"> e <script type="dojo/connect">, não existem no dojox.mobile.parser. Porém, o dojox.mobile.parser é menor.

Como mostra a Tabela 6, o tamanho do dojox.mobile.parser é aproximadamente 0,7 KB (minimizado & compactado com Gzip), enquanto o dojo.parser (além de seus módulos dependentes que não são exigidos pela base dojox.mobile) é de 6,5 KB. Se a capacidade do dojox.mobile.parser for suficiente para seu aplicativo, o uso dele poderá reduzir o tamanho total do código de seu aplicativo.

Voltar para parte superior

Resumo

Este artigo mostrou como compilar aplicativos da web remotos leves usando o Dojo Mobile e como aplicar suas técnicas de otimização de desempenho aos seus aplicativos.

Recursos

Aprender

• Saiba mais sobre os recursos remotos do Dojo.
  
  
• Leia a documentação mais recente do dojox.mobile .
  
  
• Experimente os testes de compilação noturnas mais recentes do Dojo Mobile 1.7 .
  
  
• Na Zona de desenvolvimento da web no developerWorks, encontre vários artigos de instruções e tutoriais, além de downloads, fóruns de discussão e diversos outros recursos para desenvolvedores da web.
  
  
• Verifique a existência de atualizações remotas no blog Mobile development do developerWorks.
  
  
• Você encontrará muitos outros artigos sobre tópicos remotos, incluindo artigos sobre o Dojo Mobile no developerWorks.
  
  
• Fique por dentro doseventos técnicos e webcasts do developerWorks com foco em uma variedade de produtos IBM e tópicos do segmento de mercado de TI.
  
  
• Participe de um briefing ao vivo e gratuito do developerWorks para se atualizar rapidamente sobre produtos e ferramentas da IBM, bem como tendências do segmento de mercado de TI.
  
  
• Acompanhe as demos on demand do developerWorks , que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.
  
  
• Siga o developerWorks no Twitter.
  
  

Obter produtos e tecnologias

• Faça o download do Dojo 1.7 mais recente na página de download do Dojo Toolkit.
  
  
• Faça o download e experimente o IBM Mobile Technology Preview, um conjunto de amostras de código e serviços para ajudá-lo a começar a desenvolver aplicativos remotos que ampliam e se integram à sua empresa. A visualização inclui um serviço de notificação RESTful; PhoneGap, uma estrutura de software livre para o desenvolvimento de aplicativos híbridos remotos; um tempo de execução WebSphere Application Server leve; e amostras de código para que você possa ver como tudo funciona.
  
  
• O IBM WebSphere Application Server Feature Pack para Web 2.0 e Dispositivo móvel inclui o IBM Dojo 1.7 Toolkit, novos blocos de construção rich Internet application (RIA) e remoto e um componente de diagrama com base em Dojo. Com as ferramentas acompanhantes do Rational, o Feature Pack o ajuda e adaptar e implantar aplicativos WebSphere desenvolvidos originalmente para navegadores desktop em dispositivos móveis.
  
  
• Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.
  
  

Discutir

• Participe da comunidade do developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  

Sobre o autor

Yoshiroh Kamiyama é um engenheiro de software conselheiro na Yamato Software Lab (YSL), IBM Japão. Ele trabalha no WebSphere Feature Pack para Web 2.0 e Dispositivo móvel. Anteriormente, ele trabalhou em vários projetos de desenvolvimento, incluindo o Mobile Mashup, o Lotus iNotes e o Rational Portfolio Manager, muitos deles com o Dojo Toolkit. Ele é um colaborador original do site dojox.mobile e um committer do Dojo Toolkit.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Apresentando o Dojo Mobile
• Widgets de UI sem imagens
• CSS Sprite
• Botão DOM
• Módulo de compatibilidade
• Dependências de módulo
• Compilação
• Agregação de CSS
• Criação dinâmica e carregamento lento
• Modo assíncrono
• dojox.mobile.parser
• Resumo
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais