Yahoo! Blog User Interface (YUIBlog)

Limites de navegador móvel de cache: Android, iOS e webOS

28 junho, 2010 às 8:45 pm por Ryan Grove | Em Desenvolvimento e Desempenho | 19 Comentários

Atualização (12 de julho de 2010): Embora os resultados descritos neste artigo são precisos para páginas HTML, novos testes revelaram limites de cache muito diferentes de recursos CSS e JS. Os resultados atualizados são descritos em Limites de navegador móvel Cache, revisitado .

No início de 2008, Wayne Shea e Tenni Theurer escreveu um post no blog YUI em Cacheabilidade iPhone em que compartilhou os resultados da investigação em várias características e limitações de cache do Mobile Safari no iPhone OS 1.x. Entre outras coisas, eles descobriram que os componentes individuais maiores do que 25KB não foram guardados, e que havia um tamanho máximo de cache total de entre 475Kb e 500KB.

Muita coisa mudou desde então. Vimos dois novos grandes lançamentos e muitas versões menores do iPhone OS (iOS agora), e vários outros dispositivos móveis com browsers altamente capacitados apareceram para desafiar o iPhone. Stoyan Stefanov encontrado, no final de 2009, que limita o iPhone tinha mudado de cache (infelizmente, para pior). Mas onde estão as coisas agora? E o que sobre esses navegadores não-Ios?

Fundo

Os navegadores têm dois tipos de caches que estamos preocupados com para efeitos destes testes:

• O cache do componente, ou cache de objetos, armazena arquivos individuais. HTML, CSS, JavaScript, imagens e todos vão para o cache componente. Sempre que precisa de um desses componentes, o primeiro navegador verifica o cache antes de fazer uma solicitação de rede.
• O cache de página, também conhecida como cache para trás / frente, armazena uma página inteira e todos os seus componentes, bem como seu estado atual. Quando você usa o botão para trás ou para frente, o navegador irá carregar a página do cache da página, se possível.

O cache do aplicativo HTML5 é outro tipo de cache que é amplamente suportado pelos navegadores móveis. Fabricantes de navegadores já fazem um bom trabalho de documentar os limites de cache do aplicativo, então eu não incluí-lo em meus testes. Mais informações sobre o cache do aplicativo mais tarde.

Dispositivos testados

Eu testei os seguintes móveis navegador / plataforma combinações:

• Android 2.1 (Nexus One)
• Mobile Safari no iOS 3.1.3 (primeira geração do iPhone)
• Mobile Safari no iOS 3.2 (IPAD)
• Mobile Safari no iOS 4.0 (iPhone 3G)
• Mobile Safari no iOS 4.0 (iPhone 4)
• webOS 1.4.1 (Palm Pre Plus)

Nota: Com exceção do Mobile Safari no iOS 4.0, eu testei apenas um dispositivo em cada categoria. Se existem variações entre os dispositivos individuais ou diferenças baseadas no software instalado além do sistema operacional, meus testes não detectar essas variações. Estes dispositivos específicos foram testados porque eles são os únicos que tive acesso, não porque eu os considero como mais importante do que outros dispositivos.

Metodologia

Testes de Cache é tedioso, mas relativamente simples.

Eu escrevi uma pequena app Sinatra ( bifurcar-lo no GitHub! ) que gera uma resposta consiste em um número solicitado de bytes pseudo-alfanuméricos e espaços em branco. As respostas podem ser servidos compactado ou descompactado. Os seguintes far-futuros cabeçalhos de resposta de expiração são enviados para assegurar que todas as respostas são considerados cacheável:

 Cache-Control: max-age = 315360000
 Expira em: Fri, 01 maio de 2020 03:47:24 GMT

Sobre a minha rede local, então eu realizada manualmente as seguintes etapas em cada dispositivo para testar o cache componente:

1. Coloque o cache de página de índice teste.
2. Toque em um link para um componente de um determinado tamanho, variando de 5 KB para 20 MB, e esperar por ele para concluir o carregamento.
3. Toque no botão de volta.
4. Toque no mesmo link novamente. Observe se os caracteres aleatórios são os mesmos, e se a consola do servidor imprime uma entrada de log para um pedido, para determinar se o componente foi cache no passo 2.
5. Repita e ajustar os tamanhos de componentes, necessários para determinar o tamanho do componente máxima que será armazenada em cache.

Para testar o cache de página, eu realizado essencialmente os mesmos passos só que em vez de tocar no link novamente no passo 4, eu bati botão de avanço do navegador, fazendo com que usam o cache de página em vez de cache componente.

Suporte para ETag e Last-Modified foi determinada por ajustes, o servidor para enviar o apropriado ETag ou Last-Modified cabeçalhos de resposta (em testes separados) e omitir os cabeçalhos far-futuros de vencimento. Eu, então, inspecionou os cabeçalhos de solicitação recebida pelo servidor para verificar se o browser enviou o esperado If-None-Match ou If-Modified-Since cabeçalhos no passo 4.

Resultados

Eu testei com gzip tanto ativado e desativado, mas eu achei que o gzip não teve efeito sobre cacheability em qualquer dispositivo. O tamanho do componente descompactado é o que importa em todos os casos, independentemente de haver ou não esse componente é servido compactado. Como tal, todos os tamanhos de componentes aqui mencionados são tamanhos descompactados.

A tabela abaixo ilustra as minhas conclusões gerais.

Tabela: características de cache do navegador móvel

