Yahoo! User Interface Blog (YUIBlog)

Mobiele browser cache Limits: Android, iOS, en webOS

Update (12 juli 2010): Terwijl de resultaten beschreven in dit artikel zijn nauwkeurig voor HTML-pagina's, nieuwe tests hebben uitgewezen zeer verschillende cache grenzen voor CSS en JS middelen. De bijgewerkte resultaten zijn beschreven in Mobile Browser Cache Limits, Revisited .

In het begin van 2008, Wayne Shea en Tenni Theurer schreef een YUI blog post op de iPhone Cacheability waarin ze de resultaten van het onderzoek gedeeld in verschillende kenmerken en beperkingen van de cache-Mobile Safari in iPhone OS 1.x. Onder andere dingen, vonden zij dat de afzonderlijke componenten groter is dan 25KB cache niet waren, en dat er een maximale totale cache grootte tussen 475KB en 500KB.

Er is veel veranderd sindsdien. We hebben gezien twee nieuwe grote releases en tal van kleinere releases van het iPhone OS (nu iOS), en diverse andere mobiele apparaten met zeer capabele browsers zijn verschenen op de iPhone uitdaging. Stoyan Stefanov gevonden, eind 2009, dat de iPhone de cache van grenzen was veranderd (helaas, voor het erger). Maar waar doen dingen nu staan? En wat te denken van deze niet-iOS browsers?

Achtergrond

Browsers hebben twee soorten caches dat we bezig met voor de toepassing van deze tests:

• De component cache, of object cache, winkels afzonderlijke bestanden. HTML, CSS, JavaScript, en beelden gaan allemaal in de component cache. Wanneer het een van deze onderdelen nodig heeft, controleert de browser eerst de cache voor het maken van een netwerk te vragen.
• De pagina cache, ook wel bekend als de back / forward cache, slaat een hele pagina en alle onderdelen daarvan, evenals hun huidige status. Wanneer u de achter-of vooruit-knop te gebruiken, zal de browser de pagina te laden van de pagina cache indien mogelijk.

De HTML5 applicatie cache is een ander type cache dat op grote schaal wordt ondersteund door mobiele browsers. Browser makers nu al doen een goede baan van het documenteren van de grenzen van de toepassing cache, dus ik heb niet op in mijn testen. Meer over de toepassing cache later.

Apparaten getest

Ik testte de volgende mobiele browser / platform combinaties:

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

Let op: Met uitzondering van de Mobile Safari op iOS 4.0, testte ik slechts een apparaat in elke categorie. Als er verschillen tussen individuele apparaten of verschillen op basis van geïnstalleerde software buiten het OS, dan zou mijn tests niet gedetecteerd die variaties. Deze bijzondere apparaten werden getest omdat ze degene die ik had toegang tot, niet omdat ik volgens hen belangrijker dan andere apparaten.

Methodologie

Cache testen is vervelend, maar relatief eenvoudig.

Ik schreef een klein Sinatra applicatie ( fork het op GitHub! ) die een respons, bestaande uit een gevraagde aantal van de pseudo-alfanumerieke en witruimte bytes genereert. De reacties kunnen worden bediend zowel gzipped of ongecomprimeerde. De volgende verre toekomst afloop response headers worden gestuurd om ervoor te zorgen dat alle reacties worden cachen beschouwd:

 Cache-Control: max-age = 315360000
 Verloopt: Vrij 1-5-2020 03:47:24 GMT

Meer dan mijn lokale netwerk, heb ik handmatig gedaan de volgende stappen op elk apparaat aan op de component cache test:

1. Laad de cache-test index pagina.
2. Tik op een koppeling naar een onderdeel van een bepaalde grootte, variërend van 5KB tot 20 MB, en wachten tot het laden van af te maken.
3. Tik op de knop Terug.
4. Tik nogmaals op dezelfde link. Let op de vraag of de willekeurige karakters zijn hetzelfde, en of de server console een log entry voor een verzoek, om te bepalen of de component werd opgeslagen in stap 2 prints.
5. Herhalen en aan te passen component maten als nodig is om de maximale grootte van component dat wordt gecached vast te stellen.

Voor het testen van de pagina cache, heb ik uitgevoerd in wezen dezelfde stappen, behalve dat in plaats van tikken op de koppeling weer in stap 4, tikte ik de browser vooruit-knop, waardoor het naar de pagina cache in plaats van de component cache te gebruiken.

