Mobile Browser Limiti Cache: Android, iOS e webOS

28 giugno 2010 alle 8:45 am da Ryan Grove | In Development , le performance | 19 commenti

Aggiornamento (12 luglio 2010): Mentre i risultati descritti in questo articolo sono accurate per le pagine HTML, nuovi test hanno rivelato i limiti della cache molto diverse per le risorse CSS e JS. I risultati aggiornati sono descritti in Limiti di mobili cache del browser, Revisited .

All'inizio del 2008, Wayne Shea e Tenni Theurer scritto un post sul Blog YUI Cache per iPhone in cui hanno condiviso i risultati della ricerca in varie caratteristiche e le limitazioni di cache di Safari Mobile di iPhone OS in 1.x. Tra le altre cose, hanno scoperto che i singoli componenti di dimensioni superiori a 25KB non sono stati memorizzati nella cache, e che vi era una dimensione massima della cache complessiva compresa tra 475KB e 500KB.

Molto è cambiato da allora. Abbiamo visto due nuove uscite principali e molte minor release di iPhone OS (ora iOS), e molti altri dispositivi mobili dotati di browser sono apparsi molto in grado di sfidare l'iPhone. Stoyan Stefanov trovato, alla fine del 2009, che i limiti della cache di iPhone era cambiato (purtroppo, in peggio). Ma dove stanno le cose adesso? E che dire di quei non-IOS browser?

Fondo

I browser sono due tipi di cache che siamo interessati ai fini di questi test:

  • La cache del componente, o cache degli oggetti, memorizza i file singoli. HTML, CSS, JavaScript, immagini e tutti vanno nella cache componente. Ogni volta che ha bisogno di uno di questi componenti, il browser controlla innanzitutto la cache prima di fare una richiesta di rete.
  • La cache pagina, noto anche come cache avanti / indietro, memorizza un'intera pagina e tutti i suoi componenti, così come loro stato attuale. Quando si utilizza il tasto indietro o in avanti, il browser caricherà la pagina dalla cache della pagina se possibile.

La cache dell'applicazione HTML5 è un altro tipo di cache che è ampiamente supportato dai browser mobili. I produttori di browser già fare un buon lavoro di documentare i limiti della cache dell'applicazione, quindi non ho incluso nel mio test. Maggiori informazioni sulla cache dell'applicazione in seguito.

Dispositivi Testato

Ho provato i seguenti browser mobile / platform combinazioni:

  • Android 2.1 (Nexus One)
  • Mobile Safari su iOS 3.1.3 (1 ° gen-iPhone)
  • Mobile Safari su iOS 3.2 (iPad)
  • Mobile Safari su iOS 4.0 (iPhone 3GS)
  • Mobile Safari su iOS 4.0 (iPhone 4)
  • webOS 1.4.1 (Palm Pre Plus)

Nota: Con l'eccezione di Mobile Safari su iOS 4.0, ho provato solo un dispositivo in ogni categoria. Se ci sono variazioni tra i singoli dispositivi o le differenze in base al software installato al di là del sistema operativo, le mie prove non rilevare tali variazioni. Questi particolari dispositivi sono stati testati perché sono quelli che ho avuto accesso a, non perché ritengo che siano più importanti di altri dispositivi.

Metodologia

Test Cache è noioso, ma relativamente semplice.

Ho scritto una piccola app Sinatra ( fork su GitHub! ) che genera una risposta costituita da un numero minimo di caratteri alfanumerici e di byte pseudocasuali spazi. Le risposte possono essere serviti sia compresso con gzip o non compresso. I seguenti lontano futuro intestazioni di risposta di scadenza vengono inviati a garantire che tutte le risposte sono considerati cacheable:

 Cache-Control: max-age = 315360000
 Scade: Fri, 1 MAGGIO 2020 03:47:24 GMT

Sopra la mia rete locale, ho poi eseguita manualmente le seguenti operazioni su ogni dispositivo per testare la cache componente:

  1. Caricare la pagina di test cache dell'indice.
  2. Toccare un collegamento a un componente di una certa dimensione, che vanno dai 5 KB a 20 MB, e attendere che finisca il caricamento.
  3. Toccare il pulsante Indietro.
  4. Toccare il collegamento stesso. Osservare se i caratteri casuali sono gli stessi, e se la console server di stampa un log per una richiesta, per determinare se il componente è stato memorizzato nella cache nel passaggio 2.
  5. Ripetere e regolare le dimensioni dei componenti, come necessarie per determinare la dimensione massima componente che verrà memorizzata nella cache.

Per testare la cache della pagina, ho eseguito in sostanza gli stessi passaggi, tranne che invece di toccare nuovamente il link al punto 4, ho sfruttato il pulsante avanti del browser, facendo in modo da utilizzare la cache della pagina, piuttosto che la cache componente.