Browser / OS Device /	Limite de um componente	Componente Limite total	Página Limite de tamanho do cache	Suporta Last-Modified	Suporta ETag	Sobrevive Power Cycle
Android 2.1 (Nexus One)	~ 2MB (~ 2.048.000 b)	~ 2MB (~ 2.048.000 b)	∞ 2	Sim	Sim	Sim
Mobile Safari, iOS 3.1.3 (primeira geração do iPhone)	0b 1	0b 1	∞ 2	Não	Não	Não
Mobile Safari, iOS 3.2 (IPAD)	25.6KB (26.214 b)	~ 281.6KB (~ 288.354 b)	25.6KB (26.214 b)	Sim	Sim	Não
Mobile Safari, iOS 4.0 (iPhone 3G)	51.199KB (52.428 b)	~ 1.05MB (~ 1.100.988 b)	∞ 2	Sim	Sim	Não
Mobile Safari, iOS 4.0 (iPhone 4)	102.399KB (104.857 b)	~ 1.9MB (~ 1.992.283 b)	∞ 2	Sim	Sim	Não
webOS 1.4.1 (Palm Pre Plus) 3	~ 1MB (~ 1.048.576)	?	~ 1MB (~ 1.048.576)	Não	Não	Sim

Andróide

O browser do Android apresentaram o melhor comportamento de cache de todos os dispositivos testados. Embora pareça impor nenhuma limitação do tamanho dos componentes individuais, o tamanho total do cache parece estar limitado a aproximadamente 2MB, o que significa que os componentes individuais são efectivamente limitada a 2MB tão bem.

O cache de página apareceu para impor nenhum limite no tamanho das páginas individuais, felizmente cache cada byte eu joguei com ele até a memória RAM disponível estava exausto e o navegador falhou.

Fiquei agradavelmente surpreso ao descobrir que o cache do Android componente sobreviveu reinicia ambos os navegadores e os ciclos de energia, uma façanha nenhum dos dispositivos iOS foi capaz de igualar.

Ressalva possível: Uma revisão de fonte do Android WebKit árvore me leva a crer que os limites de seu cache pode adaptar com base na quantidade de memória RAM e / ou memória flash disponível no dispositivo especial em que ele está correndo. Se for verdade, esses números só podem ser aplicáveis ​​ao Nexus One. Na verdade, se o tamanho do cache adapta com base na memória não utilizada ao invés de memória total, estes números só podem ser aplicáveis ​​ao meu Nexus One.

Eu poderia estar enganado, mas as diferenças nos resultados dos testes iOS 4.0 no iPhone 3G e iPhone 4 apoiar esta teoria. (Android e Mobile Safari são dois navegadores baseado no WebKit, então eles podem ter esse comportamento em comum.) Se você estiver familiarizado com a fonte WebKit e pode lançar mais luz sobre isso, por favor entrar em contato comigo.

iOS

Os resultados variaram amplamente entre os três mais recentes versões do iOS. Surpreendentemente, o Mobile Safari no iOS 3.1.3 não cache componentes de qualquer tamanho, apesar de ter um tamanho de cache aparentemente ilimitados página. Isto é preocupante pois significa iOS 3.1.3 os usuários são provavelmente recebendo uma experiência de navegação de qualidade inferior, especialmente se eles não estão usando wifi. O tamanho do cache unlimited página faz pouco bom aqui, uma vez que só entra em jogo para voltar / avançar navegações. Este comportamento é uma mudança significativa do que os outros observada nas versões anteriores do iOS e eu não posso imaginar qualquer boa razão para isso, então eu suspeito que isso pode ser um bug.

Mobile Safari no iOS 3.2 (que só está disponível no iPad) não apresentam esse bug. Seu limite componente 25.6KB e ~ limite de cache 281.6KB total são melhor que nada, mas eles ainda parecem insignificantes em comparação com os outros dispositivos testados. Exclusivamente entre os dispositivos IOS, o iPad parece limitar o tamanho das páginas no cache de página para 25.6KB, o mesmo que o seu limite de tamanho do componente.

Mobile Safari no iOS 4.0 apresentaram limites diferentes sobre o iPhone 3GS e no iPhone 4, o que implica que os limites adaptar baseado na memória RAM disponível (o iPhone 3GS tem 256MB, enquanto o iPhone 4 tem 512 MB, ambos os dispositivos testados tinham 32GB de memória flash) . No iPhone 3GS, iOS 4.0 tem um limite de tamanho 51.199KB componente e um tamanho de cache ~ 1.05MB total de componente.

No iPhone 4, o limite de tamanho do componente era quase exatamente duas vezes o limite no iPhone 3GS, em 102.399KB. O tamanho total do cache componente foi de aproximadamente 1.9MB. Talvez porque iOS 3.2 e iOS 4.0 foram desenvolvidos separadamente, mas ramificou de um ancestral comum, o iOS 4.0 tamanho do cache de página parece ser limitada apenas pela memória RAM disponível em ambos os dispositivos testados, assim como iOS 3.1.3.

Nenhum dos dispositivos iOS preservado o conteúdo do cache do navegador entre as reinicializações forçadas ou ciclos de alimentação dos dispositivos, embora tenham preservar o cache quando simplesmente alternar entre aplicativos sem realmente matar o navegador.

webOS

Meus resultados de teste no webOS eram tão inconsistente que tenho pouca confiança neles. Eu incluí o que poucos dados que consegui reunir puramente por uma questão de integridade. Por favor, levá-la com um grão de sal bolada.

O mais perto que eu era capaz de determinar, webOS pode ter um limite de tamanho de componente individual de cerca de 1MB, com um limite de tamanho de página correspondente no cache de página. Eu era incapaz de persuadir If-None-Match ou If-Modified-Since cabeçalhos de solicitação do webOS, o que implica que ele não suporta ETag e Last-Modified .

Em alguns testes, verificou-se que o tamanho do componente webOS máxima foi maior do que 1MB, mas isso era inconsistente. Tanto quanto eu posso dizer, webOS parece ter um bug desagradável onde, depois de um certo ponto, possivelmente, quando o tamanho do cache total máximo é atingido-o cache apenas pára completamente de funcionar completamente até que o telefone é o poder-ciclo. Em alguns casos, até mesmo o ciclo de alimentação não resolver o quebra cache, então eu finalmente desisti de tentar estabelecer a causa exata do problema e os limites exactos do cache webOS.