Ondersteuning voor ETag en Last-Modified werd bepaald door het instellen van de server naar de juiste te sturen ETag of Last-Modified response headers (in afzonderlijke tests) en de verre toekomst afloop headers weglaten. Vervolgens heb ik onderzocht het verzoek headers ontvangen door de server om te controleren of de browser de verwachte stuurde If-None-Match of If-Modified-Since headers op stap 4.

Resultaten

Ik heb getest met gzip zowel de in-en uitgeschakeld, maar ik vond dat de gzip geen effect op cacheability op elk apparaat had. De ongecomprimeerde component grootte is waar het om gaat in alle gevallen, ongeacht of niet, dat onderdeel is gzipped geserveerd. Als zodanig, alle componenten maten die hier genoemd zijn niet-gecomprimeerde formaten.

Onderstaande tabel illustreert mijn algemene bevindingen.

Android

De Android-browser vertoonde de beste cache gedrag van alle geteste apparaten. Hoewel het lijkt geen limiet te stellen aan de grootte van de afzonderlijke componenten, de totale cachegrootte lijkt te worden beperkt tot ongeveer 2MB, wat betekent dat afzonderlijke componenten effectief worden beperkt tot 2 MB ook.

De pagina cache bleek geen limiet stellen aan de grootte van de afzonderlijke pagina's, gelukkig elke byte caching gooide ik op totdat het beschikbare RAM-geheugen is uitgeput en de browser is gecrasht.

Ik was aangenaam verrast om te ontdekken dat Android component cache van zowel de browser opnieuw opgestart en de macht cycli overleefde, een prestatie die geen enkele van de iOS-apparaten in staat was aan te passen.

Mogelijke valkuil: Een overzicht van Android's WebKit source tree leidt me om te geloven dat de cache grenzen kunnen aanpassen op basis van de hoeveelheid RAM-geheugen en / of flash-geheugen beschikbaar is op het specifieke apparaat waarop het draait. Als dat waar is, kan deze nummers alleen van toepassing op de Nexus One. In feite, als de cache grootte aanpast op basis van ongebruikt geheugen in plaats van totaal geheugen, kan deze nummers alleen van toepassing op mijn Nexus One.

Ik zou vergissen, maar de verschillen in de iOS 4.0 testresultaten op de iPhone 3G en iPhone 4 ondersteunen deze theorie. (Android en Mobile Safari zijn beide WebKit-gebaseerde browsers, zodat ze kunnen dit gedrag gemeen hebben.) Als je bekend bent met de WebKit-source en kan meer licht werpen op deze, neem dan contact op met mij.

iOS

De resultaten varieerden wild over de drie meest recente versies van iOS. Verbazingwekkend, heeft Mobile Safari op iOS 3.1.3 niet in de cache componenten van elke omvang, ondanks het feit dat een schijnbaar ongelimiteerde pagina cache grootte. Dit is verontrustend, omdat het betekent iOS 3.1.3 gebruikers waarschijnlijk een suboptimaal surfervaring krijgt, vooral als ze niet zijn wifi gebruikt. De onbeperkte pagina cachegrootte doet weinig goed hier, want het komt alleen in het spel voor terug / vooruit navigatie. Dit gedrag is een belangrijke verandering van wat anderen waargenomen in eerdere iOS releases en ik kan me niet voorstellen dat geen goede reden voor zijn, dus ik vermoedt dat dit een bug te zijn.

Mobile Safari op iOS 3.2 (die alleen beschikbaar is op de iPad) niet vertonen deze bug. De 25.6KB component te beperken en ~ 281.6KB totaal cache limiet zijn beter dan niets, maar ze lijken nog steeds schamele in vergelijking met de andere geteste apparaten. Uniek onder de iOS-apparaten, de iPad lijkt te beperken van de grootte van pagina's in de pagina cache 25.6KB, net als de samenstellende limiet.

Mobile Safari op iOS 4.0 tentoongesteld verschillende limieten op de iPhone 3G en op de iPhone 4, wat impliceert dat de grenzen aan te passen op basis van beschikbare RAM-geheugen (de iPhone 3G is 256 MB, terwijl de iPhone 4 heeft 512 MB; getest beide apparaten had 32 GB flash-geheugen) . Op de iPhone 3G, iOS 4.0 heeft een 51.199KB component limiet en een ~ 1.05MB totaal component cache grootte.

Op de iPhone 4, het onderdeel limiet was bijna precies twee keer de limiet op de iPhone 3G, op 102.399KB. De totale component cache grootte van ongeveer 1,9 MB. Misschien omdat iOS 3.2 en iOS 4.0 afzonderlijk werden ontwikkeld, maar vertakt vanuit een gemeenschappelijke voorouder, de iOS 4.0 pagina cachegrootte lijkt te worden alleen beperkt door de beschikbare RAM-geheugen op beide apparaten getest, net als iOS 3.1.3.