Supporto per ETag e Last-Modified è stato determinato dal tweaking al server di inviare l'appropriato ETag o Last-Modified intestazioni di risposta (in test separati) e di omettere le intestazioni lontano futuro di scadenza. Poi ho controllato le intestazioni delle richieste ricevute dal server per verificare che il browser ha inviato l'atteso If-None-Match o If-Modified-Since header al punto 4.

Risultati

Ho provato con gzip sia attivato e disattivato, ma ho scoperto che gzip non ha effetto sulla cacheability su qualsiasi dispositivo. Il formato non compresso componente è ciò che conta in tutti i casi, indipendentemente dal fatto o meno tale componente viene servita compresso con gzip. Come tale, tutte le dimensioni dei componenti citati qui sono formati non compressi.

La tabella sottostante illustra le conclusioni raggiunte.

Tabella: caratteristiche della cache del browser per cellulari
Browser / OS / Device Componente Limit singolo Componente limite complessivo Page Cache Size Limit Supporta Last-Modified Supporta ETag Sopravvive Ciclo di alimentazione
Android 2.1 (Nexus One) ~ 2MB (~ 2.048.000 b) ~ 2MB (~ 2.048.000 b) 2
Safari Mobile, iOS 3.1.3 (1 ° gen-iPhone) 0B 1 0B 1 2 No No No
Safari Mobile, iOS 3.2 (iPad) 25.6KB (26.214 b) 281.6KB ~ (~ 288.354 b) 25.6KB (26.214 b) No
Safari Mobile, iOS 4.0 (iPhone 3GS) 51.199KB (52.428 b) ~ 1.05MB (~ 1.100.988 b) 2 No
Safari Mobile, iOS 4.0 (iPhone 4) 102.399KB (104.857 b) ~ 1.9MB (~ 1.992.283 b) 2 No
webOS 1.4.1 (Palm Pre Plus) 3 ~ 1MB (~ 1.048.576) ? ~ 1MB (~ 1.048.576) No No

Note:

1 Mobile Safari su iOS 3.1.3 non sembra conservare nella cache i componenti, indipendentemente dalle dimensioni, fatta eccezione per la cache di pagina. Non è chiaro se questo sia intenzionale o di un bug.

2 Le cache di pagina in Android 2.1, iOS 3.1.3 e iOS 4.0 (ma non iOS 3.2) sembrano essere limitato solo dalla memoria RAM disponibile quando si tratta di dimensioni singola pagina. Non ha cercato di determinare con esattezza quante pagine separate potessero coesistere nella cache di pagina in una sola volta.

Risultati dei test 3 webOS erano incompatibili e in vari punti della cache sembrava di smettere di lavorare del tutto fino a quando il telefono era spento e riacceso. Non ritengo che questi risultati conclusivi, o anche di fiducia, ma sono elencati qui per omogeneità di confronto.

Androide

Il browser Android esposto il comportamento migliore della cache di tutti i dispositivi testati. Mentre sembra imporre alcun limite alle dimensioni dei singoli componenti, la dimensione della cache totale sembra essere limitata a circa 2MB, il che significa che i singoli componenti siano effettivamente limitati a 2MB pure.

La cache di pagina sembra imporre alcun limite alle dimensioni delle singole pagine, ogni byte caching felicemente ho buttato a farlo finché la RAM disponibile è stata esaurita e il browser si è bloccato.

Sono stato piacevolmente sorpreso di scoprire che la cache del componente di Android è sopravvissuto sia riavviato browser e cicli di potenza, una prodezza nessuno dei dispositivi iOS è stato in grado di eguagliare.

Possibile caveat: Una rassegna di sorgenti di Android WebKit mi porta a credere che i limiti della cache può adattare in base alla quantità di RAM e / o memoria flash disponibile sul particolare dispositivo su cui è in esecuzione. Se fosse vero, questi numeri possono essere applicabili solo al Nexus One. Infatti, se la dimensione della cache si adatta in base alla memoria inutilizzata piuttosto che la memoria totale, questi numeri possono essere applicabili solo al mio Nexus One.

Potrei sbagliarmi, ma le differenze nei risultati dei test sui iOS 4.0 iPhone 3GS e iPhone 4 sostegno di questa teoria. (Android e Mobile Safari sono entrambi i browser WebKit-based, in modo che questo comportamento può avere in comune.) Se si ha familiarità con la sorgente WebKit e può far luce su questo, si prega di mettersi in contatto con me.

iOS