Recomendações

Com base nesses resultados, ofereço as seguintes recomendações para alguém desenvolver aplicações web para os dispositivos testados:

• Use far-futuros cabeçalhos de expiração de cache. Isto irá evitar que o navegador de ter que enviar uma solicitação GET condicional e irá melhorar cacheability no webOS, que não suporta ETag ou Last-Modified .
• Pelo menos até iOS 4.0 chega no IPAD, tente limitar o tamanho dos componentes individuais para 25.6KB ou menos, não comprimido. E exortar os seus usuários do iPhone para atualizar para o iOS 4.0 o mais rápido possível.
• Se o seu site deve suportar iOS 3.1.3 os usuários (que é provável), se requer componentes maiores do que 25.6KB, ou se o tamanho total de todos os seus componentes é maior do que 281.6KB, considere usar o cache do aplicativo HTML5, localStorage , ou armazenamento de dados para armazenar os seus componentes. Alex recente Kessinger do YUI Blog post, uma introdução ao uso YUI 3 em Aplicações off-line , pode ser de interesse para YUI 3 desenvolvedores considerando esta abordagem.
• Faça seus próprios testes. Não presuma que estes resultados se aplicam a qualquer versão futura de qualquer um dos navegadores testados ou dispositivos. Use estes resultados como um ponto de partida, mas verificá-los você mesmo antes de tomar decisões importantes baseadas em suposições sobre as limitações de cache móveis. As mudanças de navegador móvel do mundo em um ritmo relâmpago, por isso esta investigação terá uma vida útil muito curta.

Eu fiz o meu código de teste disponível no GitHub e eu encorajo você a usá-la, garfo, e compartilhar o que aprendeu.

Chamada de Documentação

Os fabricantes de browsers, por favor considere documentar e publicar os limites do seu navegador de cache. No mundo desktop, onde esses limites são geralmente tão alto quanto a ser uma questão não, a documentação não foi necessário. No mundo móvel, os limites de cache do navegador são informações vitais que os desenvolvedores web devem ter para criar sites de elevada performance com recursos interessantes.

Os limites de novos recursos, como localStorage e cache do aplicativo normalmente são bem documentados. Por favor, estender esse nível de documentação para o cache componente também.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

In the Wild para 25 de junho de 2010

25 junho, 2010 às 10:10 am por Eric Miraglia | Em In the Wild | Comments Off

Como sempre, deixe-nos saber nos comentários ou yuilibrary @ se perdemos algo importante.

• YUI UI liga 3-baseado anunciou formalmente na Conferência Liferay : A partir do comunicado de imprensa : "Como parte deste esforço, Liferay também anunciou a disponibilidade imediata do Liferay UI Liga . Desenvolvido em colaboração com a YUI do Yahoo projeto, liga UI fornece um conjunto de componentes de interface do usuário ricos para rapidamente criar user-friendly portlets, widgets e aplicações web. UI liga lida com as complexidades da CSS, HTML e Javascript, liberando os desenvolvedores se concentrem em requisitos de negócio e funcionalidades. UI Liga também ajuda a resolver alguns problemas comuns de compatibilidade cross-browser que normalmente consomem recursos do projeto. A nova biblioteca não requer um portal e pode ser utilizado para desenvolver componentes para qualquer aplicação web. Liferay Portal irá padronizar o seu quadro de front-end em torno UI Alloy, ampliando a simplicidade ea capacidade de modernas soluções corporativas baseadas portal. UI Liga representa uma nova capacidade para desenvolvedores web para simplificar o desenvolvimento de interfaces de usuário ricas ", disse Brian Chan, Liferay criador do portal e Chief Software Architect. "Estamos felizes por ter trabalhado isso com a equipe Yahoo e sentir que vai ser um grande trunfo para ajudar os desenvolvedores com suas soluções." "Todos os componentes de interface do usuário Liga estão agora disponíveis gratuitamente para a comunidade no YUI YUI 3 Galeria .
• CarPrices.com AutoFusion lança Usando YUI 3.1.1 : YUI 3 contribuinte Galeria Josh Lizarraga vem trabalhando com Autofusion Inc. sobre o novo project CarPrices.com , construído com uma série de YUI 3.1.1 utilitários e widgets. Josh terão mais sobre este projeto em um post YUIBlog futuro.
  
• Baixe Erez Esquadrão da Zukerman Aconselha JS Devs para ver Crockford em YUI Theater : Grava Erez: " Douglas Crockford é um gênio. Sério - o cara é brilhante. Ele está atualmente servindo como Yahoo! 's arquiteto JavaScript chefe, ele inventou JSON (um formato de intercâmbio amplamente utilizados dados), ele é parte do comitê ECMAScript (os caras estabelecendo o padrão JavaScript) e tem uma compreensão muito ampla da história geral de programação línguas e informática. Recentemente, Crockford deu cinco palestras sobre JavaScript como parte do Yahoo! 's Theater YUI . Estão todos disponíveis gratuitamente, e eles são mais de cinco horas de duração (mais parecido com seis a sete horas no total, eu acho). O que é tão legal quanto essas conversas é que Crockford realmente lhe dá uma visão panorâmica do assunto, a primeira hora é só uma história, e é realmente fascinante. É toda sobre o lugar, começando com o tear Jackquad , através por isso que temos tanto Excluir e uma tecla de retrocesso em nossos teclados, todo o caminho para linguagens de programação modernas e JavaScript. "Para mais de recursos favoritos de Erez de JavaScript, confira o seu posto , ou dirigir-se ao Crockford na página JavaScript para vídeos mais recentes Douglas (com muito mais encher a segunda coluna da YUI Theater ).
  