Geen van de iOS-apparaten behouden van de inhoud van de cache over gedwongen browser opnieuw wordt opgestart of het apparaat stroom cycli, hoewel ze wel de cache te behouden wanneer alleen schakelen applicaties zonder dat het doden van de browser.

webOS

Mijn testresultaten op webOS waren zo inconsequent dat ik weinig vertrouwen in hen hebben. Ik heb begrepen wat weinig gegevens slaagde ik erin om puur te verzamelen voor de volledigheid. Neem het met een flinke korrel zout.

Zo dichtbij als ik was in staat om vast te stellen, zou webOS hebben een individuele component limiet van ongeveer 1 MB, met een bijpassende paginagrootte te beperken in de pagina cache. Ik was niet in staat om coax If-None-Match of If-Modified-Since verzoek headers van webOS, hetgeen impliceert dat het geen ondersteuning biedt voor ETag en Last-Modified .

Op sommige tests bleek dat webOS is een maximale grootte van component was groter dan 1 MB, maar dit was inconsistent. Voor zover ik kan vertellen, webOS lijkt te hebben een vervelende bug waar, na een bepaald punt, eventueel wanneer de maximale totale cache grootte is bereikt, de cache gewoon helemaal niet meer werkt helemaal totdat de telefoon wordt power-gefietst. In sommige gevallen zelfs de macht fietsen niet van de cache breuk vast te stellen, zodat ik uiteindelijk gaf het proberen om de precieze oorzaak van het probleem en de exacte grenzen van het webOS cache vast te stellen.

Aanbevelingen

Op basis van deze resultaten, bied ik de volgende aanbevelingen aan iedereen die het ontwikkelen van web applicaties voor de geteste apparaten:

• Gebruik verre toekomst cache verlopen headers. Dit zal de browser voorkomen dat een voorwaardelijke GET-verzoek te verzenden en zal cacheability verbeteren webOS, die geen ondersteuning biedt voor ETag of Last-Modified .
• Ten minste tot iOS 4.0 komt op de iPad, probeer dan aan de individuele component maten te beperken tot 25.6KB of minder, niet-gecomprimeerde. En drang je iPhone-gebruikers om te upgraden naar iOS 4.0 zo snel mogelijk.
• Als uw website moet ondersteunen iOS 3.1.3 gebruikers (wat zeer waarschijnlijk is), als het nodig onderdelen groter is dan 25.6KB, of als de totale omvang van al je componenten groter is dan 281.6KB, overweeg dan het gebruik van de HTML5 applicatie cache, localStorage , of opslag in een databank om uw componenten op te slaan. Recente YUI alex Kessinger's Blog post, An Introduction to gebruik van YUI 3 in offline toepassingen , wellicht van belang zijn voor YUI drie ontwikkelaars overweegt deze aanpak.
• Doe je eigen onderzoek. Ga er niet vanuit dat deze resultaten van toepassing op alle toekomstige versie van een van de geteste browsers of apparaten. Gebruik deze resultaten als uitgangspunt, maar controleren ze zelf voordat je belangrijke beslissingen gebaseerd op aannames over mobiele cache beperkingen. De mobiele browser wereld verandert in een bliksem tempo, zodat dit onderzoek zal een zeer korte houdbaarheid.

Ik heb gemaakt mijn test code beschikbaar op GitHub en ik moedig u aan om het te gebruiken, het vork, en wat je leert delen.

Bel voor Documentatie

Browser makers, overweeg dan documenteren en publiceren van uw browser cache van grenzen. In de desktop wereld waar deze limieten zijn meestal zo hoog als voor een non-issue te zijn, was de documentatie niet nodig. In de mobiele wereld, browser cache grenzen zijn vitale informatie die webontwikkelaars moet hebben om performante websites te maken met de aantrekkelijke mogelijkheden.

De grenzen van de nieuwe functies, zoals localStorage en de toepassing cache zijn meestal goed gedocumenteerd. Gelieve uit te breiden dit niveau van documentatie om het onderdeel cache ook.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!

In de Wild voor 25 juni 2010

Zoals altijd, laat het ons weten in de commentaren of @ yuilibrary als we iets gemist belangrijk.