Risultati varia selvaggiamente attraverso le tre versioni più recenti di IOS. Sorprendentemente, Mobile Safari su iOS 3.1.3 non memorizzare nella cache i componenti di qualsiasi dimensione, nonostante l'apparentemente illimitata dimensione della cache della pagina. Questo è preoccupante perché significa iOS 3.1.3 gli utenti sono probabilmente ottenere un'esperienza di navigazione ottimale, specialmente se non si utilizza wifi. L'illimitata dimensione della cache pagina fa poco bene qui, dal momento che entra in gioco solo per il back / forward navigazioni. Questo comportamento è un cambiamento significativo da quanto osservato in altri precedenti versioni di IOS e non riesco a immaginare una buona ragione per farlo, quindi credo che questo potrebbe essere un bug.

Mobile Safari su iOS 3.2 (che è disponibile solo su iPad) non presenta questo bug. Il suo limite componente 25.6KB e ~ limite 281.6KB cache totale sono meglio di niente, ma sembrano ancora irrisorio rispetto agli altri dispositivi testati. Unica tra i dispositivi iOS, l'iPad sembra limitare la dimensione delle pagine nella cache pagina per 25.6KB, lo stesso che il suo limite di dimensione dei componenti.

Mobile Safari su iOS 4.0 esposto limiti differenti sui 3GS iPhone e su iPhone 4, il che implica che i limiti si adattano sulla base di RAM disponibile (l'iPhone 3GS dispone di 256MB, mentre l'iPhone 4 ha 512 MB, entrambi i dispositivi testati avuto 32GB di memoria flash) . Sulle iPhone 3GS, iOS 4.0 ha una 51.199KB limite di dimensioni dei componenti e una ~ 1.05MB totale dimensione della cache del componente.

Su iPhone 4, il limite di dimensione dei componenti era quasi esattamente due volte il limite per l'iPhone 3GS, a 102.399KB. Il totale dimensione della cache dei componenti è stato di circa 1.9MB. Forse perché iOS 3.2 e iOS 4.0 sono state sviluppate separatamente, ma si dirama da un antenato comune, la pagina iOS 4.0 dimensione della cache sembra essere limitata solo dalla RAM disponibile su entrambi i dispositivi testati, proprio come iOS 3.1.3.

Nessuno dei dispositivi iOS conservato il contenuto della cache del browser durante il riavvio forzato o cicli di alimentazione del dispositivo, anche se ha mantenuto la cache quando si limita a passare da un'applicazione all'altra senza però uccidere il browser.

webOS

I miei risultati dei test su webOS erano così inconsistenti che ho poca fiducia in loro. Ho incluso quello che pochi dati sono riuscito a raccogliere esclusivamente per ragioni di completezza. Si prega di prendere con un grano di sale pesante.

Il più vicino come mi è stato in grado di determinare, webOS potrebbe avere un limite di dimensione individuale componente di circa 1 MB, con un limite di dimensione corrispondente pagina nella cache di pagina. Non ero in grado di convincere If-None-Match o If-Modified-Since header di richiesta di webOS, il che implica che non supporta ETag e Last-Modified .

In alcuni test, è emerso che le dimensioni dei componenti massima webOS donna era più grande di 1 MB, ma questo era inconsistente. Per quanto ne so, webOS sembra avere un bug brutto dove, dopo un certo punto, forse quando la dimensione massima della cache totale viene raggiunta la cache appena smette completamente di funzionare del tutto fino a quando il telefono è spento e riacceso. In alcuni casi anche il ciclismo potere non fissare la rottura cache, quindi alla fine ho rinunciato a stabilire la causa esatta del problema e gli esatti limiti della cache webOS.

Raccomandazioni

Sulla base di questi risultati, offro le seguenti raccomandazioni a chiunque lo sviluppo di applicazioni web per i dispositivi testati:

  • Utilizzare lontano futuro intestazioni di scadenza della cache. Questo modo si evita il browser di dover inviare una richiesta GET condizionale e migliorerà cacheability in webOS, che non supporta ETag o Last-Modified .
  • Almeno fino a quando iOS 4.0 arriva su iPad, cercare di limitare le dimensioni dei singoli componenti a 25.6KB o meno, non compresso. E invito gli utenti iPhone l'aggiornamento a iOS 4.0 il più presto possibile.
  • Se il vostro sito deve supportare gli utenti iOS 3.1.3 (che è probabile), se richiede componenti più grande di 25.6KB, o se la dimensione totale di tutti i componenti è maggiore di 281.6KB, è consigliabile utilizzare la cache dell'applicazione HTML5, localStorage o archiviazione di database per memorizzare i vostri componenti. Alex Kessinger YUI la recente post sul blog, un'introduzione all'uso di YUI 3 in applicazioni offline , potrebbero essere di interesse per gli sviluppatori YUI 3 considerando questo approccio.
  • Fate il vostro test personale. Non date per scontato che questi risultati si applicano a qualsiasi futura versione di uno dei browser testati o dispositivi. Utilizzare questi risultati come punto di partenza, ma verificare voi stessi prima di prendere importanti decisioni basate su ipotesi relative limitazioni di cache mobili. I mobili del browser cambia mondo a un ritmo un fulmine, quindi questa ricerca avrà una durata molto breve.