• Parabéns para Matt Snider & Friends em YUI 2-based Mint.com, vencedores de um Webby 2010 : Parabéns para Matt Snider . e os outros engenheiros frontend em circulação no Mint.com para o prêmio Webby bem merecida 2010 na categoria Serviços Financeiros Mint foi YUI 2-baseado desde o início , e Matt continua a ser um grande contribuinte para o projeto YUI . Você pode ver discurso de Matt aceitação cinco palavras mais no YouTube .
  
• Módulo Dion Ajaxian de Almaer Comentários Caridy Patiño Mayea Galeria de Preload para YUI 3 : Dion tem um bom post em cima Ajaxian revisão módulo Preload Caridy Patiño Mayea para prefetching e de caching ativos , uma entrada Galeria YUI 3, que ele escreveu sobre recentemente em YUIBlog .
  
• Usando Grades YUI com Movable Type (por @ foxxtrot) : YUI contribuinte Jeff Craig escreveu sobre sua experiência de conversão de um blog de ​​Movable Type para YUI Grids 2: "Então, como alguém que já tenha lido o meu blog antes, você verá que no fim de semana Eu atualizei meu modelo de blog para usar YUI Grids e YUI3 para o JavaScript. Ao mudar para longe dos modelos MT (ou, os modelos que eram padrão quando eu instalei as primeiras versões do MTOS 4), eu era capaz de reduzir o pageweight HTML pela metade quase nada. Os modelos antigos eram realmente div-pesado, e tinha uma tonelada de marcação extra. Principalmente, a decisão foi motivada por um desejo de refazer a sensação visual do meu blog, e eu senti que eu posso também reescrever em Grids YUI enquanto eu faço isso. "
• Nate Schutta Compara YUI e Dojo para DevelperWorks IBM : Nate Schutta escrito para o IBM developerWorks compara YUI 2.xe Dojo em um novo post. Enquanto estamos focados mais no 3.x YUI codeline nos dias de hoje, artigo de Nate tem algumas orientações úteis para aqueles que pensam sobre bibliotecas JavaScript e tomar uma decisão para o seu negócio ou projeto. Primeiro - por YUI ou Dojo?

  Com tantas excelentes opções à sua disposição, por que você considera YUI ou Dojo? Em uma palavra: perfeição. Ao contrário de outras soluções que envolvem bibliotecas adicionais ou plug-ins, Dojo e YUI tem tudo (e mais) que o engenheiro de hoje front-end poderia querer. Embora isso seja uma bênção e uma maldição, se você estiver no mercado para um one-stop shop para as suas necessidades de Ajax, estes são dois candidatos fortes. Além de uma riqueza de ajudantes JavaScript e utilitários, ambos oferecem top-notch widgets e controles-muito além da paleta limitada do navegador padrão.

  Nate conselhos sobre critérios gerais de seleção da biblioteca é útil:

  • O que você quer com isso? Você está procurando um substituto completo de quase todos os elementos da interface do usuário na página, ou você está apenas procurando algo para tomar um pouco de dor de programação JavaScript?
  • Quão fácil é o código para ler? Apesar das melhorias maciças em documentação ao longo dos últimos anos, as probabilidades são que você terá que mergulhar no código em algum ponto. Antes de cometer a uma biblioteca, passar algum tempo até os joelhos na fonte. É fácil de entender, ou faz ainda o autor original têm problemas com isso?
  • Como é bom a documentação? Código limpo e legível pode compensar menos-que-estelares documentos, mas nada ajuda você a começar bem como tutoriais e exemplos. Pique em todo o wiki ou o site, e ver o que eles têm para oferecer. São os exemplos são claros e fáceis de seguir? Será que uma rápida pesquisa no Google trazê-lo para a parte adequada do seu material?
  • Qual é a comunidade como a que rodeia a biblioteca? Confira as listas de discussão. Existe uma grande quantidade de tráfego? São pessoas novas tratados com respeito ou desprezo? Tem o código foi atualizado recentemente, ou foi o último lançamento de vários anos atrás?
  • Você pode obter ajuda? Embora isto está relacionado com os bits anteriores sobre a comunidade, é sempre valioso para olhar em torno da comunidade de desenvolvimento e ver quem está usando o quê. Confira as placas do trabalho para ter uma noção de quais bibliotecas estão aparecendo com freqüência em currículos.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

YUI: Horário de funcionamento Sexta-feira 25 junho

23 de junho de 2010 às 15:07 por Luke Smith | Em Desenvolvimento | Comments Off

A última parcela do YUI: Horário de funcionamento será esta sexta-feira, 25 de junho.

Na semana passada, Eduardo Lundgren nos apresentou a alguns dos grandes AlloyUI módulos recentemente adicionadas à galeria. O debate incidiu sobre instanciação, decisões de configuração, desenvolvimento, e um pouco da história de sua TreeView módulo. Mas isso foi só o começo. Também exploramos a sua IO , Nó , e validação de formulário módulos e passou algum tempo em alguns dos estilos visuais disponíveis. Eduardo ainda nos deu uma prévia do novo Liferay, Inc. portal, alimentado por todo esse trabalho duro. Trabalho entalhe realmente superior.

Tudo o que disse, é difícil dizer se o show-e-dizer ou a conversa foi o headliner real. Código grande conteúdo relacionado à parte, havia um monte de bons comentários e discussão sobre a colaboração da comunidade, a natureza da Galeria, e como podemos fazê-lo e YUI melhor. Então, um grande agradecimento a todos na chamada!

Esta semana, estamos indo para borrifar um pouco, tanto no mundo desenvolvedor a matéria-prima, bem como o mundo designer. Caridy Patiño está de volta com a gente para falar sobre sua Binder evento módulo que foi apresentado aqui apenas esta manhã . Nós vamos fazer uma revisão de código e discutir a etapa de configuração que tem que ser feito antes YUI é ainda carregado. É isso mesmo: pura, não adulterada DOM scripting. Você pode querer usar um capacete.