• YUI 3-based UI Alloy Formeel Aangekondigd op Liferay Conference : Vanaf het persbericht : "Als onderdeel van deze inspanning, ook Liferay de onmiddellijke beschikbaarheid van de aangekondigde Liferay Alloy UI . Ontwikkeld in samenwerking met Yahoo's YUI-project, Lichtmetalen gebruikersinterface biedt een reeks van rijke user interface componenten voor het snel bouwen van user-friendly portlets, widgets, en web applicaties. Legering UI gaat over de complexiteit van CSS, HTML en Javascript, het vrijmaken ontwikkelaars om zich te concentreren op de business requirements en functionaliteit. Legering UI helpt ook oplossen van een aantal gemeenschappelijke cross-browser compatibiliteit problemen die typisch verbruiken project resources. De nieuwe bibliotheek is niet nodig een portal en kan worden gebruikt om componenten voor iedere web applicatie te ontwikkelen. Liferay Portal zal zijn front-end kader rond Alloy UI te standaardiseren, het uitbreiden van de eenvoud en de mogelijkheden van moderne portal-gebaseerde enterprise oplossingen. "Alloy UI is een nieuwe mogelijkheid voor web-ontwikkelaars om de ontwikkeling van rijke gebruikersinterfaces te vereenvoudigen, 'zei Brian Chan, Liferay portal schepper en Chief Software Architect. 'We zijn blij te hebben gewerkt aan dit met de Yahoo-team en het zal een grote aanwinst voor ontwikkelaars te helpen met hun oplossingen te voelen. "' Alle Alloy UI-componenten zijn nu vrij beschikbaar voor de YUI gemeenschap in de YUI 3 Gallery .
• AutoFusion's CarPrices.com lanceert Met behulp van YUI 3.1.1 : YUI 3 Gallery medewerker Josh Lizarraga heeft gewerkt met Autofusion Inc op de nieuwe CarPrices.com project , gebouwd met behulp van een gastheer van YUI 3.1.1 hulpprogramma's en widgets. Josh zal meer over dit project in de toekomst een YUIBlog post.
  
• Download Squad's Erez Zukerman adviseert JS Devs to Crockford kijken op YUI Theater : Schrijft Erez: " Douglas Crockford is een genie. Serieus - de man is briljant. Hij is op dit moment dienst doet als Yahoo! 's chief JavaScript architect, vond hij JSON (een veel gebruikte data interchange format), hij is een deel van de ECMAScript commissie (de jongens het instellen van de JavaScript-standaard) en heeft een zeer brede kennis van de algemene geschiedenis van het programmeren talen en informatica. Onlangs Crockford gaf vijf praat over JavaScript, als onderdeel van Yahoo! 's YUI Theater . Dit zijn allemaal gratis beschikbaar, en ze zijn meer dan vijf uur lang (meer als zes tot zeven uur in totaal, denk ik). Wat is er zo cool aan deze gesprekken is dat Crockford echt geeft u een overzicht in vogelvlucht van het onderwerp, het eerste uur is gewoon geschiedenis, en het is echt fascinerend. Het is all over the place, te beginnen met de Jackquad weefgetouw , door middel van Daarom hebben we zowel een wissen en een Backspace-toets op ons toetsenbord, de hele weg naar moderne programmeertalen en JavaScript. "Voor meer van favoriete JavaScript Erez middelen, check out zijn post , of over het hoofd naar de Crockford op JavaScript-pagina voor de nieuwste video's Douglas's (met veel meer het vullen van de tweede kolom van YUI Theater ).
  
• Proficiat aan Matt Snider & Friends op YUI 2-based Mint.com, Winnaars van een Webby 2010 : Felicitaties voor Matt Snider . en de andere openstaande frontend engineers van Mint.com voor hun welverdiende 2010 Webby Award in de Financial Services categorie Mint is YUI 2-based sinds het begin , en Matt nog steeds een grote bijdrage levert aan de YUI project . U kunt zien dat Matt's vijf-woord dankwoord over op YouTube .
  
• Ajaxian's Dion Almaer Reviews Caridy Patiño Mayea's Preload Gallery Module voor YUI 3 : Dion heeft een leuke functie op Ajaxian herziening van Preload module Caridy Patiño Mayea voor prefetching en caching activa , een YUI 3 Gallery item dat hij schreef over onlangs op YUIBlog .
  