Ho fatto il mio codice di prova disponibile su GitHub e vi incoraggio ad usarlo, forcella, e condividere ciò che si impara.

Invito a presentare documentazione

I produttori di browser, perche documentare e pubblicare i limiti della cache del tuo browser. Nel mondo desktop dove questi limiti sono in genere così elevato da essere un non-problema, la documentazione non era necessario. Nel mondo mobile, i limiti della cache del browser sono informazioni di vitale importanza che gli sviluppatori web devono avere per creare siti web performanti con caratteristiche interessanti.

I limiti di nuove funzionalità come localStorage e la cache dell'applicazione sono in genere ben documentate. Si prega di estendere questo livello di documentazione alla cache componente pure.

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

In the Wild per il 25 giugno 2010

25 Giugno 2010 alle 10:10 am da Eric Miraglia | In In the Wild | Commenti disabilitati

Come sempre, fateci sapere nei commenti o @ yuilibrary se ne abbiamo tralasciato qualcosa di importante.

  • YUI 3-based UI lega formalmente annunciato alla Conferenza Liferay : Dal comunicato stampa : 'Come parte di questo sforzo, Liferay ha inoltre annunciato la disponibilità immediata di UI lega Liferay . Sviluppato in collaborazione con Yahoo YUI progetto, lega interfaccia utente fornisce un insieme di componenti ricca interfaccia utente per creare rapidamente portlet user-friendly, widget e applicazioni web. UI Lega occupa la complessità di CSS, HTML e Javascript, liberando gli sviluppatori di concentrarsi sulle esigenze di business e funzionalità. UI Lega aiuta anche a risolvere alcuni comuni cross-browser problemi di compatibilità che tipicamente consumano risorse del progetto. La nuova libreria non richiede un portale e può essere usato per sviluppare componenti per qualsiasi applicazione web. Liferay Portal sarà standardizzare il suo front-end framework UI intorno lega, ampliando la semplicità e la funzionalità dei moderni portal basate su soluzioni aziendali. 'UI Lega rappresenta una nuova funzionalità per gli sviluppatori web per semplificare lo sviluppo di interfacce utente ricche,' ha dichiarato Brian Chan, Liferay creatore Portal e Chief Software Architect. 'Siamo felici di aver lavorato su questo con il team di Yahoo e sento che sarà una grande risorsa per aiutare gli sviluppatori con le loro soluzioni.' 'Tutti i componenti dell'interfaccia utente in lega sono ora disponibili gratuitamente per la comunità YUI nella Galleria 3 YUI .
  • CarPrices.com AutoFusion lancia Utilizzando YUI 3.1.1 : YUI 3 Galleria contributo Josh Lizarraga ha lavorato con Autofusion Inc. sul nuovo progetto CarPrices.com , costruita con una serie di YUI 3.1.1 utilities e widget. Josh avrà più su questo progetto in un post YUIBlog futuro.
  • Scarica Squad di Erez Zukerman Mette in JS Devs per guardare Crockford su YUI Theater : Scrive Erez: " Douglas Crockford è un genio. Scherzi a parte - il ragazzo è brillante. Ha attualmente in servizio come architetto Yahoo! 's chief JavaScript, ha inventato JSON (un diffuso Data Interchange Format), fa parte del comitato di ECMAScript (i ragazzi definendo lo standard JavaScript) e ha una conoscenza molto ampia della storia generale della programmazione lingue e informatica. Recentemente, Crockford ha dato cinque conferenze su JavaScript come parte di Yahoo! 's Theater YUI . Questi sono tutti disponibili gratuitamente, e sono più di cinque ore in lunghezza (più simile a sei a sette ore in totale, credo). Cosa c'è di così interessante di questi colloqui è che Crockford vi dà un visione d'insieme del soggetto, la prima ora è solo storia, ed è davvero affascinante. E 'dappertutto, a cominciare dal telaio Jackquad , attraverso il motivo per cui abbiamo sia uno Delete e una chiave Backspace sulle nostre tastiere, fino ai linguaggi di programmazione moderni e JavaScript. "Per più di risorse preferite Erez di JavaScript, check out il suo posto , o la testa verso il Crockford a pagina JavaScript per Douglas ultimi video (con molti altri riempire la seconda colonna di YUI Theater ).
  • Congratulazioni a Matt Snider & Friends a YUI 2-based Mint.com, vincitori di un Webby 2010 : Congratulazioni a Matt Snider . e gli altri ingegneri in circolazione a Mint.com frontend per il loro meritato Webby Award 2010 nella categoria Financial Services Mint è stato YUI 2-based fin dall'inizio , e Matt continua ad essere un contributo al grande progetto di YUI . Potete vedere Matt cinque parole sul discorso di accettazione su YouTube .
  • Galleria Ajaxian di Dion Almaer recensioni Caridy Patiño Mayea del Modulo di precarico per YUI 3 : Dion ha un bel post su Ajaxian revisione del modulo Preload Caridy Patiño Mayea per il prefetching e caching attivi , a 3 Galleria voce di YUI che ha scritto di recente su YUIBlog .
  • Utilizzando Griglie YUI con Movable Type (by @ foxxtrot) : YUI contributor Jeff Craig ha scritto sulla sua esperienza la conversione di un blog Movable Type per YUI 2 Griglie: "Quindi, come chiunque abbia letto il mio blog prima, vedrete che nel fine settimana Ho aggiornato il mio blog template da usare e YUI Grids YUI3 per il JavaScript. Con il passaggio di distanza dai modelli MT (o, i modelli che erano standard quando ho installato le prime versioni di OMT 4), sono stato in grado di ridurre il pageweight HTML mezzo dannatamente vicino. I modelli vecchi erano davvero div pesante, e aveva un sacco di markup extra. Per lo più, la decisione è stata guidata dal desiderio di rifare la sensazione visiva del mio blog, e ho sentito che posso anche riscrivere in YUI Grids, mentre lo faccio. "
  • Nate Schutta Confronta YUI e Dojo per DevelperWorks IBM : Nate Schutta scrivere per IBM developerWorks confronta YUI 2.xe Dojo in un nuovo post. Mentre noi siamo concentrati più sulla 3.x YUI codeline in questi giorni, l'articolo Nate ha alcune linee guida utili per tutti coloro pensare librerie JavaScript e di prendere una decisione per la loro attività o progetto. In primo luogo - perché YUI o Dojo?

    Con ottime scelte così tanti a disposizione, perché si considera YUI o Dojo? In una parola: la completezza. A differenza di altre soluzioni che coinvolgono librerie aggiuntive o plug-in, Dojo e YUI avere tutto (e più) che oggi front-end tecnico possa desiderare. Anche se questo è sia una benedizione e una maledizione, se siete nel mercato per un one-stop shop per le vostre esigenze Ajax, si tratta di due contendenti potenti. Oltre ad una ricchezza di aiutanti JavaScript e utilità, sia top-notch widget offerta e controlli, ben oltre la tavolozza limitata del browser standard.

    Nate su consiglio criteri generali di selezione della libreria è utile:
    • Cosa vuoi fuori di esso? Sei alla ricerca di un sostituto completo di quasi tutti gli elementi dell'interfaccia utente della pagina, o siete solo in cerca di qualcosa da prendere un po 'del dolore di programmazione JavaScript?
    • Quanto è facile da leggere il codice? Nonostante i miglioramenti enormi nella documentazione nel corso degli ultimi anni, è probabile che si dovrà scavare nel codice ad un certo punto. Prima di impegnarsi in una biblioteca, trascorrere qualche ora in ginocchio la fonte. E 'facile da capire, o se anche l'autore originale ha problemi con esso?
    • Quanto è buona la documentazione? Codice pulito e leggibile può fare a meno-che-stellari documenti, ma nulla vi aiuta a iniziare proprio così tutorial ed esempi. Poke intorno al wiki o al sito web, e vedere che cosa hanno da offrire. Sono gli esempi chiari e facili da seguire? Esiste una veloce ricerca su Google porterà alla parte proprio del loro materiale?
    • Qual è la comunità che circonda, come la biblioteca? Scopri le mailing list. C'è un sacco di traffico? Sono nuove persone trattate con rispetto o derisione? Ha il codice è stato aggiornato di recente, o era l'ultima versione parecchi anni fa?
    • Si può ottenere aiuto? Anche se questo è legato ai bit precedenti sulla comunità, è sempre utile dare un'occhiata in giro la comunità di sviluppo e vedere chi sta usando cosa. Controlla le schede di lavoro per ottenere un senso di quali librerie vengono visualizzati spesso in ripresa.

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