Então vamos passar para o processo igualmente matizada pele projeto com Jeff Conniff, o yahoo responsável pela a variedade atual de Slider look-and-sente. Ele vai andar nós através do seu processo de construção dos ativos visuais e mostrar como você pode ter os mesmos PSDs e facilmente criar cores temáticos ativos que se encaixam em sua paleta site. Aqui estão os arquivos do Photoshop se você quiser jogar junto. Eu também vou falar sobre algumas das decisões tomadas na construção da estrutura CSS e DOM de Slider.

Estamos de volta para o dia usual e tempo esta semana: Sexta-feira 10:00-12:00 PDT. Há um código novo participante para a chamada de conferência, mas por outro lado, os detalhes de conexão são os mesmos, como de costume.

1. Disque para 1-888-371-8922 (fora dos Estados Unidos participantes, enviar e-mail me para um número local)
2. Digite o código de participante 47188953 #
3. Junte-se a sessão de compartilhamento de tela (este irá pedir-lhe para instalar o plugin Adobe Connect, se esta é sua primeira vez de usá-lo)

Também criei um tópico no fórum para este Horário de funcionamento para que possamos começar a discussão cedo!

Além disso, como sempre, você pode manter-se atualizado com o cronograma programado e por tópicos seguindo @ yuilibrary no Twitter ou assinando o Calendário de Eventos YUI .

Espero ver você lá!

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

No 3 YUI Gallery: Módulo Caridy Patiño Mayea da Binder evento oferece suporte para o evento ligação antecipada e orientada a eventos Carregando Módulo

23 de junho de 2010 às 9:25 pm por Caridy Patino | Em Desenvolvimento , YUI 3 Galeria | 1 Comentário

Este artigo apresenta o meu módulo Binder evento , foi lançado recentemente no 3 º YUI Galeria.

YUI 3 está ficando boa tração na comunidade de desenvolvedores, com a adoção significativa da mais recente versão 3.1.1 e uma enorme infusão de novos projectos inovadores no 3 Galeria YUI . Muitos desenvolvedores estão recebendo as suas cabeças em torno da natureza on-demand de YUI 3 e começar a aproveitar esses recursos em seus projetos. Esta abordagem tem grandes vantagens, mas também pode apresentar alguns desafios.

Um desses desafios é captar as interações do usuário cedo. Mesmo quando o navegador é iniciado processar a página, nós queremos que o usuário seja capaz de começar a interagir com os elementos da página. Em muitos casos, essas interações podem acontecer antes que o processo de inicialização JavaScript (incluindo o anexo de ouvintes de evento) foi concluída.

Em muitos casos você pode otimizar seu código de inicialização, definindo apenas ouvintes do seu evento e, em seguida, adicionar a lógica para carregar as peças que você precisa para cada interação do usuário. Recentemente, os engenheiros do Facebook falou sobre uma abordagem semelhante para melhorar o processo de carregamento - veja a entrevista do Rey Bango em JSConf. Aqui está um exemplo de como essa técnica pode funcionar em YUI 3:

  <Script src = "& http://yui.yahooapis.com/combo?3.1.1/build/yui/yui-min.js
 
	 3.1.1/build/oop/oop-min.js e 3.1.1/build/event-custom/event-custom-base-min.js e
	 3.1.1/build/event/event-base-min.js e 3.1.1/build/dom/dom-base-min.js e
	 3.1.1/build/dom/selector-native-min.js e 3.1.1/build/dom/selector-css2-min.js e
	 3.1.1/build/node/node-base-min.js "> </ script>
 
 YUI (). Usar ("evento-base ', function (Y) {
     / / Espera até que o usuário se concentra em um elemento de entrada para iniciar o carregamento ativos
     Y.on ("click", function (e) {
 
       Y.use ('anim', 'io', function () {
           / / Carregar um conteúdo remoto e exibi-lo usando uma animação aqui
       });
 
       e.halt () / / parar a propagação
     }, "Demo #");
 }); 

Isto introduz alguma complexidade no seu código, porque não só os ouvintes têm de lidar com a interação do usuário, mas também com alguma lógica de carregamento. Outra desvantagem desta abordagem é que você ainda tem que carregar um código JavaScript no topo (neste caso, YUI semente, o Utilitário de evento, e algumas dependências), a fim de definir pelo menos o ouvinte ea lógica de carregamento para pegar as ações iniciais. Então, vamos considerar isso como dois distintos casos de uso:

• Capturar as interações do usuário primeiros
• Facilitar a natureza on-demand de algumas interações com o usuário

Para atender a essas necessidades que eu criei um novo módulo para YUI 3 . Meu foco principal tem sido a de criar um componente que funciona sem afetar a lógica do aplicativo. Este novo módulo é chamado de " galeria de evento para encadernação "e está agora disponível através do carregador de YUI.

Capturar as interações do usuário primeiros

O principal objetivo desse recurso é para garantir que as interações do usuário estão na fila até que os ouvintes de eventos são inicializados.

Vamos ver um exemplo aglutinante evento :

  YUI ({
     / / Galeria última compilação deste módulo
     Galeria: "galeria-2010.06.07-17-52 '
 }). Usar ('galeria evento pasta', 'evento', function (Y) {
 
     Y.on ('click', function (e) {
 
         / / Faz as suas coisas aqui
         e.halt () / / parar a propagação do evento se você quiser ...
 
     }, 'Demo #');
 
     / / Limpar as interações do usuário primeiros
     Y.EventBinder.flush ('click');
 
 }); 