• Het gebruik van YUI Grids met Movable Type (door @ foxxtrot) : YUI medewerker Jeff Craig schreef over zijn ervaringen omzetten van een Movable Type blog om YUI 2 Grids: "Zo, zoals iedereen die ooit voor lezen mijn blog, zul je dat zien in het weekend Ik deed een upgrade mijn blog template te YUI grids en YUI3 te gebruiken voor de JavaScript. Door over te schakelen weg van de MT-templates (of, de sjablonen die werden standaard, toen ik de eerste versies van MTD 4 geïnstalleerd), was ik in staat om de HTML pageweight verminderen verdomme in de buurt van de helft. De oude templates waren echt div-zwaar, en had een ton extra markup. Meestal is het besluit gedreven door een verlangen om de visuele gevoel van mijn blog opnieuw, en ik voelde dat ik net zo goed herschrijven onder YUI grids, terwijl ik het doen. "
• Nate Schutta Vergelijkt YUI en Dojo voor IBM DevelperWorks : Nate Schutta schrijven voor IBM developerWorks vergelijkt YUI 2.x en Dojo in een nieuwe functie. Terwijl we meer gericht op de YUI 3.x codeline deze dag, Nate's artikel heeft een aantal nuttige richtlijnen voor degenen die het denken over JavaScript libraries en het maken van een beslissing voor hun bedrijf of project. Eerste - waarom YUI of Dojo?

  Met zo veel uitstekende keuzes tot je beschikking, waarom zou u overwegen YUI of Dojo? In een woord: volledigheid. In tegenstelling tot andere oplossingen die extra bibliotheken of plug-ins te betrekken, Dojo en YUI hebt alles (en meer) dat de huidige front-end engineer zou willen. Terwijl dat is zowel een zegen als een vloek, als je in de markt voor een one-stop shop voor uw Ajax nodig heeft, zijn dit twee krachtige kanshebbers. Naast een schat van JavaScript helpers en hulpprogramma's, bieden beide top-notch widgets en controle-veel verder dan het beperkte palet van de standaard browser.

  Nate's advies over de algemene bibliotheek selectiecriteria is nuttig:

  • Wat wil je eruit? Bent u op zoek naar een volledige vervanging van bijna alle UI-elementen op uw pagina, of bent u gewoon op zoek naar iets om een ​​beetje van de pijn uit van JavaScript-programma's te nemen?
  • Hoe gemakkelijk is de code om te lezen? Ondanks de enorme verbeteringen in de documentatie van de afgelopen jaren, is de kans groot dat u moet in de code te graven op een bepaald punt. Alvorens zich te verbinden tot een bibliotheek, wat tijd doorbrengen knieën in de bron. Is het makkelijk te begrijpen, of is zelfs de oorspronkelijke auteur hebben moeite met het?
  • Hoe goed is de documentatie? Schoon en leesbare code kan maken voor minder-dan-stellaire documenten, maar niets helpt u aan de slag heel graag tutorials en voorbeelden. Poke rond de wiki of de website, en kijk wat ze te bieden hebben. Zijn de voorbeelden duidelijk en gemakkelijk te volgen? Heeft een snelle Google-zoekopdracht brengt u naar het juiste deel van hun materiaal?
  • Wat is de gemeenschap zoals die rond de bibliotheek? Bekijk de mailing-lijsten. Is er veel verkeer? Zijn nieuwe mensen die behandeld worden met respect of spot? Is de code is onlangs bijgewerkt, of was de laatste release een aantal jaren geleden?
  • Kunt u hulp krijgen? Hoewel dit is gerelateerd aan de vorige stukjes over de gemeenschap, het is altijd waardevol om rond te kijken voor de ontwikkeling gemeenschap en wie wat met behulp van zien. Check out de job boards om een ​​gevoel van die bibliotheken worden opduiken vaak op hervat te krijgen.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!

YUI: Openingstijden vrijdag 25 juni

De laatste aflevering van YUI: Openingstijden zullen deze vrijdag, 25 juni.

Vorige week, Eduardo Lundgren stelde ons voor aan enkele van de grote AlloyUI modules onlangs toegevoegd aan de Gallery. De discussie overdekte instantiatie, configuratie, ontwikkeling beslissingen en een stukje geschiedenis van hun TreeView module. Maar dat was slechts het begin. We hebben ook onderzocht hun IO , Node , en de vorm validatie modules en verbleef enige tijd op een aantal van de visuele stijlen beschikbaar. Eduardo zelfs gaf ons een sneak preview van de nieuwe Liferay, Inc portaal, aangedreven door al dit harde werk. Echt top notch te werken.

Dat gezegd hebbende, is het moeilijk te zeggen of de show-and-vertellen of het gesprek was de echte headliner. Grote code gerelateerde opzij content, er was heel veel goede feedback en discussie over de communautaire samenwerking, de aard van de Gallery, en hoe we kunnen maken en YUI beter. Dus een grote dank aan iedereen op de oproep!