YUI: Orario di apertura Venerdì 25 giugno

23 Giu 2010 alle 15:07 da Luke Smith | In Sviluppo | Commenti disabilitati

L'ultima puntata di YUI: Orario di apertura sarà questo Venerdì, 25 giugno.

La settimana scorsa, Eduardo Lundgren ci ha introdotto ad alcuni dei grandi AlloyUI moduli aggiunti di recente alla Galleria. La discussione ha riguardato istanza, configurazione, le decisioni di sviluppo, e un pò di storia della loro TreeView modulo. Ma questo era solo l'inizio. Abbiamo anche esplorato il loro IO , Node , e la convalida di forma dei moduli e trascorse qualche tempo su alcuni degli stili visivi disponibili. Eduardo ci ha dato in anteprima del nuovo Liferay, Inc. portale, alimentato da tutto questo duro lavoro. Notch lavoro davvero superiore.

Tutto ciò che ha detto, è difficile dire se lo spettacolo-e-dire o la conversazione è stato il vero headliner. Grande codice contenuto correlato a parte, c'era un sacco di buon feedback e discussione sulla collaborazione della comunità, la natura della Galleria, e come possiamo farlo e YUI meglio. Quindi un grande grazie a tutti la chiamata!

Questa settimana, stiamo andando a dilettarsi un po 'sia nel mondo sviluppatore raw così come il mondo designer. Caridy Patiño è tornato con noi a parlare del suo evento Binder modulo che è stato descritto qui proprio questa mattina . Faremo una revisione del codice e discutere la fase di configurazione che deve essere fatto prima di YUI viene caricato. Proprio così: pura al DOM scripting. Si potrebbe desiderare di indossare un casco.