Neste exemplo, YUI carregador tentará carregar as gallery-event-binder e event módulos on-demand, e uma vez que ambos estão prontos junto com suas dependências, o código dentro da função de callback (terceiro argumento) será executado. Durante a execução, um ouvinte é definido para um elemento com id=demo . O truque aqui é que uma vez Y.EventBinder.flush('click') é chamado, o sistema irá liberar alguns dos eventos de clique que poderia ter acontecido antes deste código de inicialização é executado.

A configuração

Esta técnica requer alguma configuração extra, especificamente a definição de YUI_config como uma variável global para ajustar a execução YUI. Não se preocupe, é muito simples. Vamos ver um exemplo em detalhes:

 
 YUI_config = {
     / / Configuração padrão YUI_config
     combinar: true,
     filtro: 'min',
 
     / Configuração ligante / evento começa aqui
     eventbinder: {
         / Manipulador / Evento para armazenar eventos que você deseja para reexpedição.
         fn: function (e) {
             var aglutinante = YUI_config.eventbinder,
                 filter = / yui3-evento-ligante /,
                 recipiente = (e.target | | e.srcElement),
                 info = {
                     alvo: container,
                     Tipo: e.type
                 };
 
             / Olhar / para um elemento com a classe yui3-evento-ligante
             while (&& contentores! filter.test (container.className)) {
                 container = container.parentNode;
             }
 
             if (container) {
                 (Binder.q = binder.q | | []) push (informações).;
 
                 / / Evitar a ação navegador padrão para este evento
                 if (e.preventDefault) {
                     e.preventDefault ();
                 }
                 retorno (e.returnValue = false);
             }
         },
         / Interface / ouvir para eventos específicos
         listenFor: function (type) {
             var d = document;
             / / Antes de as cargas da biblioteca, temos de lidar com inconsistências navegador
             if (d.addEventListener) {
                 d.addEventListener (tipo, this.fn, false);
             Else {}
                 d.attachEvent ('on' + tipo, this.fn);
             }
 
             envie este;
         }
     }
 };
 / / Adiciona eventos ao processo de acompanhamento
 YUI_config.eventbinder.listenFor ('click');

Este código deve ser incluído no topo da página. Será apenas algumas mordidas depois de apoucar este objeto de configuração. Eu recomendo usar um arquivo (externo) cacheable para a produção e incluindo-a na seção de cabeça em suas páginas. Você pode ler mais sobre YUI_config e as diferentes configurações que você pode ajustar através desse objeto na documentação da API oficial .

Você pode modificar esta configuração para servi-lo melhor, e definir os eventos que você se preocupa também. No exemplo acima, adicionamos 'click' para a lista de monitoramento (última linha). Você pode adicionar vários eventos para a lista de monitoramento usando encadeamento:

  YUI_config.eventbinder.listenFor ('click') listenFor ('keyup') listenFor ('mouseover')..; 

Como funciona este recurso?

Uma vez que a configuração (isto é, YUI_config lógica) é executada, juntamente com a chamada para YUI_config.eventbinder.listenFor , um ouvinte para um tipo de evento específico será definido. Somente eventos que se bolha vai ser monitorados como o ouvinte será definido para o document elemento. Quando uma interação com o usuário é pego a este nível, que serão analisados, especificamente verificar se o elemento de destino ou de qualquer de seus ancestrais tem classname yui3-event-binder . Se assim for, o evento vai ser adicionado a uma fila e o comportamento padrão para que o evento será impedido. Esta técnica oferece uma maneira fácil de monitorar tipos específicos de interação em áreas específicas da página.

Quando esse código é executado, os ouvintes para eventos do tipo especificado ou tipos são adicionados ao document , então quando esses eventos ocorrem e borbulhar (estes eventos apenas monitores que bolhas), que será interrompido e suas informações armazenadas em uma fila de processamento . Mais tarde, em seu use() de retorno de chamada quando a inicialização estiver concluída, basta ligar para Y.EventBinder.flush a reexpedição todos os eventos clique armazenados como se tivessem acontecido só depois de cortesia do módulo de simulação de eventos.

Facilitar a natureza on-demand de algumas interações com o usuário

O principal objetivo desse recurso é ajudar os desenvolvedores a definir a lógica de carregamento com base em interações do usuário.

Aqui está outro exemplo aglutinante evento :

 
 YUI ({
   módulos: {
     "My-módulo personalizado": {
       fullpath: '. / my-custom-module.js'
     }
   }
 }). Usar ('galeria evento pasta', 'nó', function (Y) {
 
   / / Definir um ouvinte para '# demo' e confiar em "minha-module-custom ' 
   / / Para lidar com esse evento em particular.
   Y.EventBinder.on ('click', 'meu-module-costume', '# demo');
 
   / / Definir um ouvinte delegado para todas as âncoras em uma lista e confiar  
   / / On 'my-custom-módulo' e 'meu-outro módulo' para lidar com esses eventos particulares
   Y.EventBinder.delegate ('click', ['meu-outro módulo'], '# mylist', 'li a');
 
 });

Aqui usamos Y.EventBinder.on e Y.EventBinder.delegate para definir alguns ouvintes. Estes dois métodos envoltório Y.on e Y.delegate dirigir lógica de carga através de uma interação do usuário. Isso nos permite adiar o carregamento de uma funcionalidade específica de uma página até que o usuário tenta usar um recurso específico.

Neste caso, quando um usuário clica em um dos elementos, nós carregamos um ou mais módulos personalizados YUI que implementam todos os recursos associados a esse clique particular. Uma vez que os módulos ficam disponíveis (e novos ouvintes são definidos), a pasta irá liberar o evento que estava em espera durante o processo de carregamento para preservar o estado da acção.

This feature doesn't require any initial configuration. Both of Event Binder's features can be used at the same time to cover early and on-demand user-interactions. In this case, you need to define the configuration, then set the on-demand listeners, and finally flush the early events.

Here's an end-to-end event binder example :

 
// configuration
YUI_config = { /* your custom event-binder configuration here */ };
YUI_config.eventbinder.listenFor('click')
 