Deze week gaan we een beetje liefhebberen in zowel de ruwe ontwikkelaar wereld en als de ontwerper ter wereld. Caridy Patiño is terug met ons te praten over zijn Event Binder module die hier werd gekenmerkt juist vanmorgen . We doen een code review en bespreken de configuratie stap die gedaan moet worden voordat YUI is zelfs geladen. Dat klopt: pure, onversneden DOM scripting. Wilt u misschien een helm te dragen.

Dan zullen we gaan naar het al even genuanceerde huid ontwerpproces met Jeff Conniff, de yahoo die verantwoordelijk is voor de huidige verscheidenheid van de Slider look-and-voelt. Hij zal wandeling ons door zijn proces van het bouwen van de visuele elementen en laten zien hoe je kunt dezelfde PSD te nemen en eenvoudig kleur thema activa die passen in uw site palet. Hier zijn de Photoshop bestanden als je wilt om mee te spelen. Ik zal ook spreken over een aantal van de besluiten die in de bouw van de CSS en de DOM-structuur van de Slider.

We zijn weer terug op de gebruikelijke dag en tijd van deze week: vrijdag van 10u tot 12u PDT. Er is een nieuwe deelnemer code voor de conference call, maar verder, de verbinding details zijn hetzelfde als altijd.

1. Inbellen op 1-888-371-8922 (niet-Amerikaanse deelnemers, me e-mail voor een lokaal nummer)
2. Geef de deelnemer code 47188953 #
3. Word lid van de delen van het scherm sessie (dit wordt u gevraagd de Adobe Connect-plugin te installeren als dit je eerste keer gebruiken)

Ik heb ook een forum thread voor deze Openingsuren zodat we de discussie vroeg beginnen!

Ook, zoals altijd, kunt u de hoogte te houden met de komende planning en onderwerpen die datum door het volgen van @ yuilibrary op Twitter of een abonnement op de YUI Evenementenkalender .

Hoop je daar te zien!

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!

In de YUI 3 Gallery: Caridy Patiño Mayea Event van Binder Module biedt ondersteuning voor Early Binding Event en Event-driven module wordt geladen

Dit artikel introduceert mijn Event Binder module , onlangs in de YUI 3 Gallery.

YUI 3 is het krijgen van goede tractie in de gemeenschap van ontwikkelaars, met aanzienlijke goedkeuring van de nieuwste 3.1.1 versie en een enorme infusie van nieuwe, innovatieve projecten in de YUI 3 Gallery . Veel ontwikkelaars krijgen hun hoofd rond de on-demand aard van YUI 3 en begint te benutten die mogelijkheden in hun ontwerpen. Deze aanpak heeft grote voordelen, maar het kan ook aanwezig zijn een aantal uitdagingen.

Een van die uitdagingen is om vroeg te vangen gebruiker interacties. Zelfs als de browser wordt gestart waardoor de pagina, we willen dat de gebruiker in staat om te beginnen met de interactie met pagina-elementen. In veel gevallen kan die interacties gebeuren voordat de JavaScript-initialisatie proces (inclusief het aanbrengen van event listeners) is voltooid.

In veel gevallen kunt u stroomlijnen initialisatie code door het instellen van alleen uw evenement luisteraars en vervolgens het toevoegen van de logica voor het laden van de stukken die je nodig hebt voor elke interactie met de gebruiker. Onlangs, ingenieurs bij Facebook gesproken over een soortgelijke aanpak van de laad-proces te verbeteren - zie het interview van Rey Bango op JSConf. Hier is een voorbeeld van hoe deze techniek zou kunnen werken 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 & 3.1.1/build/event-custom/event-custom-base-min.js &
	 3.1.1/build/event/event-base-min.js & 3.1.1/build/dom/dom-base-min.js &
	 3.1.1/build/dom/selector-native-min.js & 3.1.1/build/dom/selector-css2-min.js &
	 3.1.1/build/node/node-base-min.js "> </ script>
 
 YUI (). Gebruik ('event-base', function (Y) {
     / / Totdat de gebruiker zich te wachten op een input element om het laden van activa start
     Y.on ("klik", function (e) {
 
       Y.use ('Anim', 'io', function () {
           / / Laad een remote content en weergeven met behulp van een animatie hier
       });
 
       e.halt (); / / stop de verspreiding
     }, "# Demo");
 }); 

