Har du problem med mystiska dubbletter av cookies du skapat på en sajt dyker upp när du förväntar dig att de ska vara unika? Då kanske du gjort samma misstag som jag gjorde – missat att ställa in en path för varje cookie. Detta gäller oavsett om du använder dig av Javascript eller .NET-ramverkets WebBrowser-kontroll för att skapa cookies. Fixen är lyckligtvis mycket simpel.
Jag och Anna brukar använda Mataffären.se för våra veckohandlingar. Tjänsten är bra, men själva webbplatsen är stundtals ohyggligt frustrerande att navigera runt på. Framförallt är den långsam, vilket beror på att den överanvänder och missbrukar funktionerna i MS AJAX – när man exempelvis ändrar antalet för en vara (innan man lagt den i varukorgen) görs ett anrop till servern för att beräkna totalsumman för raden (!). Och inte nog med att den måste vänta på servern för att utföra triviala beräkningar, den skickar samtliga varor i det aktuella sökresultatet (kan vara många) till servern, även om den bara ska behandla en av dem.
Hursomhelst – eftersom sidan har mycket Javascript kopplade till rader i sökresultat och liknande så är den lite av ett lidande för de flesta webbläsare att rendera (särskilt IE6). På kul testade jag att göra vår senaste storhandling i Google Chrome istället för Firefox, och det var en ruskig skillnad! Istället för frustration gick allt faktiskt smidigt. Nästan så att jag glömde bort hur dumt de implementerat sin lösning…
Ett mycket hett tips till alla som använder Mataffären.se alltså.
Den något kryptiska titeln på inlägget kräver en förklaring. Vad jag syftar på är den form av ”streaming” av bildinnehåll som man exempelvis kan se på Google Maps eller Microsoft Live Search, där användaren panorerar runt över en till synes oändligt stor bildyta som visas genom ett ”titthål”. Istället för att låta användaren vänta på att en jättestor bild laddas in så skickar servern några små bitar av bilden, så kallade ”tiles”, i taget. Tilesen skickas allteftersom användaren panorerar, så att det normalt i princip ser ut som om man tittar på en bild som aldrig tar slut. Typiskt smart. Så vill jag också göra. Ett hobbyprojekt är påbörjat.
Som jag ser det är problematiken indelad i ett par olika delar med olika klurighetsgrader. Först och främst måste jag komma på hur jag gör ett titthål (hädanefter kallad ”viewport”) som man kan titta på en yta genom och som stödjer panorering med muspekaren. Detta visade sig vara helt okej enkelt. Grundprincipen är att lägga den stora ytan som man vill panorera över inuti ett element med CSS-attributet overflow: hidden (bland annat). Det betyder att även om ytan är jättestor så syns bara en så stor del som får plats i det yttre elementet. För att kunna panorera krävs även att det yttre elementet, viewporten, har position: relative och att det inre, canvasen, har position: absolute. Sedan kan man använda Javascript för att manipulera canvasens position relativt viewportens. Ganska rättframt.
De mer utmanande tankenötterna börjar rada upp sig när det kommer till att dynamiskt läsa in och visa upp tiles. En webbläsare fungerar så att den börjar ladda in en bildfil så snart som den får veta dess sökväg, exempelvis genom ett src-attribut på en img-tagg eller som värde på ett elements background-image-styleattribut. Detta innebär att bara vi vet URL:en till en given tile så tar webbläsaren hand om den ”streaming” som behövs för att visa upp bilden. Mycket bekvämt.
Låt säga att vi har ett enkelt koordinatsystem där varje tile har unika koordinater. För enkelhetens skull (och det finns ju ingen anledning att inte hålla det enkelt) bestämmer jag att en tile exempelvis kan ha koordinaterna (0, 0). Motsvarande bildfil heter troligen 0-0.jpg och ligger i mappen Images/Tiles. Eftersom strukturen är känd kan klienten själv lista ut URL:en till varje tile, och samtidigt beräkna vilken position den ska ha relativt canvasen. Men hur ska den veta vilka tiles som ska vara synliga vid ett givet tillfälle?
Klienten vet hur stor viewporten är, och kan därför veta hur många tiles den motsvarar. Man skulle kunna tänka sig att först ta reda på vilken tile som är ”i mitten” av viewporten och sedan ladda in ett visst antal tiles relativt denna i både X och Y-led. När användaren sedan panorerar över canvasen så ändras den mittersta tilen, vilket ger en ny bas för beräkning av vilka tiles som ska vara synliga.
Gamla tiles, sådana som inte syns längre, tas bort från dokumentträdet för att det inte ska bli för stort och klumpigt. Eftersom webbläsaren i normalfallet cachar de bilder den laddar in kommer det ändå gå mycket snabbt att visa upp tiles som tidigare tagits bort om användaren skulle panorera tillbaka.
Det finns klara begränsningar som styr vad man kan göra samtidigt som en smidig resonsivitet i GUI:t bibehålls (kom ihåg att användaren kanske panorerar omkring helt godtyckligt, då duger det inte med en massa fördröjningar och lagg). Ett s¥dant exempel är att det faktiskt tar tid att skapa noder i DOM-trädet (vilket är vad man gör när man lägger till en tile). Ju mindre tiles, desto fler ska synas samtidigt vilket betyder fler aktiva noder för varje givet tillfälle. Responsiviteten minskar. Det hela blir en avvägning – vilken är den bästa tilestorleken i förhållande till prestanda och syfte? Detta är bara en av de frågor som jag stött på under mitt experimenterande hittills.
Den approach till problemet som jag skrivit helt kort om här är såklart bara en variant, kanske läroböcker i dynamiska webbapplikationer (finns det sådana?) skulle kalla den naiv. Men det är klart att jag inte kan skriva om alla finesser och knep nu direkt, då blir det ju inget roligt! Detta är ett löpande hobbyprojekt som jag har tänkt lägga en hel del tid på. Jag kommer säkert att skriva mer om olika detaljer framöver. Till sist har jag förhoppningsvis ett schysst resultat att visa, med en grundlig teknisk ”bakom kulisserna”-genomgång som bonus.
Då och då kommer jag (kanske) göra releaser av det jag åstadkommit hittills, och den senaste versionen hittar du alltid på http://koncept.fjeldstad.se. Tycker du att den ser konstig ut så beror det med stor sannolikhet på att den gör det.
Idag satt jag och kodade i godan ro på jobbet, och hade varit mycket nöjd om det inte vore för en liten, halvt nedprioriterad rad på min uppgiftslista:
Webbapplikationen tycks gå långsammare när browsern varit igång länge. Finns det en minnesläcka på klientsidan? Undersök!
Jag ligger bra till tidsmässigt just nu i projektet så jag hade möjlighet att titta närmare på frågan. Det visade sig att minnesläckor i webbläsaren i samband med vissa Javascript/DOM-kopplingar är välkända, och diskuteras bland annat på den här bloggen, i denna CodeProject-artikel och hos Microsoft.
Ett problem tycks vara eventhanterare, och att man alltid bör ”koppla bort” dem då sidan avslutas (vid window-objektets unload-event). Spontant känner jag att detta automatiskt borde hanteras av den funktionalitet som från början kopplar upp eventhanterarna, exempelvis $addHandler om man använder AJAX Library. Kanske är det redan så? Jag tror dock inte det. Jag ska gräva lite djupare i det hela, blir väl till slut kanske tvungen att implementera något i stil med denna lösning för eventhantering.
Sedan får man inte glömma bort alla andra mönster som kan framkalla de här minnesläckorna (som beskrivs mer noggrannt i ovan nämnda artiklar). Ibland, när det känns som att jag tvingas lägga tid på olika hack för att komma runt begränsningar i webbläsaren, önskar jag att hela termen ”webbapplikation” aldrig uppstått…tacka vet jag hederliga hemsidor!