// initialization
YUI({
   módulos: {
    'my-custom-module': {
      fullpath: './my-custom-module.js'
     }
   }
}).use('gallery-event-binder', function(Y) {
  
  Y.EventBinder.delegate('click', ['my-custom-module'], '#doc', '.yui3-event-binder a');
  Y.EventBinder.flush('click');
 
 });

A more advanced configuration

You can modify the fn function in your configuration to be more selective about which events to queue and you can store more information about the events. Additionally adds a yui3-waiting class to the click target which we style in CSS to display a loading spinner:

 
YUI_config = {
    // standard YUI_config configuration
    combine: true,
    filter: 'min',
 
    // event binder configuration starts here
    eventbinder: {
        // set of options that should be preserved for every event (all optional)
        eventProperties: [
            "ctrlKey", "altKey",
            "shiftKey", "metaKey",
            "keyCode", "charCode",
            "screenX", "screenY",
            "clientX", "clientY",
            "button",
            "relatedTarget"
         ],
 
        // listener callback function
        fn: function(e) {
            var binder = YUI_config.eventbinder,
                props = binder.eventProperties,
                filter = /yui3-event-binder/,
                target = (e.target || e.srcElement),
                container = target,
                info = {
                    target: target,
                    type : e.type
                 },
                 i;
 
            if (target.nodeType === 3) {
                // target is a text node, so use its parent element
                target = target.parentNode;
             }
 
            // look for an element with the class yui3-event-binder
            while (container && !filter.test(container.className)) {
                container = container.parentNode;
             }
 
            if (container) {
                target.className += ' yui3-waiting';
 
                // back up the event properties to simulate the event later on
                for (i = props.length - 1; i >= 0; --i) {
                    info[props[i]] = e[props[i]];
                 }
 
                (binder.q = binder.q || []).push(info);
 
                // prevent the default browser action for this event
                if (e.preventDefault) {
                     e.preventDefault ();
                 }
                return (e.returnValue = false);
             }
         },
 
        listenFor: function(type) {
            var d = document;
 
            if (d.addEventListener) {
                d.addEventListener(type, this.fn, false);
             Else {}
                d.attachEvent('on' + type, this.fn);
             }
 
             envie este;
         }
     }
 };
// add events to the monitoring process
YUI_config.eventbinder.listenFor('click');

Check out this event binder example to see this advanced configuration in action.

Conclusão:

For high performance web applications, it's important for pages to load and become responsive quickly. To accomplish this, we have to rely on on-demand loading techniques. Once you start using them, it's equally important to control user interactions that can happen before the corresponding code for an action become available.

Event Binder (gallery-event-binder) provides friendly APIs to deal with both use-cases without you having to change your application logic. It can be applied to any YUI 3 application without introducing extra complexity to your code.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

Using the YUI 3 Calendar Date Selector from Alloy

June 18, 2010 at 10:46 am by Eric Miraglia | In Development , YUI 3 Gallery | 6 Comments

The Alloy components (contributed by Nate Cavanaugh and Eduardo Lundgren from Liferay) in the YUI 3 Gallery are simple to use. This example illustrates the use of the Alloy calendar to progressively enhance a set of select elements for date selection.

Let's start with the markup — the HTML that will be on the page and functioning regardless of whether JavaScript is enabled. Alloy's Calendar module does not require this markup; you can feed it an empty element and it will create the select elements for you in the event that your use case would not benefit from progressive enhancement.

 <div id="calendar">
	<select class="yui3-datepicker-month" name="month" id="monthselect">
		<option value="0">
			 Janeiro
		</option>
		<option value="1">
			 Fevereiro
		</option>

 ...

	 </ Select>

        <select class="yui3-datepicker-day" name="day" id="dayselect">
		<option value="1">
			 1
		</option>
		<option value="2">
			 2
		</option>

 ...

	 </ Select>

        <select class="yui3-datepicker-year" name="year" id="yearselect">
		<option value="2009">
			 2009
		</option>

 ...

	 </ Select>
 </ Div> 