Dit introduceert een aantal complexiteit in de code, omdat luisteraars niet alleen te maken met de interactie van de gebruiker, maar ook met een aantal laad-logica. Een ander nadeel van deze aanpak is dat je nog steeds een aantal JavaScript-code laden aan de bovenkant (in dit geval YUI zaad, de Event Utility, en een aantal afhankelijkheden) om ten minste de luisteraar en de laad-logica te vroeg acties te vangen definiëren. Dus, laten we dit beschouwen als twee aparte use-cases:

• Het vastleggen van vroege gebruikers interactie
• Het vergemakkelijken van de on-demand aard van sommige gebruikers interactie

Om tegemoet te komen aan deze behoeften die ik heb gemaakt een nieuwe module voor YUI 3 . Mijn belangrijkste focus is om een ​​onderdeel dat werkt zonder gevolgen heeft voor uw applicatie logica te creëren. Deze nieuwe module heet " galerij-event-bindmiddel "en is nu beschikbaar via de YUI Loader.

Het vastleggen van vroege gebruikers interactie

Het belangrijkste doel van deze functie is om te garanderen dat de gebruiker interacties rij totdat gebeurtenislisteners worden geïnitialiseerd is.

Laten we eens kijken een evenement bindmiddel voorbeeld :

  YUI ({
     / / Laatste Gallery Bouw van deze module
     gallery: 'gallery-2010.06.07-17-52'
 }). Gebruik ('gallery-event-bindmiddel', 'event', function (Y) {
 
     Y.on ('click', function (e) {
 
         / / Hier doen je spullen
         e.halt (); / / stop het evenement propagatie als je wilt ...
 
     }, '# Demo');
 
     / / Spoelen begin van de gebruiker interactie
     Y.EventBinder.flush ('klik');
 
 }); 

In dit voorbeeld, YUI Loader zal proberen om de belasting gallery-event-binder en event modules on-demand, en zodra ze allebei klaar zijn met hun afhankelijkheden, wordt de code binnen de callback functie (derde argument) worden uitgevoerd. Tijdens de uitvoering, is een luisteraar voor een element met id=demo . De truc hier is dat zodra Y.EventBinder.flush('click') wordt aangeroepen, zal het systeem spoelen enkele van de gebeurtenissen die klik er gebeurd zou zijn voordat deze initialisatie code wordt uitgevoerd.

De configuratie

Deze techniek vereist enige extra configuratie, met name de definitie van YUI_config als een globale variabele van de YUI uitvoering tweak. Maak je geen zorgen, het is heel simpel. Laten we een voorbeeld in de details te zien:

 
 YUI_config = {
     / / Standaard configuratie YUI_config
     combineren: true,
     filter: 'min',
 
     / / Event bindmiddel configuratie begint hier
     eventbinder: {
         / / Event handler op gebeurtenissen die u wilt terugzending op te slaan.
         fn: function (e) {
             var bindmiddel = YUI_config.eventbinder,
                 filter = / yui3-event-binder /,
                 container = (e.target | | e.srcElement),
                 info = {
                     doel: container,
                     type: e.type
                 };
 
             / / Zoeken naar een element met de class yui3-event-bindmiddel
             while (container & &! filter.test (container.className)) {
                 container = container.parentNode;
             }
 
             if (container) {
                 (Binder.q = binder.q | | []) push (info).;
 
                 / / Voorkomen dat de standaard browser actie voor dit evenement
                 if (e.preventDefault) {
                     e.preventDefault ();
                 }
                 return (e.returnValue = false);
             }
         },
         / /-Interface om te luisteren voor specifieke evenementen
         listenFor: functie (type) {
             var d = document;
             / / Voor de bibliotheek wordt geladen, hebben we te maken met de browser inconsistenties
             if (d.addEventListener) {
                 d.addEventListener (type, this.fn, false);
             } Else {
                 d.attachEvent ('op' + type, this.fn);
             }
 
             retourneren;
         }
     }
 };
 / / Gebeurtenissen toevoegen aan het proces van toezicht
 YUI_config.eventbinder.listenFor ('klik');

Deze code moet worden opgenomen op de top van de pagina. Het zal slechts een paar happen zodra je minify deze configuratie object. Ik raad het gebruik van een cachen (externe) bestand voor de productie en de integratie ervan in het hoofd sectie van uw pagina's. U kunt meer lezen over YUI_config en de verschillende configuraties die u kunt door dit object tweak in de officiële API-documentatie .

U kunt deze configuratie het best bij u past, en definiëren gebeurtenissen die u de zorg over ook. In het bovenstaande voorbeeld, voegden we 'klik' aan het toezicht op lijst (laatste regel). U kunt meerdere events aan het toezicht op lijst met behulp van chaining:

  . YUI_config.eventbinder.listenFor ('klik') listenFor ("keyUp") listenFor ('mouseover').; 