Poi ci sposteremo al processo di pelle altrettanto sfumato design con Jeff Conniff, il yahoo responsabile per la varietà attuale delle Slider look-and-feels. Egli ci cammina attraverso il suo processo di creazione delle risorse visive e mostrare come si può prendere il PSD stessi e creare facilmente colore attività a tema che si inseriscono nel tuo sito palette. Qui ci sono i file di Photoshop se si vuole suonare. Devo dire anche parlare di alcune delle decisioni prese nella costruzione della struttura CSS e DOM di Slider.

Siamo tornati al giorno e l'ora consueta di questa settimana: Venerdì 10:00-12:00 PDT. C'è un codice nuovo partecipante per la chiamata in conferenza, ma per il resto, i dettagli di connessione sono le stesse come al solito.

  1. Comporre al 1-888-371-8922 (non statunitensi partecipanti, mandatemi una email per un numero locale)
  2. Inserire il codice partecipante 47188953 #
  3. Partecipa alla sessione di condivisione dello schermo (questa vi verrà chiesto di installare il plugin Adobe Connect se questa è la prima volta ad usarlo)

Ho anche creato un thread del forum per questo Orario di apertura in modo da poter iniziare la discussione in anticipo!

Inoltre, come sempre, è possibile tenersi aggiornati con il programma imminente e gli argomenti seguendo @ yuilibrary su Twitter o iscrivendoti al Calendario degli eventi YUI .

Spero di vedervi lì!

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

Nel 3 YUI Gallery: Binder Caridy Patiño Mayea del modulo Event fornisce supporto per l'evento l'associazione anticipata e Event-driven Loading Module

23 Giu 2010 alle 9:25 pm Caridy Patino | In Development , YUI 3 Galleria | 1 commento

Questo articolo introduce il mio modulo Event Binder , recentemente pubblicato nella Galleria 3 YUI.

YUI 3 è sempre una buona trazione nella comunità degli sviluppatori, con l'adozione significativo della più recente versione 3.1.1 e un'infusione enorme di nuovi progetti innovativi nella Galleria 3 YUI . Molti sviluppatori stanno ottenendo le loro teste intorno alla natura on demand di YUI 3 e di iniziare a sfruttare queste capacità nei loro progetti. Questo approccio ha grandi vantaggi, ma può anche presentare alcune sfide.

Una di queste sfide è quello di catturare le interazioni degli utenti in anticipo. Anche se il browser si avvia il rendering della pagina, vogliamo che l'utente sia in grado di iniziare a interagire con gli elementi della pagina. In molti casi, tali interazioni possono avvenire prima che il processo di inizializzazione JavaScript (compreso il sequestro di listener) è stata completata.

In molti casi è possibile ottimizzare il codice di inizializzazione impostando solo i listener di eventi e quindi aggiungere la logica per il caricamento dei pezzi di cui avete bisogno per ogni interazione con l'utente. Recentemente, gli ingegneri di Facebook ha parlato di un approccio simile per migliorare il processo di caricamento - vedi l'intervista di Rey Bango a JSConf. Ecco un esempio di come questa tecnica potrebbe funzionare in 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 (). Utilizzare ('evento-base', function (Y) {
     / / Attendere finché l'utente non si concentra su un elemento di input per iniziare le attività di carico
     Y.on ("click", function (e) {
 
       Y.use ('anim', 'io', function () {
           / / Caricare un contenuto remoto e visualizzare utilizzando un'animazione qui
       });
 
       e.halt (); / / fermare la propagazione
     }, "Demo #");
 }); 