With this markup in place (or with just an empty root element if we aren't progressively enhancing existing form fields), we bring in the Alloy Calendar module with datepicker selection support from the YUI 3 Gallery . This requires us to have YUI 3 on the page and then to follow the configuration step outlined on the module's Gallery page .

 <script src="http://yui.yahooapis.com/3.1.1/build/yui/yui-min.js"></script>
 <script>
YUI({
	// All of this configuration information can be cut-and-pasted from the Gallery entry for
	// this module: http://yuilibrary.com/gallery/show/aui-calendar-datepicker-select
    gallery: 'gallery-2010.06.07-17-52',
     módulos: {
        'gallery-aui-skin-base': {
            fullpath: 'http://yui.yahooapis.com/gallery-2010.06.07-17-52/build/gallery-aui-skin-base/css/
							gallery-aui-skin-base-min.css',
            type: 'css'
         },
        'gallery-aui-skin-classic': {
            fullpath: 'http://yui.yahooapis.com/gallery-2010.06.07-17-52/build/
							gallery-aui-skin-classic/css/
							gallery-aui-skin-classic-min.css',
            type: 'css',
            requires: ['gallery-aui-skin-base']
         }
     }
}).use('gallery-aui-calendar-datepicker-select', function(Y) {
    var datePickerSelect = new Y.DatePickerSelect({
		displayBoundingBox: '#calendar',
		dateFormat: '%m/%d/%y',
		yearRange: [ 2009, 2012 ],
		dayField: Y.one("#dayselect"),
		dayFieldName: "day",
		monthField: Y.one("#monthselect"),
		monthFieldName: "month",
		yearField: Y.one("#yearselect"),
		yearFieldName: "year"
	}).render();
 });

 </ Script> 

Here's a live version of this simple example .

É tão simples como isso. The configuration properties for datePickerSelect are lucidly defined in the Alloy documentation . In this example, the properties are used to set the root element, format the date, set the date range, and then wire up our existing select elements to the widget instance so that it knows which form fields to use for progressive enhancement. In practice, only the root element ( displayBondingBox ) is a required property.

Check out the YUI 3 Gallery roster for a full list of the Alloy UI contributions .

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

Implementation Focus: YUI 3 Powering Autofusion's ResearchPro

June 18, 2010 at 9:00 am by Josh Lizarraga | In Development | Comments Off

About the author: Josh Lizarraga is a YUI Contributor and frontend developer located in San Diego, California. He uses YUI to build rich frontend interfaces and Ajax applications for Autofusion, Inc. , a San Diego firm that offers web solutions to the automotive industry in the United States and Canada. When he's not on the clock, Josh enjoys contributing to the YUI project with test cases and Gallery modules.

Sobre o Projeto

In addition to serving industry professionals, Autofusion provides end-user information resources via our CarPrices.com sister-site. “ResearchPro” is the name we've bestowed on our brand new car research application, which allows the user to quickly and easily find everything there is to know about a potential new car purchase.

Researching a new car before you buy is typically a daunting yet necessary experience, and the current options available to consumers are not very user-friendly. ResearchPro attempts to remedy these issues with a simple, guided approach to car research. We also take the experience one step further, allowing customers to receive a free quote on their dream car from local dealers.

Why YUI?

We started using YUI 2 for all of our frontend development about two years ago, and haven't looked back. YUI's focus on application development makes it a no-brainer for Autofusion, as we provide many embeddable web apps and widgets to our customers.

Over the years we have used just about every YUI 2 component there is in both our client web properties and our internal tools. YUI's proven track record and incredible documentation really set it apart from the other libraries we've worked with. The refinements to the library offered by YUI 3 made it an easy choice for this project.

How YUI is Utilized in the Project

ResearchPro makes use of several YUI 3 components, namely IO , JSON , Node , Event , Animation , and even the beta Slider widget. We're also using the selector-css3 and event-mouseenter modules, as well as a custom module that handles the JSON communication with the backend.

Challenges and Benefits of Using YUI 3

Migrating from YUI 2 to YUI 3 was both the largest challenge and the largest benefit during ResearchPro's development. Working with Node instances instead of DOM nodes directly can take some adjusting to at first, but we quickly found that this excellent abstraction greatly reduces the amount and complexity of the code for a given task. Likewise, the chainability of YUI 3 methods offers some great syntactic sugar that is hard to live without.

The primary challenge of the YUI 3 migration was and continues to be beta bugs. The first YUI 3 beta was released a few months before we started development, and we took that opportunity to start this project with the new codeline. We wanted to be familiar with YUI 3 once it replaces YUI 2 in our workflow down the road. During development, we discovered and reported several bugs, some of which are still being worked out today.

What's Next for Autofusion?

We are always developing new products with YUI and revising our existing offerings to incorporate YUI on the frontend. Our online inventory solution is powered by YUI 2, and we're currently planning a refined version of the product that will use YUI 3 in its place.

Our inventory interface makes heavy use of the Container module family, so hopefully by the time we start development YUI 3 will have implementations of Panel and Dialog. We've been very pleased with the rapid growth of features, and expect YUI to be our frontend toolkit of choice for years to come.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!

YUI: Open Hours, Wed June 16th

June 15, 2010 at 12:26 am by Luke Smith | In Development | 2 Comments

It's time again for YUI: Open Hours ! A change of schedule this week, though. The call will be on Wednesday .

I want to start by sending a huge thanks to Iliyan Peychev, Andrew Bialecki , Matt Snider , and Jacob Fogg for featuring their Gallery widgets in the last Open Hours. From Matt's game UI inspired Radial Menu to Iliyan's full featured Accordion , it was a great exploration of the types of UI tools you can find (or create) in the Gallery today as well as a study in different ways to use YUI 3 to solve UI challenges. You can find links to the modules in the May 21st Open Hours post , and a sampling of some of the interesting points from the discussion in the comments .

This week, hot on the heels of their huge YUI 3 Gallery contribution , Nate Cavanaugh and Eduardo Lundgren of Liferay, Inc. will be joining us to introduce us to some of the new AlloyUI modules. Este é um negócio muito grande. We've been working with these guys for months to get their 65 modules into the Gallery. That's right, 65 modules! All created by just Nate and Eduardo. Talk about productive.

Obviously we'll barely have time to scratch the surface of all the AlloyUI modules, but we will do a quick overview of some of the most interesting or popular ones and cover some “Getting started” code. There's such a variety of modules, there will be something for everyone.

• For YUI 3 newcomers or folks that have been waiting for the YUI 2 widgets to be migrated, there are now a lot more options to check out.
• For people wanting to take those first steps creating something in YUI 3, there are now more things to write plugins for, patch, or extend.
• For seasoned component developers, there's now a lot more implementation code to reference for evolving conventions and components to collaborate on.
• For more complex app developers, you can get a sense of one team's strategy for code submodularization and approach for building and packaging modules in a larger or more complex application.

Nate and Eduardo are open to whatever questions you have, so the conversation can go however deep, and in whichever direction you want. If you have any questions about a particular module or about anything else, ask away.

We're changing up a little this week and moving Open Hours to Wednesday . The time will be the same as before, though (10am – 12pm PDT), and the connection details are also the same:

1. Dial in to 1-888-371-8922 (non-US participants, email me for a local number)
2. Enter the attendee code 4718 8953#
3. Join the screen sharing session (this will prompt you to install the Adobe Connect plugin if this is your first time using it)

And as always, you can keep up to date with the upcoming schedule and topics by following @yuilibrary on Twitter or subscribing to the YUI Event Calendar .

Espero ver você lá!

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!