Hoe werkt deze functie?

Zodra de configuratie (dat wil zeggen, YUI_config ) logica wordt uitgevoerd, samen met de oproep om YUI_config.eventbinder.listenFor , een listener voor een specifiek evenement type zal worden gedefinieerd. Alleen gebeurtenissen die bubble up zal worden gevolgd als de luisteraar zullen worden gedefinieerd voor het document element. Wanneer een gebruiker interactie is gevangen op dit niveau, zal het worden geanalyseerd, met name controleren of het doel element of een van de voorouders heeft classname yui3-event-binder . Als dat zo is, zal het evenement worden toegevoegd aan een wachtrij en het standaard gedrag voor dat evenement zal worden voorkomen. Deze techniek biedt een eenvoudige manier om specifieke soorten van interactie in specifieke gebieden van de pagina te controleren.

Wanneer deze code wordt uitgevoerd, zijn luisteraars voor evenementen van het opgegeven type of de types toegevoegd aan het document , dus als deze gebeurtenissen plaatsvinden en borrelen (dit alleen monitoren gebeurtenissen die bubbel), ze zullen worden tegengehouden en hun informatie is opgeslagen in een verwerking van wachtrij . Later, in het use() callback als je initialisatie is voltooid, kunt u bellen Y.EventBinder.flush om alle opgeslagen klikgebeurtenissen wederverzending alsof ze net gebeurd toen-met dank aan de event-simuleren module.

Het vergemakkelijken van de on-demand aard van sommige gebruikers interactie

Het belangrijkste doel van deze functie is om ontwikkelaars te helpen bij het laden van de logica op basis van gebruiker interactie te definiëren.

Hier is een evenement bindmiddel voorbeeld :

 
 YUI ({
   modules: {
     'Mijn-custom-module': {
       fullpath: '. / my-custom-module.js'
     }
   }
 }). Gebruik ('gallery-event-bindmiddel', 'node', function (Y) {
 
   / / Set een listener voor '# demo een' en vertrouwen op 'mijn-custom-module' 
   / / Die bepaalde gebeurtenis af te handelen.
   Y.EventBinder.on ('click', 'my-custom-module', '# demo een');
 
   / / Set een afgevaardigde listener voor alle ankers in een lijst en vertrouwen  
   / / Op 'mijn-custom-module' en 'mijn-andere-module' te hanteren die bepaalde gebeurtenissen
   Y.EventBinder.delegate ('klik', ['my-andere-module'], '# mylist', 'li a');
 
 });

Hier gebruiken we Y.EventBinder.on en Y.EventBinder.delegate om enkele luisteraars te definiëren. Deze twee methoden wrap Y.on en Y.delegate voor het laden logica rijden door een interactie met de gebruiker. Dit laat ons uitstellen laden van specifieke functionaliteit op een pagina totdat de gebruiker probeert het gebruik van een bepaalde functie.

In dit geval, wanneer een gebruiker klikt op een van de elementen, laden we een of meer aangepaste YUI modules die alle functies die samenhangen met die specifieke klik implementeren. Zodra deze modules beschikbaar (en nieuwe luisteraars zijn ingesteld), zal het bindmiddel flush het geval dat in de wacht was tijdens het laden om de toestand van de actie te behouden.

Deze functie vereist geen initiële configuratie. Beide Event Binder de functies kan worden gebruikt op hetzelfde moment te vroeg en on-demand user-interactie te dekken. In dit geval moet u de configuratie te definiëren, en stel vervolgens de on-demand luisteraars, en tot slot spoel het begin van de gebeurtenissen.

Hier is een end-to-end event bindmiddel voorbeeld :

 
 / / Configuratie
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.

Conclusie:

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.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!

Using the YUI 3 Calendar Date Selector from Alloy

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">
			January
		</option>
		<option value="1">
			 Februari
		</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 .

It's as simple as that. 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 .

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!

Implementation Focus: YUI 3 Powering Autofusion's ResearchPro

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.

Over het project

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.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!

YUI: Open Hours, Wed June 16th

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. Dial in to 1-888-371-8922 (non-US participants, email me for a local number)
2. Enter the attendee code 4718 8953#
3. Word lid van de delen van het scherm sessie (dit wordt u gevraagd de Adobe Connect-plugin te installeren als dit je eerste keer gebruiken)

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 .

Hoop je daar te zien!

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!