Questo introduce una certa complessità in codice perché non ascoltatori soltanto avere a che fare con l'interazione dell'utente, ma anche con una certa logica di carico. Un altro aspetto negativo di questo approccio è che avete ancora a caricare un codice JavaScript in alto (in questo caso le sementi YUI, l'utilità di eventi e alcune dipendenze), al fine di definire almeno l'ascoltatore e la logica di carico per catturare azioni precedenti. Quindi, consideriamo questo come due distinti casi d'uso:

Per rispondere a queste esigenze ho creato un nuovo modulo per YUI 3 . Il mio obiettivo principale è stato quello di creare un componente che funziona senza intaccare la logica dell'applicazione. Questo nuovo modulo si chiama " galleria-evento-legante "ed è ora disponibile attraverso il Loader YUI.

Catturare le interazioni degli utenti i primi

L'obiettivo principale di questa funzione è quello di garantire che le interazioni degli utenti sono in coda fino a quando i listener di eventi vengono inizializzati.

Vediamo un esempio legante evento :

  YUI ({
     / / Galleria Ultimo costruzione di questo modulo
     Galleria: 'gallery-2010/6/7-17-52'
 }). Utilizzare ('gallery-eventi-legante', 'evento', function (Y) {
 
     Y.on ('click', function (e) {
 
         / / Fai le tue cose qui
         e.halt (); / / fermare la propagazione evento se si desidera ...
 
     }, '# Demo');
 
     / / Lavare le interazioni dell'utente primi
     Y.EventBinder.flush ('click');
 
 }); 

In questo esempio, YUI Loader cercherà di caricare le gallery-event-binder ed event moduli on-demand, e una volta che sono entrambi pronti insieme alle loro dipendenze, il codice all'interno della funzione di callback (terzo argomento) verrà eseguito. Durante l'esecuzione, l'ascoltatore è impostato per un elemento con id=demo . Il trucco qui è che, una volta Y.EventBinder.flush('click') viene chiamato, il sistema lavare alcuni degli eventi click che sarebbe successo prima di questo codice di inizializzazione viene eseguito.

La configurazione

Questa tecnica richiede qualche configurazione aggiuntiva, in particolare la definizione di YUI_config come una variabile globale per ottimizzare l'esecuzione YUI. Non preoccupatevi, è molto semplice. Vediamo un esempio in dettaglio:

 
 YUI_config = {
     / / Configurazione standard di YUI_config
     combinano: true,
     Filtro: 'min',
 
     / Configurazione legante / evento inizia da qui
     eventbinder: {
         / / Event handler per memorizzare gli eventi che si desidera rispedizione.
         fn: function (e) {
             var = YUI_config.eventbinder legante,
                 filter = / yui3-evento-legante /,
                 container = (e.target | | e.srcElement),
                 info = {
                     target: contenitore,
                     Tipo: e.type
                 };
 
             / / Cercare un elemento con la classe yui3-event-legante
             while (&& container! filter.test (container.className)) {
                 container = container.parentNode;
             }
 
             se (contenitore) {
                 (Binder.q = binder.q | | []) push (info).;
 
                 / / Evitare che l'azione browser predefinito per questo evento
                 se (e.preventDefault) {
                     e.preventDefault ();
                 }
                 return (e.returnValue = false);
             }
         },
         / / Interfaccia per l'ascolto di eventi specifici
         listenFor: function (tipo) {
             var d = document;
             / / Prima del caricamento della libreria, abbiamo a che fare con le incongruenze del browser
             se (d.addEventListener) {
                 d.addEventListener (tipo, this.fn, false);
             Else {}
                 d.attachEvent ('on' + tipo, this.fn);
             }
 
             restituire questo;
         }
     }
 };
 / / Aggiungere eventi al processo di monitoraggio
 YUI_config.eventbinder.listenFor ('click');

Questo codice dovrebbe essere incluso in cima alla pagina. Sarà solo qualche boccone, una volta minify questo oggetto di configurazione. Mi consiglia di utilizzare un cacheable (esterno) del file per la produzione e anche nella sezione testa tra le pagine. Potete saperne di più YUI_config e le diverse configurazioni che si può giocare con questo oggetto nella documentazione delle API ufficiali .

È possibile modificare questa configurazione secondo le proprie esigenze al meglio, e definire gli eventi che ti interessano pure. Nell'esempio precedente, abbiamo aggiunto 'click' nella lista di sorveglianza (ultima riga). È possibile aggiungere più eventi alla lista monitoraggio usando concatenazioni:

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

Come funziona questa caratteristica?

Una volta (cioè, configurazione YUI_config ) logica viene eseguita, con la chiamata a YUI_config.eventbinder.listenFor , un ascoltatore per un tipo di evento specifico verrà definito. Solo gli eventi che fino bolla sarà controllata come l'ascoltatore sarà definito per il document elemento. Quando un interazione con l'utente e 'colto a questo livello, sarà analizzata, in particolare verificando se l'elemento di destinazione o qualsiasi suo antenato ha classname yui3-event-binder . In tal caso, l'evento verrà aggiunto a una coda e il comportamento predefinito per tale evento sarà impedito. Questa tecnica fornisce un modo semplice per monitorare i tipi specifici di interazione in aree specifiche della pagina.

Quando questo codice viene eseguito, gli ascoltatori per gli eventi del tipo specificato oi tipi vengono aggiunti al document , così quando tali fatti si verificano e bubble up (questo solo gli eventi monitor che bolle), saranno fermati e le informazioni immagazzinate in una coda di elaborazione . Più tardi, nel vostro use() callback quando il inizializzazione è terminata, è sufficiente chiamare Y.EventBinder.flush di rispedire tutti gli eventi click memorizzati come se fossero accaduto proprio in quel momento-per gentile concessione della manifestazione-simulazione modulo.

Facilitare l'on-demand natura di alcune interazioni degli utenti

L'obiettivo principale di questa funzione è quello di aiutare gli sviluppatori a definire la logica di carico base alle interazioni dell'utente.

Ecco un altro esempio legante evento :

 
 YUI ({
   {moduli:
     'My-custom-module': {
       fullpath: '. / my-custom-module.js'
     }
   }
 }). Utilizzare ('gallery-eventi-legante', 'nodo', function (Y) {
 
   / / Imposta un listener per '# demo a' e si basano su 'my-custom-module' 
   / / Per gestire quel particolare evento.
   Y.EventBinder.on ('click', 'my-custom-module', '# demo a');
 
   / / Imposta un listener delegato per tutte le ancore in una lista e si affidano  
   / / Su 'il mio-custom-module' e 'il mio, un altro modulo' per gestire tali eventi particolari
   Y.EventBinder.delegate ('click', ['my-altro-module'], '# mylist', 'li a');
 
 });

Qui usiamo Y.EventBinder.on e Y.EventBinder.delegate definire alcuni ascoltatori. Questo involucro due metodi Y.on e Y.delegate di guidare la logica di carico attraverso l'interazione dell'utente. Questo ci permette di rimandare carico di funzionalità specifiche di una pagina fino a quando l'utente tenta di utilizzare una particolare funzione.

In questo caso, quando un utente fa clic su uno degli elementi, si carica uno o più moduli personalizzati YUI che implementano tutte le funzioni associate a quel particolare scatto. Una volta che tali moduli diventano disponibili (e nuovi ascoltatori sono impostati), il legante lavare l'evento che è stato in attesa durante il processo di caricamento a preservare lo stato dell'azione.

Questa funzione non richiede alcuna configurazione iniziale. Entrambe le caratteristiche Event leganti possono essere utilizzati contemporaneamente per coprire precoci e su richiesta dall'utente interazioni. 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 ({
  modules: {
    '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);
             }
 
            return this;
         }
     }
};
// add events to the monitoring process
YUI_config.eventbinder.listenFor('click');

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

Conclusione:

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.

Condividi ed estendere: Segnalibro con 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">
			 Gennaio
		</option>
		<option value="1">
			 Febbraio
		</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',
    modules: {
        '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 .

E 'così semplice. 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 .

Condividi ed estendere: Segnalibro con 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 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.

ResearchPro Home Screen

Informazioni sul progetto

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.

ResearchPro YUI 3 Slider Usage

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.

Condividi ed estendere: Segnalibro con 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. This is a pretty big deal. 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. Comporre al 1-888-371-8922 (non statunitensi partecipanti, mandatemi una email per un numero locale)
  2. Enter the attendee code 4718 8953#
  3. Partecipa alla sessione di condivisione dello schermo (questa vi verrà chiesto di installare il plugin Adobe Connect se questa è la prima volta ad usarlo)

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 .

Hope to see you there!

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

Pagina successiva »
Ospitato da Yahoo!

Copyright © 2006-2012 Yahoo! Inc. Tutti i diritti riservati. Privacy Policy - Termini di servizio

Powered by WordPress su Yahoo! Web Hosting .