Avancerad webbteknologi i mobila webbläsare

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Advanced Web Technology In Mobile Browsers

av

Linus Björk

LIU-IDA/LITH-EX-A--11/006--SE

2011-02-21

Linköpings universitet SE-581 83 Linköping, Sweden

Linköpings universitet 581 83 Linköping

Linköpings universitet Institutionen för datavetenskap

Examensarbete

AVANCERAD WEBBTEKNOLOGI I

MOBILA WEBBLÄSARE

av

Linus Björk

LIU-IDA/LITH-EX-A--11/006--SE

2011-01-21

Handledare: Henrik Petterson, Visiarc AB

S

AMMANFATTNING

Utvecklingen p˚a webben g˚ar snabbt fram˚at och webbapplikationerna blir bara mer avan-cerade. Samtidigt s˚a har de mobila webbl¨asarna utvecklats i en snabb takt. Dock skiljer det fortfarande mycket mellan en mobil webbl¨asare och en vanlig webbl¨asare, samt att man integrerar med en mobiltelefon p˚a ett annat s¨att ¨an vad man g¨or med en dator. Det-ta examensarbete unders¨oker om det ¨ar m¨ojligt att skapa avancerade webbapplikationer som, genom att utnyttja de senaste webbteknologierna, kan ers¨atta vanliga mobilappli-kationer.

Unders¨okningen genomf¨ors genom att skapa en l¨attviktsvariant av en telefonapplikation, Mobile Documents till Symbian S60, som ¨ar en applikation som hanterar dokument, mejl och bilagor. Utvecklingen sker till st¨orsta del i Google Web Toolkit och tekniker s˚a som AJAX och Comet anv¨ands. Eftersom antalet olika sorters telefoner med trycksk¨arm ¨ar v¨aldigt stort s˚a kommer unders¨okningen att rikta sig mot ett f˚atal telefoner som k¨or webbl¨asarna Mobile Safari, microB och Android Browser.

Slutsatserna av rapporten ¨ar att JavaScript-st¨odet hos dagens webbl¨asare ¨ar stort nog till att k¨ora avancerade webbapplikationer. Dock skiljer det mycket webbl¨asarna emellan och det st¨orsta problemet ¨ar att skapa sig ett v¨alfungerande anv¨andargr¨anssnitt som fungerar lika bra p˚a alla telefoner och med alla de olika interaktionsm¨ojligheter som finns i en mobiltelefon.

A

BSTRACT

The web develops fast and web applications are getting more advanced. At the same time the mobile browsers develop at a rapid pace. However, it still differs a lot between a mobile browser and a standard web browser. You also interact with a mobile phone in a different way than what you do with a computer. This thesis examines whether it is possible to create advanced web applications that by utilizing the latest web technologies can replace ordinary mobile applications.

The investigation is done by creating a lightweight version of a phone application, Mobile Documents on Symbian S60, which is an application that manages documents, emails and attachments. The development is done in Google Web Toolkit and technologies such as AJAX and Comet are both used. As the number of different types of phones with touch screens is very large the investigation only will target a small number of phones running web browsers as Mobile Safari, microB and Android Browser.

The conclusion of this report is that the JavaScript support of today’s browsers is enough to run advanced web applications. However, it differs a lot between browsers and the main problem is to create a functional user interface that works equally well on all phones and with all the different interaction possibilities that a mobile phone gives.

F ¨

ORORD

Denna rapport ¨ar resultatet av ett examensarbete (30 hp) som utf¨orts i samarbete med Visiarc AB under v˚aren 2010. Denna rapport avslutar min utbildning till civilingenj¨or i Datateknik vid Link¨opings tekniska h¨ogskola och ¨ar examinerad vid institutionen f¨or Datavetenskap (IDA) av Simin Nadjm-Tehrani.

Linus Bj¨ork

I

NNEH

ALL

˚

Kapitel 1 – Inledning 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 2 1.3 Direktiv . . . 3 1.4 Problemformulering . . . 4 1.5 Avgr¨ansningar . . . 4 1.6 Utrustning . . . 5 1.7 Rapportens struktur . . . 6 Kapitel 2 – Bakgrundsbeskrivning 7 2.1 Standarder och programmeringsspr˚ak . . . 7

2.1.1 Hyper Text Markup Language . . . 7

2.1.2 Document Object Model . . . 8

2.1.3 Cascading Style Sheets . . . 8

2.1.4 Cookies . . . 8

2.1.5 JavaScript . . . 8

2.1.6 Asynchronous JavaScript and XML . . . 10

2.1.7 Comet . . . 11

Kapitel 3 – Unders¨okning 13 3.1 Optimeringsm¨ojligheter . . . 13

3.1.1 Optimering av bandbredd . . . 13

3.1.2 Optimering av processortid . . . 16

3.2 Olika renderingsmotorer . . . 20

3.3 Begr¨ansningar . . . 20

3.4 Anv¨andargr¨ansnitt . . . 22

3.4.1 Viewport . . . 22 3.4.2 Interaktion . . . 25 3.5 Pekdon . . . 26 3.5.1 Touch-event . . . 26 3.5.2 Egna tester . . . 26 3.6 Proxy-servrar . . . 26

3.6.1 Webbl¨asarspecifika proxyservrar . . . 27

3.7 Installationsskript . . . 27

3.7.1 iPhone och iPod . . . 27

3.7.2 Widgets . . . 28 3.7.3 Mobilapplikation . . . 28 Kapitel 4 – Utveckling 29 4.1 Utvecklingsmilj¨o . . . 29 4.2 Arkitektur . . . 30 4.3 Serverkommunikation . . . 33

4.3.1 Val av Comet bibliotek . . . 33

4.3.2 Protokoll . . . 34

4.3.3 Kommunikationsanrop . . . 37

4.3.4 Uppdatering av listvy . . . 37

4.4 Cache . . . 38

4.5 Inloggning . . . 39

4.6 Anv¨andargr¨anssnitt . . . 40

4.6.1 Fixerad ”header” . . . 41

4.6.2 Stilmallar . . . 43

4.6.3 Knappar . . . 43

4.6.4 Text- och l¨osenordsboxar . . . 44

4.6.5 Inmatning av PIN-kod . . . 46

4.6.6 Skalning av bilder p˚a Android . . . 46

4.6.7 F¨orkortning av textstr¨angar . . . 47

4.6.8 Navigering med fysiska knappar . . . 47

4.6.9 Popupmeny . . . 48 4.6.10 Uppdatering av bilder . . . 49 4.7 Komprimering . . . 49 4.8 Installationsskript . . . 49 Kapitel 5 – Resultat 51 5.1 Tester . . . 51 5.1.1 Inloggning . . . 52 5.1.2 Dokumentvisning . . . 53 5.1.3 Mejlhantering . . . 54 5.1.4 Automatisk uppdatering . . . 55 5.1.5 Ovriga telefoner . . . .¨ 56 vii

5.2 Datam¨angd mellan klient och server . . . 57

5.3 Installationsskript . . . 58

Kapitel 6 – Slutsats och diskussion 59 6.1 Slutsats . . . 59 6.2 Diskussion . . . 60 6.2.1 Gr¨anssnitt . . . 61 6.2.2 JavaScript-st¨od . . . 61 6.2.3 Asynkrona anrop . . . 62 6.2.4 Utveckling . . . 62 6.2.5 Framtid f¨or applikationen . . . 62 viii

F

IGURF

ORTECKNING

¨

1.1 Illustration p˚a hur Mobile Documents fungerar . . . 2

2.1 Diagram som visar hur olika snabbt JavaScript exekveras p˚a olika plattformar och webbl¨asare. (Datan ¨ar h¨amtad fr˚an NS Basic Corporation [1]) * f¨or Mac Pro s˚a specificeras inte vilken version av Internet Explorer som k¨ors. 9 2.2 Illustration p˚a hur AJAX fungerar. [2] . . . 11

2.3 Renh˚allningsprodukt fr˚an Ajax respektive Comet . . . 11

2.4 Illustration p˚a hur Comet fungerar till skillnad fr˚an AJAX [3] . . . 12

3.1 Bilder skapade helt i CSS, tagna ur sk¨armdump d˚a de visas i webbl¨asaren Safari 4.0.5 [4] . . . 15

3.2 Illustration p˚a hur bilderna blir oskarpa vid touch-event. T.v. utan touchevent och t.h. med touchevent. Sk¨armdumparna ¨ar fr˚an test p˚a en Motorola Droid som har en h¨ogdensitetssk¨arm. . . 23

3.3 Illustration p˚a storleken p˚a iPhones webbvy [5] . . . 24

4.1 Arkitektur . . . 31

4.2 Schema ¨over Node-klassen och dess subklasser . . . 32

4.3 Skiss. . . 40 ix

4.4 Sk¨armdump som visar hur zoom-knappar upptr¨ader i Android. . . 41

4.5 Olika s¨att att h˚alla en telefon om man utf¨or operationer med h¨oger hand. . . . 42

4.6 Sk¨armdump p˚a hur button-elementet fr˚an Nokias stilmallar visas p˚a Maemo . 43 4.7 De fysiska navigationsknapparna hos Motorola Droid(t.v) och Nexus One(t.h) 44 4.8 Sk¨armdump som visar hur markering upptr¨ader vid navigation med fysiska knappar. till h¨oger button-element som ligger ¨over hela ytan, till v¨anster anchor-element som omringar ytan . . . 48

4.9 Sk¨armdump p˚a popupmenyn . . . 48

5.1 Sk¨armdumpar fr˚an tester . . . 53

5.2 Sk¨armdumpar fr˚an tester . . . 54

5.3 Sk¨armdumpar fr˚an tester . . . 56

A

KRONYMER

AJAX Asynchronous JavaScript and XML

GWT Google Web Toolkit

HTML Hyper Text Markup Language

HTTP HyperText Transfer Protocol

CSS Cascading Style Sheets

DOM Document Object Model

GIF Graphics Interchange Format

Gzip GNU Zip

RPC Remote procedure call

XML Extensible Markup Language

JSON JavaScript Object Notation

PIN Personal identification number

IMEI International Mobile Equipment Identity

URI Uniform Resource Identifier

W3C World Wide Web Consortium

UI User Interface

K

APITEL

1

Inledning

1.1

Bakgrund

Visiarc utvecklar en tj¨anst som heter Mobile Documents. Kortfattat s˚a ¨ar detta en mejl och dokumentl¨osning f¨or mobiltelefoner, d¨ar all data lagras p˚a en extern server och sedan str¨ommas till mobiltelefonen n¨ar anv¨andaren vill bl¨addra eller titta i dokument eller bilagor (se figur 1.1).

F¨or att anv¨anda sig av Mobile Documents p˚a sin mobiltelefon s˚a m˚aste man installera en applikation p˚a denna. I dagsl¨aget har Visiarc en mobilapplikation som fungerar p˚a telefoner med Nokias operativsystem Symbian/S60. St¨od f¨or andra telefoner ¨ar planerade.

Man kan ¨aven komma ˚at Mobile Documents fr˚an en PC via en modern webbl¨asare. Dock finns det inte st¨od ¨annu f¨or att l¨asa och skicka mejl via hemsidan. Mobile Documents hemsida anv¨ander i stor utstr¨ackning en teknik som kallas AJAX (Asynchronous Java-Script And XML). Denna teknik st¨ods idag av alla de moderna fullskaliga webbl¨asarna. Dock s˚a ¨ar inte st¨odet lika stort i de mobila webbl¨asarna.

F¨or att man ska kunna komma ˚at Mobile Documents fr˚an en telefon som inte ¨ar baserad p˚a Symbian/S60 s˚a ¨ar det v¨aldigt intressant att utveckla en webbapplikation f¨or mobil-telefoner som klarar av de viktigaste funktionerna i Mobile Documents och kan k¨oras p˚a de vanligaste webbl¨asarna f¨or mobiltelefoner.

1.2. Syfte 2

Figur 1.1:Illustration p˚a hur Mobile Documents fungerar

Utvecklingen p˚a webben g˚ar snabbt fram˚at. Dock s˚a har inte alla de mobila webbl¨asarna samma skriptst¨od som f¨or fullskaliga webbl¨asarna. Sidor som bygger mycket p˚a JavaScript blir ofta v¨aldigt tunga f¨or klienten d˚a denna m˚aste l¨asa in och exekvera all JavaScript d˚a sidan laddas. Eftersom mobiltelefoner varken har samma ber¨akningskapacitet som vanliga datorer och att uppkopplingen ofta ¨ar l˚angsammare s˚a kan detta g¨ora att tunga webbsidor k¨anns v¨aldigt l˚angsamma. Mobile Documents webbklient ¨ar ¨aven en v¨aldigt tung sida, d˚a den har en JavaScript-fil p˚a ca en megabyte, vilket g¨or att den ¨ar l˚angsam p˚a en mobil webbl¨asare.

Mobile Documents anv¨ander sig av en teknik som kallas f¨or Comet vilket m¨ojligg¨or tv˚av¨agskommunikation d¨ar ¨aven HTTP-servern kan initiera kommunikation. Detta till skillnad fr˚an traditionell teknik d¨ar klienten alltid fr˚agar och f˚ar svar. M˚alet med mitt arbete var att avg¨ora om denna teknik fungerar p˚a de mobila webbl¨asarna.

1.2

Syfte

Syftet med examensarbetet ¨ar att skapa en webbapplikation som ¨ar lik den mobilap-plikation som finns f¨or Symbian/S60 och klarar av de mest fundamentala sakerna i Mobile Documents. Stor vikt kommer att ligga i att beh˚alla en bra prestanda s˚a att anv¨andarupplevelsen blir behaglig.

1.3. Direktiv 3

1.3

Direktiv

Visiarc har satt upp m˚alet med examensarbetet att en webbapplikationsvariant av deras mobilapplikation som klarar de viktigaste funktionerna i Mobile Documents ska tas fram. Dessa funktioner ¨ar:

• Login Det ska g˚a att logga in p˚a Mobile Documents

• Dokumentvisning Det ska g˚a att bl¨addra bland dokumenten och visa dess in-neh˚all.

• Mejlhantering Det ska g˚a att l¨asa, skriva och skicka mejl.

Webbapplikation ska ¨aven kunna lyssna p˚a uppdateringar och f¨or¨andra den vy som anv¨andaren tittar p˚a d¨arefter. T.ex. om anv¨andaren tittar p˚a en vy som represente-rar anv¨andarens mejlinkorg och servern registrerar att ett nytt mejl har inkommit. D˚a ska webbapplikationen uppdatera vyn s˚a att det nya mejlet visas. Anv¨andaren ska allts˚a inte sj¨alv beh¨ova uppdatera vyn och inte heller ska webbapplikationen automatiskt ladda om sidan f¨or att den nya informationen ska visas. Informationen ska infogas i den exi-sterande vyn genom en manipulation av vyn. Webbapplikationen ska endast rikta sig till telefoner som har peksk¨arm och str¨ava efter att ha ett utseende som ¨ar likt en mobilap-plikation. D.v.s. anv¨andaren ska f˚a en k¨ansla av att det ¨ar en mobilapplikation ist¨allet f¨or en webbapplikation. F¨or att f˚a ett mobilapplikationslikt utseende s˚a f¨oresl˚ar Visiarc att designen byggs p˚a Nokia Mobile Web Templates for High-End Devices, vilket ¨ar ett webbgr¨anssnitt f¨or mobiltelefoner som Nokia har tagit fram.

F¨or att f˚a ett s˚a mobilapplikationslikt beteende som m¨ojligt vill ¨aven Visarc att m¨ojligheterna till att skapa ett installationsskript f¨or webbapplikationen i olika telefonmodeller un-ders¨oks. Dessa skript ¨onskas fungera s˚a att n¨ar de k¨ors s˚a skapar de en genv¨ag till web-bapplikationen som representeras i telefonen som om det vore en vanlig mobilapplikation.

Visiarc ¨onskar att utvecklingen av applikationen i s˚a stor utstr¨ackning som m¨ojligt sker i Google Web Toolkit (GWT).

1.4. Problemformulering 4

1.4

Problemformulering

Projektet siktar p˚a att l¨osa f¨oljande problem:

• Ta fram en mobil webbapplikation utefter Visiarcs riktlinjer.

Delproblem som ska l¨osas f¨or att ˚astadkomma detta ¨ar att unders¨oka:

• Hur stor skillnad ¨ar det p˚a JavaScript-st¨odet mellan de olika webbl¨asarna? F¨or att kunna skriva en mobil webbapplikation f¨or flera webbl¨asare s˚a m˚aste det utredas hur stor kompatibiliteten ¨ar mellan webbl¨asarna.

• Hur exekverar webbl¨asarna JavaScript-koden? Eftersom prestandan ¨ar en viktig faktor i examensarbetet s˚a b¨or det kollas upp om man genom att skriva koden p˚a ett visst s¨att kan ¨oka prestandan.

• Kommunikation via proxy-server F¨or att minska n¨atverkstrafiken p˚a de mobila webbl¨asarna s˚a ¨ar flera mobila webbl¨asare inst¨allda att surfa via en proxy-server som filtrerar och minimerar trafiken. Hur kommer detta p˚averka applikationens kommunikation med Mobile Documents centrala server?

1.5

Avgr ¨ansningar

Eftersom det finns s˚a m˚anga olika webbl¨asare s˚a har Visiarc satt upp en prioriteringslista f¨or vilka webbl¨asare slutresultatet ska st¨odja, d¨ar kravet ¨ar att alla under prio ett ska st¨odjas:

Prio ett

• Safari Mobile ( iPhone / iPad )

• Android Web Browser ( Android )

1.6. Utrustning 5

Prio tv˚a

• Opera mini

• S60 OSS Browser ( Symbian S60 )

Prio tre

• S40 OSS Browser ( Symbian S40 )

• Internet Explorer ( Windows Mobile )

• Netfront ( Sony Ericsson )

Prio fyra

• Palm

• Blackberry

N¨ar det i rapporten h¨anvisas till iPhone s˚a syftar det p˚a Mobile Safari.

1.6

Utrustning

De mobila enheter som jag har haft tillg˚ang till under examensarbetet ¨ar:

Med Mobile Safari:

• Apple iPod Touch

Med Mozilla:

1.7. Rapportens struktur 6

Med Android:

• Android Emulator

• Motorola Droid (Android 2.1)

• Sony Ericsson Xperia 10i (Android 1.6)

• Sony Ericsson Xperia mini (Android 1.6)

Med S60 OSS Browser:

• Nokia N97

Att notera ¨ar att iPoden varit min handledares personliga, vilket resulterat i att jag inte haft fullst¨andig tillg˚ang till den. Samt att n¨ar det g¨aller enheter med Android s˚a har dessa tillkommit under examensarbetets g˚ang och i b¨orjan var jag tvungen att f¨orlita mig p˚a emulatorn.

1.7

Rapportens struktur

Rapporten ¨ar indelad i sex kapitel. Kapitel 2 ger en introduktion till alla de standarder som ¨ar relevanta f¨or arbetet. Kapitel 3 unders¨oker vad det finns f¨or begr¨ansningar och m¨ojligheter p˚a de olika plattformarna. Kapitel 4 beskriver hur utvecklingen av applika-tionen g˚att till samt ˚aterger problem som uppkommit under utvecklingen och viktiga designbeslut som tagits. Kapitel 5 g˚ar igenom de tester som har gjorts p˚a den slutgiltiga produkten. Kapitel 6 inneh˚aller slutstats och diskussion.

K

APITEL

2

Bakgrundsbeskrivning

I detta kapitel kommer flera av de standarder och spr˚ak att beskrivas som anv¨ands f¨or att skapa avancerade webbapplikationer. Under rubriken Standarder och programmerings-spr˚ak kommer ¨aven AJAX och Comet f¨orklaras som ¨ar ben¨amning p˚a tv˚a olika tekniker f¨or att skapa ett asynkront gr¨anssnitt.

2.1

Standarder och programmeringsspr ˚ak

2.1.1

Hyper Text Markup Language

Hyper Text Markup Language, f¨orkortat HTML, ¨ar ett m¨arkspr˚ak och webbstandard f¨or strukturering av text, hypertext, media och inbyggda objekt p˚a exempelvis webbsidor och i epostmeddelanden. Olika webbl¨asare tolkar HTML-kod p˚a olika s¨att och detta ¨

ar ett stort problem f¨or webbutvecklare. Gemensamma standarder f¨or hur HTML-kod ska tolkas best¨ams genom World Wide Web Consortium(W3C). Genom att f¨olja dessa standarder ¨okar chansen att webbsidan ser likadan ut i moderna webbl¨asare. Den senaste versionen av HTML ¨ar HTML 4.01 och den fastst¨alldes 1997 av W3C [6]. F¨or tillf¨allet s˚a arbetas det med n¨asta standard som ¨ar versionen HTML 5 [7]. Utvecklingen av HTML 5 ¨ar l˚angt g˚angen och m˚anga av de nyheter som kommer att ing˚a i HTML 5 standarden ¨

ar redan implementerade av flera webbl¨asare.

2.1. Standarder och programmeringsspr˚ak 8

2.1.2

Document Object Model

Document Object Model, f¨orkortat DOM, ¨ar ett standardiserat s¨att f¨or en webbl¨asare att bygga upp en hemsida. N¨ar en webbl¨asare har tolkat HTML-kod s˚a kommer den att bygga ett DOM-tr¨ad, som sedan ¨ar det som tolkas och visas f¨or anv¨andaren. Med hj¨alp av JavaScript kan man sedan skapa dynamiska sidor som ¨andrar inneh˚allet i sidorna genom att manipulera sidornas DOM-tr¨ad. [8]

2.1.3

Cascading Style Sheets

Cascading Style Sheets, f¨orkortat CSS, ¨ar ett spr˚ak som beskriver presentationsstilen f¨or ett strukturerat dokument som till exempel typsnitt, textstorlek och f¨arg. ¨Aven standar-den f¨or CSS skapas genom W3C och de rekommenderar att man anv¨ander CSS f¨or att ¨

andra format och utseende p˚a element i webbsidor ist¨allet f¨or att anv¨anda sig av attribut i HTML-taggar [9].

Dock s˚a har webbl¨asarnas utveckling av CSS g˚att snabbare ¨an standardens utvecklings-takt. Detta har gjort att webbl¨asarna har skapat egna CSS-funktioner. Dessa icke stan-dardiserade funktioner har f˚att prefix s˚a som -webkit- och -moz- beroende p˚a vilken webbl¨asare som har dessa implementerade. Problemet med att dessa funktioner inte ¨ar standardiserade ¨ar att om man vill utnyttja dem s˚a m˚aste man skapa olika kod beroende p˚a vilken webbl¨asare sidan ska visas p˚a. [10]

2.1.4

Cookies

En Cookie ¨ar en textbaserad datafil som en webbsida kan beg¨ara att f˚a spara p˚a en bes¨okares dator. Cookien kommer sedan att skickas tillbaka till sidan vid varje f¨orfr˚agan som g¨ors till webbservern. I en cookie kan ¨aven en giltighetstid att anges, n¨ar giltighets-tiden g˚att ut kommer webbl¨asaren att ta bort cookien. [11]

2.1.5

JavaScript

JavaScript ¨ar ett interpreterande programspr˚ak, ¨aven kallat skriptspr˚ak. Detta inneb¨ar att koden kommer att tolkas av en interpretator samtidigt som programmet exekveras.

2.1. Standarder och programmeringsspr˚ak 9

Detta till skillnad fr˚an ett kompilerande programspr˚ak d¨ar programmet i en separat process ¨overs¨atts till maskinkod av en kompilator innan det exekveras. Det finns ¨aven mellanting mellan dessa spr˚ak. Ett exempel ¨ar Java, d¨ar koden f¨orst kompileras till en mellankod och sedan tolkas av en interpretator n¨ar den exekveras.[12] [13]

Interpretator f¨or JavaScript brukar i vardagligt tal ben¨amnas som JavaScript-motor. Att det ¨ar ett interpreterande spr˚ak f˚ar nackdelarna gentemot ett kompilerande spr˚ak att det kommer bli l˚angsammare att exekvera, d¨aremot f˚ar det f¨ordelen att det kan k¨oras p˚a alla plattformar bara de har en JavaScript-motor, vilket finns integrerat i s˚a gott som alla dagens webbl¨asare.[12] [13]

Skillnaden mellan hur snabbt JavaScript tolkas p˚a en vanlig dator och mobiltelefon ¨ar stor. Diagrammet nedan visar hur snabbt JavaScript ¨ar p˚a olika webbl¨asare och platt-formar, desto l¨angre stapel desto snabbare ¨ar exekveringen av JavaScript.

Figur 2.1: Diagram som visar hur olika snabbt JavaScript exekveras p˚a olika plattformar och webbl¨asare. (Datan ¨ar h¨amtad fr˚an NS Basic Corporation [1])

2.1. Standarder och programmeringsspr˚ak 10

Datan ¨ar h¨amtad fr˚an NS Basic Corporation [1] och ¨ar en bra illustration p˚a hur mycket l˚angsammare JavaScript-exekveringen ¨ar p˚a en mobiltelefon till skillnad fr˚an en dator.

2.1.6

Asynchronous JavaScript and XML

Asynchronous JavaScript and XML, f¨orkortat AJAX, ¨ar i sig ingen egen teknologi utan en samling av olika tekniker som g¨or det m¨ojligt att bygga hemsidor p˚a ett kraftfullare s¨att ¨an tidigare. Termen AJAX myntades 2005 av Jesse James Garret p˚a Adaptive Path i Usa.[2]

Inom ramen AJAX ing˚ar tekniker som:

• Standardbaserade presentation som anv¨ander XHTML (eller HTML) och CSS. • Dynamisk visning och interaktion med hj¨alp av DOM.

• Asynkrona dataanropp till webbsidan med XMLHttpRequest.

• Och JavaScript som binder samman alla tekniker.

I tradionell webbteknik (icke AJAX) s˚a kommer webbsidan s˚a fort den ska uppdateras eller f¨or¨andras (tex vid interaktion fr˚an anv¨andaren) att skicka en f¨orfr˚agan till webbser-vern som hanterar datan och sedan skickar tillbaka en ny sida. Detta skapar ofta v¨aldigt mycket v¨antan f¨or anv¨andaren.[2]

Grunden f¨or AJAX ¨ar att man skapar en AJAX-applikation skriven i JavaScript som laddas med sidan. N¨ar anv¨andaren sedan interagerar med sidan s˚a kommunicerar sidan med AJAX-applikationen ist¨allet f¨or med servern. AJAX-applikationen skickar sedan en asynkron f¨orfr˚agan till servern. N¨ar sedan servern svarar s˚a kan AJAX-applikationen manipulera den sida som anv¨andaren ser med den nya informationen. Detta resulterar i att endast den information som beh¨over uppdateras skickas mellan server och klient ist¨allet f¨or hela sidan. Anv¨andaren kan forts¨atta anv¨anda sidan medan en f¨orfr˚agan mot servern sker vilket ger en st¨orre applikationsk¨ansla ¨over sidan. I figur 2.2 s˚a illustreras skillnaden mellan traditionell teknik och AJAX. [2]

2.1. Standarder och programmeringsspr˚ak 11

Figur 2.2: Illustration p˚a hur AJAX fungerar. [2]

2.1.7

Comet

Figur 2.3:

Renh˚allningsprodukt fr˚an Ajax respekti-ve Comet

Till skillnad fr˚an AJAX s˚a st˚ar namnet egentligen inte f¨or n˚agot ut-an ¨ar ist¨allet en lek med namnet Ajax, d˚a b˚ade Comet och Ajax ¨ar stora m¨arken f¨or renh˚allningsprodukter i USA [14]. Ett annat namn f¨or Comet ¨ar ”long polling”. AJAX och Comet kan verka vara sam-ma sak, men den stora skillnaden ¨ar att en Comet applikation inte fr˚agar varje g˚ang den vill ha ny data, utan den ser till att h˚alla en f¨orbindelse ¨oppen med servern, s˚a att servern i sin tur kan kommuni-cera med webbapplikationen utan att beh¨ova v¨anta p˚a en fr˚aga fr˚an webbapplikationen.

2.1. Standarder och programmeringsspr˚ak 12

K

APITEL

3

Unders ¨okning

I detta kapitel unders¨oks skillnader mellan de olika plattformarna samt hur applikationen b¨or designas f¨or att f˚a bra prestanda och anv¨andarv¨anlighet.

3.1

Optimeringsm ¨

ojligheter

N¨ar det g¨aller optimering s˚a s¨ager Wagner [15] att man kan urskilja tv˚a skolor. Dessa sko-lor kallar han f¨or hyperoptimerare (eng. hyper-optimizers) samt avslappnade optimerare (eng. relaxed optimizers). Hyperoptimerare g¨or allt f¨or att spara en byte eller ett on¨odigt anrop till webbservern. De prioriterar sparandet av n˚agra f˚a millisekunder framf¨or kodens l¨asbarhet. De avslappnade optimerarna ¨ar v¨aldigt intresserad att optimera sin kod men ¨

ar inte beredd att offra l¨asbarhet och hanterlighet av f¨or att tj¨ana n˚agra nanosekunder.

Innan man b¨orjar med att optimera s˚a tycker Wagner att man m˚aste v¨alja vilken av dessa skolor man faller in i.

3.1.1

Optimering av bandbredd

Den st¨orsta flaskhalsen n¨ar man utvecklar en webbapplikation f¨or mobila enheter ¨ar tiden det tar f¨or data att transporteras mellan webbserver och webbl¨asare. Wagner

3.1. Optimeringsm¨ojligheter 14

tar d¨arefter en del viktiga saker som man b¨or t¨anka p˚a, nedan f¨oljer en delm¨angd av dem.

• Separera sidinneh˚allet i separata .css, .js och .html filer s˚a att varje separat fil kan bli sparad av webbl¨asaren i dess cacheminne.

• Reducera f¨orekomsten av tomma utrymmen (tabbar och mellanslag) d¨ar det ¨ar m¨ojligt.

• Ta bort kod och taggar som inte anv¨ands. • Ta bort kommentarer i koden.

• Anv¨and korta filnamn.

• Minimera det totala antalet stilmallar och JavaScriptbiblioteks-filer som inkluderas i sidan. Detta p˚a grund av att webbl¨asaren endast g¨or tv˚a filf¨orfr˚agningar ˚at g˚angen. Varje fil som webbl¨asaren m˚aste v¨anta p˚a f¨or varje f¨orfr˚agan att bli klar kommer skapa f¨ordr¨ojningar.

• ¨Overv¨ag att anv¨anda gzip-komprimering p˚a datat som skickas.

• ¨Overv¨ag att anv¨anda JavaScript komprimering.

Det ¨ar ¨aven v¨aldigt m˚anga anv¨andare som betalar f¨or den data som skickas fr˚an och till mobiltelefonen, vilket g¨or att det inte bara ¨ar bra f¨or applikationens hastighet att minimera informationen som skickas mellan klient och server utan ¨aven g¨or applikationen billigare att anv¨anda f¨or m˚anga anv¨andare.

Bilder

Att ladda stora bilder ¨ar ofta en flaskhals. Att optimera bildernas storlek f¨or applikationen kan spara mycket bandbredd. H¨ar tycker Wagner [15] att man ska vara pedantisk. Att bara banta flera bilders storlek med 5kb s˚a kan det skapa stora vinster i bandbredd. Bilder tar upp mycket mer plats ¨an text, d¨arf¨or b¨or det ¨overv¨agas att koda s˚a mycket design som m¨ojligt med hj¨alp av CSS ist¨allet f¨or att anv¨anda sig av bilder. I de webbl¨asare som har b¨ast st¨od f¨or CSS kan man g¨ora avancerade ikoner (se figur 3.1)[4], dock s˚a ¨ar inte st¨odet lika stort i alla webbl¨asare och i de webbl¨asare som inte hanterar alla CSS-attribut korrekt blir bilderna odugliga.

3.1. Optimeringsm¨ojligheter 15

Figur 3.1: Bilder skapade helt i CSS, tagna ur sk¨armdump d˚a de visas i webbl¨asaren Safari 4.0.5 [4]

CSS & JavaScript

B˚ade CSS och JavaScript skickas i klartext, d¨arf¨or kan man optimera bort mycket data genom att korta ner namnen p˚a JavaScript-funktioner och variabler samt anv¨anda sig av korta CSS-identifierare.

Cookies

Cookies ¨ar ett vanligt och effektivt s¨att att spara sm˚a m¨angder av data p˚a en webbklient. Dock s˚a kommer denna data skickas med i varje f¨orfr˚agan som g¨ors mot servern. D¨arf¨or b¨or datam¨angden som lagras i cookies vara s˚a liten som m¨ojligt f¨or att inte p˚averka hastigheten p˚a applikationen. [16]

Minifiering

Eftersom JavaScript-koden f¨orst behandlas i webbl¨asaren kommer den att skickas i klar-text mellan server och webbl¨asare. F¨or att d˚a minimera det som skickas s˚a m˚aste man minimera antalet tecken i koden. Detta g¨ors genom att d¨opa om funktionsnamn, va-riabelnamn etc. till enstaka bokst¨aver ist¨allet f¨or fullst¨andiga ord. Resultatet blir f¨or m¨anniskan en till synes ol¨asbar kod. D¨arf¨or ¨ar detta inget man g¨or under sj¨alv program-meringen utan man l˚ater ett program g¨ora detta i efterhand n¨ar koden ¨ar f¨ardigskriven.

3.1. Optimeringsm¨ojligheter 16

Det finns flera gratisprogram p˚a n¨atet som tillhandah˚aller denna tj¨anst. I Google Web Toolkit s˚a kan man n¨ar man kompilerar Java-koden till JavaScript v¨alja att l˚ata den ge-nererade JavaScript koden bli minimal p˚a detta s¨att. En positiv bieffekt av komprimering av JavaScript-kod ¨ar att koden blir sv˚arare att l¨asa, d¨armed s˚a blir den ¨aven s¨akrare.

Komprimering

Ett vanligt s¨att att minska ner datan som skickas via server och klient ¨ar att komprimera informationen. Gzip ¨ar en standard som st¨ods av s˚a gott som alla webbl¨asare. Hur mycket en fil komprimeras beror p˚a den grad av redundans eller repetering av teckensekvenser i filen. I enstaka fall s˚a kan den komprimerade filen krympas till en femtedel av den ursprungliga filen [17].

3.1.2

Optimering av processortid

DOM-tr ¨adet

Att manipulera och s¨oka upp element i DOM-tr¨adet tar l˚ang tid [15], d¨arf¨or b¨or alla operationer mot DOM-tr¨adet t¨ankas igenom. T.ex. om man ska g¨ora flera operationer p˚a samma DOM-element s˚a ¨ar det mycket effektivare att endast leta upp elementet en g˚ang och spara en pekare dit i en variabel ¨an att leta upp det f¨or varje operation man ska g¨ora.

Till exempel s˚a ¨ar det mer kostsamt att g¨ora s˚ah¨ar:

var str = document.createTextNode("hello");

document.getElementById("content").appendChild(str); document.getElementById("content").className = "special";

¨

An att g¨ora s˚ah¨ar:

var str = document.createTextNode("hello"); var p = document.getElementById("content"); p.appendChild(str);

3.1. Optimeringsm¨ojligheter 17

Dessutom s˚a kostar det att manipulera ett DOM-element som redan finns i tr¨adet. D¨arf¨or om man ska l¨agga till ett nytt DOM-element som inneh˚aller flera barn i DOM-tr¨adet s˚a ¨

ar det mycket b¨attre att l¨agga till alla barn i elementet innan det f¨ors in i tr¨adet. Annars m˚aste vyn uppdateras flera g˚anger ist¨allet f¨or bara en. Se exempel nedan d¨ar operatio-nen document.body.appendChild(commentDiv); l¨agger in elementet i DOM-tr¨adet. I det ¨

ovre kodblocket l¨aggs elementet in i DOM-tr¨adet och sedan fylls p˚a, vilket resulterar i en DOM-manipulation varje g˚ang elemntets fylls p˚a. Detta till skillnad fr˚an det nedre kodblocket d¨ar elementet fylls innan det l¨aggs in i DOM-tr¨adet.

var comments=customBlog.getComments(‘index’); var c=comments.count;

var entry;

var commentDiv = document.createElement(‘div’); document.body.appendChild(commentDiv);

for (var i=0;i<c;i++) {

entry=document.createElement(‘p’); entry.appendChild( document.createTextNode(comments[i]); commentDiv.appendChild( entry ); } var comments=customBlog.getComments(‘index’); var c=comments.count; var entry;

var commentDiv = document.createElement(‘div’); for (var i=0;i<c;i++) {

entry=document.createElement(‘p’);

entry.appendChild( document.createTextNode(comments[i]); commentDiv.appendChild( entry );

}

document.body.appendChild(commentDiv);

F¨or de operationer som g˚ar s˚a b¨or man anv¨anda Window-objektet eftersom webbl¨asaren d˚a inte beh¨over g¨ora n˚agra s¨okningar i DOM-tr¨adet f¨or att kunna svara.

D.v.s. ist¨allet f¨or att anv¨anda upps¨okningar som:

3.1. Optimeringsm¨ojligheter 18

var h = document.url.href; var h = location.href;

S˚a ¨ar det b¨attre att g¨ora s¨okningen via window-objektet:

var h = window.location.href;

Variabler

N¨ar Mobile Safari processar koden s˚a kommer den alltid att f¨orst leta efter lokala vari-abler. Om den inte hittar variabeln den s¨oker efter s˚a kommer den s¨oka i n¨asta niv˚a och sen i n¨asta o.s.v. Detta resulterar i att globala variabler kommer vara de variabler som ¨ar l˚angsammast att s¨oka upp och de som befinner sig p˚a samma niv˚a som operationen kom-mer att g˚a snabbast att hitta. Att komma ˚at objekt eller egenskaper via punkt notering ¨

ar aldrig effektivt t.ex.

document.property.property.property

D¨arf¨or b¨or detta g¨oras s˚a s¨allan som m¨ojligt. Kod som:

m.n.no.p.doThis; m.n.no.p.doThat;

b¨or ers¨attas med:

var d = m.n.o.p; d.doThis;

d.doThat;

Enkeltr ˚adat spr ˚ak

Eftersom JavaScript ¨ar enkeltr˚adat s˚a skapar det en del prestandaproblem d˚a flera pro-cesser inte kan k¨ora parallellt. Detta resulterar i att kr¨avande operationer kan l˚asa hela

3.1. Optimeringsm¨ojligheter 19

programmet under en viss tid. F¨or att undvika detta s˚a finns tv˚a m¨ojligheter. Om det g˚ar s˚a l˚ater man de kr¨avande operationerna ske p˚a serversidan. Detta g¨ors genom att skicka en asynkron f¨orfr˚agan till servern. Eftersom anropet ¨ar asynkront kommer anropet inte blockera klienten fr˚an att k¨ora annan kod medan den v¨antar p˚a svar fr˚an servern. Om man m˚aste utf¨ora operationerna p˚a klientsidan, s˚a kan man skapa en schemal¨aggare p˚a tunga ber¨akningar som utf¨or en liten del av ber¨akningen ˚at g˚angen. T.e.x. om man ska iterera ¨over en l˚ang lista s˚a kan man l˚ata iterera X antal g˚anger f¨or att sedan pausa iterationen. Med en timer st¨aller man in n¨ar iterationen ska forts¨atta igen. Under tiden iterationen v¨antar p˚a att starta igen kan andra JavaScript-funktioner k¨oras.

Lazy Loading

All JavaScript-kod laddas hem till webbl¨asaren innan den k¨ors, vilket resulterar i att det kan ta l˚ang tid innan applikationen startar om JavaScript-filen ¨ar stor och uppkopplingen l˚angsam. F¨or att undvika att all kod h¨amtas med detsamma s˚a kan man anv¨anda sig av n˚agot som kallas Lazy Loading, ¨aven kallat Code Splitting. Denna teknik fungerar s˚a att om man har en del av applikationen som ¨ar frist˚aende, s˚a kan man l˚ata webbl¨asaren h¨amta JavaScript-koden f¨orst n¨ar den ska k¨oras. N¨ar den v¨al ¨ar h¨amtad s˚a beh¨over man inte h¨amta den n¨asta g˚ang man g˚ar in i den frist˚aende delen.[18]

Om man vet att det finns tid att h¨amta den frist˚aende delen n˚agon g˚ang d˚a huvudpro-grammet k¨ors, s˚a kan man anv¨anda sig av prefetching. Det vill s¨aga att man laddar koden innan den beh¨ovs. Detta resulterar i att den redan finns laddad n¨ar den ska anv¨andas.[18]

Deferred Binding

Inom webbprogrammering uppst˚ar ofta speciall¨osningar f¨or olika webbl¨asare. F¨or att d˚a inte alla ska webbl¨asare ska beh¨ova ladda hem kod som ¨ar specifik f¨or andra webbl¨asare s˚a kan man skapa olika kodblock f¨or olika webbl¨asare. N¨ar sedan webbl¨asaren surfar in p˚a sidan s˚a l˚ater man den endast h¨amta hem det kodblock som passar den l¨asaren b¨ast. [19]

3.2. Olika renderingsmotorer 20

3.2

Olika renderingsmotorer

Det finns idag flera olika renderingsmotorer som webbl¨asare anv¨ander sig av f¨or att rendera webbsidor. De tre mest anv¨anda ¨ar Gecko, Presto och WebKit, varav WebKit ¨

ar den absolut vanligaste inom mobila webbl¨asare.

MicroB som ¨ar webbl¨asaren i n900 anv¨ander sig av Gecko, medan Android respektive iPhone anv¨ander sig av WebKit.

Peter-Paul Koch som driver sidan quirksmode.org har gjort en unders¨okning f¨or att visa att WebKit p˚a mobila webbl¨asare inte kan r¨aknas som en renderingsmotor utan beter sig olika beroende p˚a webbl¨asaren den befinner sig i. I unders¨okningen har han testat 22 olika mobila webbl¨asare som har WebKit. Resultatet visar p˚a att alla webbl¨asare beter sig olika och hans slutsats av testet ¨ar kort och koncist:

There is no “WebKit on mobile!” [20]

Detta resulterar i att om en webbapplikation utvecklas mot en webbl¨asare som har webkit som renderingsmotor s˚a ¨ar det inte s¨akert att en applikationen kommer att bete sig likadant p˚a en konkurerande webbl¨asare som ocks˚a har webkit som renderingsmotor.

3.3

Begr ¨ansningar

Dokumentationen runt de olika webbl¨asarna ¨ar v¨aldigt olika. Om iPhone g˚ar det mesta att hitta om vad webbl¨asaren har f¨or begr¨ansningar etc. Dock s˚a har jag inte hittat mycket information om Android och Maemo. F¨or Android s˚a har jag oftast f¨orst uppt¨ackt begr¨ansningarna via egen testning f¨or att sedan hitta att begr¨ansningen ¨ar bekr¨aftat i Andorids buggrapporteringssystem, d˚a utvecklare har rapporterat det som buggar och Android-teamet sedan bekr¨aftat buggarna som en begr¨ansning. Nedan f¨oljer n˚agra av de begr¨ansningar som p˚averkar webbapplikationen.

3.3. Begr¨ansningar 21

Bilder

I iPhone finns en begr¨ansning om att en animerad GIF-bild max f˚ar vara 2MB stor. Om denna storlek ¨overskrids kommer endast f¨orsta bilden i animationen att visas [15]. Android har inte i sina tidiga versioner n˚agot st¨od f¨or animerade GIF-bilder, men efter version 2.2 av operativet s˚a finns ett st¨od f¨or detta [21]. Dock har jag inte hittat n˚agon dokumentation om det finns n˚agon begr¨ansning i storlek f¨or animerade GIF-bilder i Android 2.2.

CSS

I iPhone s˚a st¨ods inte i CSS attributet position: fixed; [15]. Webbl¨asaren kommer att behandla fixed som absolute [22]. Detta medf¨or att man inte med hj¨alp av CSS kan positionera ett objekt i f¨orh˚allande till webbl¨asarf¨onstret, t.ex. s˚a kan man inte skapa ett objekt som alltid ligger l¨angst upp i den synliga vyn hur man ¨an scollar i sidan. I Android s˚a st¨ods attributet fixed, men vid testning av hur det fungerar s˚a visar det sig att det upptr¨ader konstigt. Ist¨allet f¨or att alltid ligga fast p˚a sin f¨onsterposition s˚a kommer objektet som har attributet att vid scrollning hoppa fram med en f¨ordr¨ojning mellan varje hopp. ¨Aven fall d˚a den inte efter hoppande slutar i r¨att position har under testerna intr¨affat.

JavaScript

I iPhone st¨ods inte eventen mouseover och mouseout. Den st¨oder inte heller document-eventen: onkeydown, onkeypress och onkeyup, och inte window-document-eventen: onresize och onScroll [23].

Cookies

Cookies anv¨ands ofta f¨or att hantera inloggningssessioner, identifiera anv¨andare och spa-ra anv¨andarinst¨allningar. M˚anga mobila webbl¨asare st¨odjer inte cookies eller har en ofullst¨andig implementation av cookies. D¨arf¨or b¨or de aktuella webl¨asarna testas om de har st¨od f¨or cookies. Om det inte finns st¨od f¨or cookies s˚a rekommenderas att f¨or hantering av sessioner anv¨anda manipulation av URI:n (Uniform Resource Identifier).

3.4. Anv¨andargr¨ansnitt 22

[24]

Vid testning av de enheter jag har haft att tillg˚a visade det sig att Nokia N97 med S60 OSS Browser inte har ett fullst¨andigt st¨od f¨or cookies. D˚a denna inte skickar med cookies i varje f¨orfr˚agan till servern. D¨aremot verkar st¨odet vara full¨andat p˚a ¨ovriga enheter.

I HTML5 kommer en ny standard f¨or att lagra data som troligen kommer att ers¨atta Cookies. D˚a alla webbl¨asare inte har st¨od f¨or denna funktionalitet s˚a har jag inte titta n¨armare p˚a denna funktionalitet.

3.4

Anv ¨andargr ¨ansnitt

F¨or f˚a ett enhetligt anv¨andargr¨ansnitt (UI eng: User Interface) som fungerar p˚a de olika webbl¨asarna s˚a m˚aste det unders¨okas vad det finns f¨or skillnader med hur sidan visas f¨or anv¨andaren och vad som h¨ander n¨ar man interagerar med den.

3.4.1

Viewport

I mobila webbl¨asare pratar man ofta om viewports. Viewport ¨ar den yta av webbl¨asaren som man ser webbsidan igenom. Eftersom olika telefoner har olika stora sk¨armar s˚a har de d¨armed olika stora viewports.

Maemo

Maemo har en viewport som i landskapsvy ¨ar 800 x 480 px i fullsk¨armsl¨age och 800 x 354 px n¨ar verktygspaneler visas. I potr¨attvy s˚a ¨ar viewporten 730 x 480 px. [25]

Android

En sk¨arm p˚a en Android-telefon kommer att ha en viss sk¨armdensitet, (p˚a engelska screen density). En sk¨arm med l˚ag densitet har f¨arre pixlar per tum (inch) medan en sk¨arm med h¨og densitet har fler pixlar per tum. Detta medf¨or att ett UI-element vars h¨ojd och bredd

3.4. Anv¨andargr¨ansnitt 23

¨

ar definierad i pixlar kommer att se st¨orre ut p˚a en sk¨arm med l˚ag densitet och mindre p˚a en sk¨arm med h¨og densitet. Android generaliserar alla olika densiteter in i tre olika grupper: h¨og, medium och l˚ag.

Som standard kommer d¨arefter webbvyn att skalas beroende p˚a vilken densitetgrupp sk¨armen tillh¨or. Om sk¨armen har en densitet som motsvarar medium s˚a kommer vyn ej att skalas, d¨aremot om sk¨armen motsvarar h¨og densitet kommer vyn att skalas med 1,5 ggr samt om den har en l˚ag densitet kommer vyn att skalas med 0,75 ggr.

Via testning p˚a Android s˚a kan man konstatera att skalningen ger ett litet problem. Bilderna som av operativsystemet ¨ar skalade blir oskarpa d˚a man trycker p˚a sk¨armen (touch-event). Fenomenet upptr¨ader inte n¨ar man navigerar runt med navigationsknap-par.

Figur 3.2: Illustration p˚a hur bilderna blir oskarpa vid touch-event. T.v. utan touchevent och t.h. med touchevent. Sk¨armdumparna ¨ar fr˚an test p˚a en Motorola Droid som har en h¨ogdensitetssk¨arm.

F¨or att undvika att bilderna blir suddiga n¨ar man trycker p˚a sk¨armen, s˚a finns det tre l¨osningar:

• ¨Andra s˚a att telefonen inte skalar webbvyn. P˚a detta s¨att s˚a kommer alltid pixlarna representeras i sin egentliga storlek. Detta ger den positiva effekten att det ¨ar l¨attare att g¨ora en snygg design av hemsidan. Dock f¨oljer nackdelarna att man f¨or att f˚a en bra anv¨andarupplevelse m˚aste g¨ora tre olika fall av designen. Ett problem ¨ar ocks˚a att st¨od f¨or att best¨amma storleken p˚a viewporten f¨orst finns i Android 2.0

3.4. Anv¨andargr¨ansnitt 24

• Eftersom bilderna i en h¨ogdensitetssk¨arm kommer att skalas upp 1.5 ggr s˚a kan man redan fr˚an b¨orjan skapa en bild som ¨ar 1.5 ggr s˚a stor som det ¨ar t¨ankt och sedan skala ner den med hj¨alpa av CSS. Detta kommer medf¨ora att webbl¨asaren kommer skala bilden tillbaka till sin naturliga storlek, vilket i sin tur resulterar i att den inte blir suddig.

• L¨osning nummer tre ¨ar helt enkelt att inte se suddigheten som ett problem och acceptera den. Suddigheten kan ¨aven ses som en f¨orst¨arkning av bekr¨aftelsen att du tryckt p˚a sk¨armen.

Fr˚an och med Android version 2.0 s˚a kan man p˚a Android-telefoner styra hur mycket sidan ska skalas via DOM, CSS och meta-taggar.

iPhone och iPod

P˚a iPhone och iPod s˚a ¨ar viewporten 320x356 pixlar i portr¨attl¨age och 480 x 208 pixlar i landskapsvy.

Figur 3.3: Illustration p˚a storleken p˚a iPhones webbvy [5]

3.4. Anv¨andargr¨ansnitt 25

Som standard kommer iPhone att f¨oruts¨atta att sidan ¨ar 980px bred. F¨or att motverka detta s˚a kan man s¨atta viewport till f¨onstrets faktiska storlek med hj¨alp av meta-taggar.

3.4.2

Interaktion

Inmatning

Inmatning av text fr˚an anv¨andaren b¨or vara s˚a liten som m¨ojligt, detta eftersom detta ofta ¨ar en tidskr¨avande process p˚a mobila enheter. D¨arf¨or rekommenderas att man i s˚a h¨og grad som m¨ojligt anv¨ander radioknappar, selektionslistor och andra kontroller som inte kr¨aver att anv¨andaren beh¨over mata in text. [16]

Scrollning

En sida b¨or designas s˚a att scrollning ¨ar begr¨ansad till en riktning. Detta f¨or att scroll-ningen ska vara s˚a enkel som m¨ojligt f¨or anv¨andaren. Vissa saker kan dock inte anpassas f¨or att visas med endast en scroll i en riktning, s˚asom vissa kartor och bilder. D¨arf¨or b¨or det undvikas att visa s˚adana objekt tillsammans med den ¨ovriga inneh˚allet. Om det inte g˚ar att undvika att visa bilder som ¨ar st¨orre ¨ar sk¨armstorleken s˚a b¨or dessa visas p˚a en separat sida med en l¨ank tillbaka till huvudsidan. [24]

Tab-ordning

Det ¨ar viktigt att tabordningen ¨ar i logisk ordning. Detta eftersom m˚anga av objekten inte kommer att kunna visas samtidigt som det element som ¨ar fokuserat. [24]

3.5. Pekdon 26

3.5

Pekdon

3.5.1

Touch-event

Med touch-event s˚a syftar jag p˚a event som skickas av webbl¨asaren d˚a man trycker p˚a sk¨armen och som man sedan kan f˚anga upp med JavaScript. Touch-event tillh¨or HTML5 och iPhone (fr˚an och med iPhone 2.0) samt Android Browser st¨odjer b˚ada touch-event[26]. Dock s˚a kommer detta f¨orst att komma till Mozilla Firefox i Firefox 4 [27].

3.5.2

Egna tester

Jag har gjort en del tester p˚a vilka events som skickas vid interaktion med en textbox.

Mina testresultat visar tydligt p˚a att det ¨ar stor skillnad p˚a vilka event som skickas bero-ende p˚a vilken plattform man befinner sig p˚a. S˚a fort det virtuella tangentbord p˚a n900 ¨

oppnas s˚a skickas eventen onMouseOut och onBlur, vilket betyder att webbapplikationen tror att textboxen har f¨orlorat fokus n¨ar den egentligen inte har det. Samt att man b˚ade p˚a Droiden och n900 kan l¨amna fokus fr˚an textboxen efter att ¨andrat v¨ardet utan att f˚a n˚agot event om att v¨ardet har ¨andrats. Enligt HTML-standarden b¨or h¨ar ett event som heter onValueChange skickas.

Eftersom man inte kan lita p˚a att event skickas enligt HTML-standarden s˚a skapar det problem om man vill bygga funktionalitet runt interaktionen med textboxar. Det enda eventet som hanteras korrekt av de olika webbl¨asarna ¨ar eventet onFocus (d˚a man ger textboxen fokus). Wagner p˚ast˚ar ¨aven att onMove ¨ar n˚agon man ska undvika [15].

3.6

Proxy-servrar

Det finns webbl¨asare som l˚ater all trafik g˚a via en proxyserver n¨ar man surfar, t.ex Opera Mobile. En anledning till att l˚ata trafiken g˚a genom en proxy ¨ar f¨or att minska trafiken som skickas ¨over mobiln¨atet till telefonen. De finns tv˚a huvudfall d˚a en anv¨andare sufar via en proxyserver. Fall ett ¨ar n¨ar mobiln¨atsoperat¨oren tvingar anv¨andaren att surfa via en proxy och fall tv˚a d˚a webbl¨asaren automatiskt surfar via en proxy.

3.7. Installationsskript 27

D˚a det inom examensarbete varken finns resurser och tid f¨or att kontrollera vilka ope-rat¨orer som l˚ater sina anv¨andare surfa via proxyservrar och hur dessa servrar p˚averkar trafiken kommer ingen tid att l¨aggas ned p˚a att unders¨oka detta.

3.6.1

Webbl ¨asarspecifika proxyservrar

Den enda av webbl¨asarna som ¨ar listade som prio ett och tv˚a inom ramen f¨or vilka webbl¨asare den mobila webbapplikationen f¨or Mobile Documents ska fungera p˚a, som anv¨ander sig av en proxyserver som standard ¨ar Opera. Opera Mobile ¨ar den webbl¨asare som ¨ar anpassad f¨or den typ av telefoner som exjobbet avser. P˚a denna webbl¨asare g˚ar det att v¨alja om man vill surfa via proxy eller inte [28]. Eftersom denna webbl¨asare bara ¨

ar prio tv˚a kommer ingen tid l¨aggas ned p˚a att unders¨oka de problem som kan uppst˚a d˚a man surfar via proxy.

3.7

Installationsskript

Visiarc har ¨onskan om unders¨oka m¨ojligheterna att skapa ett installationsskript. Detta f¨or att f˚a webbapplikationen att bete sig mer lik en vanlig mobilapplikation. D¨armed beh¨ovde jag unders¨oka hur detta skulle kunna ske p˚a de olika plattformarna.

3.7.1

iPhone och iPod

I iPhone s˚a kan anv¨andaren v¨alja att l¨agga en l¨ank till en hemsida p˚a sin startsk¨arm. F¨or att f˚a sidan att k¨annas mer applikationslik kan man via l¨ank-element definiera en applikations-ikon samt uppstartsbild. Om man d˚a v¨aljer att l¨agga en l¨ank till sidan p˚a sin startsida s˚a kommer hemsidans egna applikations-ikon att visas, samt n¨ar man d˚a v¨aljer att ¨oppna sidan s˚a kommer uppstartsbilden att visas tills hela sidan ¨ar laddad.

De l¨ank-element som anv¨ands ¨ar f¨oljande:

f¨or ikon:

3.7. Installationsskript 28

f¨or uppstartsbild:

<link rel="apple-touch-startup-image" href="/startup.png">

Detta ¨ar dock inget installationsskript, utan anv¨andaren v¨aljer i iPhones inbyggda funk-tioner att l¨agga till sidan p˚a startsidan.

3.7.2

Widgets

En annan variant att g¨ora en hemsida mer applikationslik ¨ar att g¨ora den till en W3C Widget [29]. En widget kan liknas vid en lokal webbapplikation. Den byggs upp av samma standarder som en webbapplikation, men beh¨ovs bara laddas hem till telefonen en enda g˚ang. Detta till skillnad fr˚an en vanlig webbapplikation som laddas hem varje g˚ang man ¨

oppnar sidan. D.v.s. den kommer att bete sig som en vanlig applikation p˚a telefonen, men ¨

ar i grund och botten en webbapplikation. Dock s˚a ¨ar st¨odet f¨or widgets f¨or tillf¨allet inte s˚a stort och f¨or att kunna anv¨anda widgets idag s˚a m˚aste man installera en widgethanterare p˚a sin telefon.

F¨or Android (v2.1 och upp˚at) och Maemo s˚a finns en widgethanterare som heter Aplix Web runtime [30]. Dessutom finns Vodafone Apps Manager som fungerar p˚a Android (v1.6 & v2.1) samt Symbian S60 [31].

3.7.3

Mobilapplikation

Ett s¨att att skapa ett installationsskript ¨ar att skapa en mobilapplikation som har som enda uppgift att starta webbapplikationen. P˚a detta s¨att s˚a kommer applikationen att kunna hanteras som vilken applikation som helst i telefonen.

K

APITEL

4

Utveckling

De olika valm¨ojligheterna i kapitel 3 visar att designrymden f¨or browserbaserade utveck-ling p˚a mobila plattformar ¨ar ganska stor idag. D˚a mobiltelefonernas webbl¨asare skiljer sig s˚a pass mycket ˚at s˚a best¨ammer jag mig f¨or att endast koncentrera mig p˚a de webbl¨asare som ¨ar listade som prio ett f¨or projektet.

4.1

Utvecklingsmilj ¨

o

Valet att anv¨anda Google Web Toolkit (GWT) berodde p˚a flera faktorer. F¨or det f¨orsta s˚a var det en ¨onskan fr˚an f¨oretaget att GWT skulle anv¨andas, f¨or det andra s˚a medf¨or det en hel del f¨ordelar n¨ar det handlar om optimering (vilket beskrivs n¨armare nedan) och f¨or det tredje s˚a har det ett bra verktyg f¨or att debugga koden.

Det som ¨ar unikt med GWT ¨ar att man programmerar i Java varp˚a Java-koden kom-pileras till JavaScript. Det g˚ar ¨aven att k¨ora Java-koden i ett l¨age som kallas Developer Mode alt. Hosted Mode. I detta l¨age s˚a kan man debugga och stega genom koden som om det vore ett vanligt Java-program, vilket resulterar i att man kan anv¨anda de debugging-verktyg som finns tillg¨angliga f¨or Java. Detta ¨ar en stor f¨ordel d˚a det f¨or JavaScript inte finns n˚agot bra debug-verktyg. Eftersom GWT kompilerar koden till JavaScript kan den i kompileringssteget b˚ade minifiera och optimera koden. Den anv¨ander sig ¨aven av Deferred binding, vilket betyder att den under kompileringssteget kan skapa flera olika instanser av koden som ¨ar optimerade f¨or de olika webbl¨asarna.

4.2. Arkitektur 30

Det ¨ar l¨att att i JavaScript g¨ora misstag s˚a att man f˚ar minnesl¨ackor. Dessa problem har GWT l¨osningar f¨or och programmeraren beh¨over inte bry sig om dom d˚a GWT f¨orhindrar dom n¨ar den kompilerar koden till JavaScript.[32]

GWT har ¨aven sin egna mekanism f¨or RPC-anrop. Ist¨allet f¨or att beh¨ova specificera JSON och XML s˚a beh¨over man bara definiera Java-gr¨anssnitt och implementeringar f¨or serverfunktionerna och GWT kommer generera kod som g¨or att klienten kan anropa serverfunktionerna som om dom vore lokala funktioner. Detta g¨or att man slipper arbetet med att definiera XML och JSON dataformat f¨or serverfr˚agor och svar.

GWT kan ¨aven skapa Image Bundles. Detta betyder att man s¨atter ihop flera bilder till en, s˚a att allt laddas ned i en stor fil till webbl¨asaren ist¨allet f¨or ladda hem m˚anga sm˚a filer. GWT paketerar ihop bilderna under kompileringen och utvecklaren beh¨over bara skapa ett gr¨anssnitt med funktioner f¨or att komma ˚at bilderna.

Att Javakod kompileras till GWT-kod kan ¨aven det vara en nackdel d˚a man inte har koll p˚a hur JavaScript-koden blir. Den st¨orsta nackdelen med GWT ¨ar i detta projekt att GWT inte ¨ar anpassat f¨or de mobila webbl¨asarna. Detta resulterar i att den kod som GWT generar kommer vara anpassad f¨or fullskaliga webbl¨asare. ¨Aven om man kan k¨ora GWT i Developer Mode s˚a g˚ar detta endast att g¨ora i vissa webbl¨asare med ett speciellt till¨aggsprogram. Detta medf¨oljer att det inte g˚ar att k¨ora Developer Mode i de mobila webbl¨asarna. D¨arf¨or m˚aste koden alltid kompileras om innan man k¨or p˚a de mobila webbl¨asarna vilket kan vara tidskr¨avande. Desto fler enheter man v¨aljer att g¨ora specialiserad kod f¨or med Deferred Binding s˚a ¨okar antalet instanser som Java-koden ska kompileras till, vilket medf¨or att den totala kompilationstiden blir l¨angre.

En sista anledning till att jag v¨aljer GWT ¨ar att jag jobbat med GWT tidigare i kursen TDDD27 Avancerad webbprogrammering.

4.2

Arkitektur

F¨or att b¨orja med att enligt Wagner[15] best¨amma mig f¨or vilken typ av optimerare jag ¨ar s˚a kommer jag fram till att i detta projekt kommer jag att bli en hybrid av de olika skolorna. Jag kommer som programmerare att bara h˚alla mig till de grundl¨aggande s¨atten f¨or att optimera koden, detta f¨or att beh˚alla kodens l¨asbarhet. Jag kan d¨aremot f¨orlita mig p˚a att GWT-kompilatorn g¨or en stor del av optimeringsjobbet ˚at mig.

4.2. Arkitektur 31

Figur 4.1: Arkitektur

Arkitekturen ¨ar uppbyggd i fyra olika block: Login, Main, Mail och Document. En anledning till att de ¨ar separerade p˚a detta s¨att ¨ar hur anv¨andaren tar sig till blocket. Vid uppstart av applikationen kommer man f¨orst att hamna i Login-blocket. Detta block kommer att avg¨ora om anv¨andaren ¨ar inloggad eller inte och skicka den vidare till main-blocket alternativt kr¨ava anv¨andaren p˚a korrekt inloggning f¨or att sedan skicka vidare denne till main-blocket. Det ¨ar f¨orst fr˚an main-blocket anv¨andaren kan komma ˚at mail-respektive document-blocket. Eftersom blocken f¨oljer varandra i en kronologisk ordning efter inloggning s˚a ¨oppnar det f¨or m¨ojligheter att anv¨anda sig av Lazy Loading.

Mainblocket ¨ar sj¨alva k¨arnan i applikationen. Dess funktionalitet kan delas upp i tv˚a huvudfunktionaliteter. Ett ¨ar att se till s˚a att det g˚ar att navigera runt i mappar i en listvy, det andra f¨or att sk¨ota Comet-kommunikationen med servern.

Navigation

Eftersom navigeringen sker i en tr¨adliknande struktur har jag ¨aven valt att representera datan i en tr¨adstruktur av noder. En nod har ett unikt id f¨or det arkiv den befinner sig i och arkivens id:n ¨ar alltid unika. D¨arf¨or kommer ett arkiv att vara root-noden av typen archive (i koden representeras av DArchive) och sedan s˚a kommer alla undernoder vara av typen node (i koden representeras som Node). F¨ordelen med att l˚ata data representeras i en tr¨adstruktur ¨ar att man alltid vet var i tr¨adet man st˚ar och man vet vilken nodens f¨or¨alder ¨ar och vilka barn den har. N¨ar anv¨andaren navigerar s˚a ¨ar det i s˚a gott som

4.2. Arkitektur 32

alltid n˚agot av dessa denne kommer att navigera till. Alternativet hade varit att l¨agga all data i en platt lista och varje g˚ang leta upp den nod vi ska navigera till. Samt att man d˚a ur listan ¨aven m˚aste leta upp alla barn till noden. Denna operation ¨ar ineffektivare n¨ar man navigerar runt bland noderna men har f¨ordelar om funktionaliteten ska byggas ut, t.ex. med funktioner som att flytta objekt mellan noder. I dessa fall s˚a blir dessa operationer genast mycket enklare med en platt lista eftersom noden inte beh¨over flyttas i tr¨adet utan bara datan om vem som ¨ar dess f¨or¨alder beh¨over ¨andras.

Beroende p˚a vad en nod inneh˚aller f¨or data s˚a kommer den ha olika egenskaper. T.ex. ett mejl och en mapp ¨ar ganska olika. D¨arf¨or har jag skapat underklasser till node f¨or alla dessa olika nodtyper (se figur 4.2).

Figur 4.2: Schema ¨over Node-klassen och dess subklasser

Symbianklienten beter sig s˚a att om anv¨andaren st˚ar p˚a en viss position i tr¨adet och st¨anger ner applikationen, s˚a ska anv¨andaren n¨ar denne loggar in igen hamna p˚a samma position. Denna funktionalitet b¨or ¨aven d˚a finnas med i webbapplikationen. F¨or att alltid veta var anv¨andare ¨ar positionerad s˚a har jag valt att spara s¨okv¨agen till noden i en cookie. S¨okv¨agen d¨ar sparas med informationen f¨or varje nod: vad det ¨ar f¨or nod-typ vad noden har f¨or namn (t.ex Mitt Arkiv”) samt vad den har f¨or id (t.ex ”112”). F¨or att minimera antalet tecken sparade i cookien har jag valt att representera nodernas typer som bokst¨aver: ’A’ representerar ’Archive’, ’F’ representerar ’Folder’ etc. Exempel p˚a en

4.3. Serverkommunikation 33

str¨ang som kan representera den s¨okv¨ag som sparas i cookien ses nedan.

[#Mitt Arkiv,112,A##testmap,4,F##testdokument,65,D#]

Ett problem ¨ar att man inte kan h¨amta hela data-tr¨adet till den position d¨ar anv¨andaren befinner sig utan att f¨orlora prestanda. D¨arf¨or har jag valt att bara h¨amta information om den position d¨ar anv¨andaren st˚ar f¨or att sedan generera ett tr¨ad med den s¨okv¨ag jag har. Om anv¨andaren d˚a backar ett steg i tr¨adet s˚a kommer den komma till en mapp d¨ar endast f¨or¨aldrar-noden till noden anv¨andaren kom ifr˚an finns. Om det ska finnas fler noder i vyn kommer dessa visas s˚a fort f¨orsta pollen kommer fr˚an servern.

Kommunikation

All kommunikation g˚ar via ett internt gr¨anssnitt. Detta ¨ar f¨or att den del som sk¨oter kommunikationen mot servern enkelt ska kunna bytas ut. Anledningen till att man skul-le vilja byta ut kommunikationsmoduskul-len ¨ar om man beslutar sig f¨or att byta logik som sk¨oter Comet-uppkopplingen. Ett fall kan vara att man skapar en telefonapplikation som anv¨ander sig webbapplikationens grafiska gr¨anssnitt men sj¨alv sk¨oter serverkontakten. S˚a ist¨allet f¨or att kommunikationsmodulen kommunicerar med servern s˚a kommunicerar den med telefonapplikationen. Eftersom telefonen har tillg˚ang till st¨orre lagringsutrymmen och en databas s˚a skulle man teoretiskt kunna g¨ora en mobilapplikation som ¨ar snab-bare och b¨attre ¨an den mobila webbapplikationen men som samtidigt beh˚aller samma anv¨andargr¨anssnitt.

4.3

Serverkommunikation

I detta kapitel kommer valet av Comet-bibliotek att motiveras samt en beskrivning hur den mobila webbapplikationens kommunikations-protokoll mot servern ¨ar uppbyggt.

4.3.1

Val av Comet bibliotek

F¨or att integrera comet i webbapplikationer s˚a finns det ett flertal olika JavaScript bib-liotek s˚asom ett comet plugin till JavaScript biblioteket jQuery (http://jquery.com/)

4.3. Serverkommunikation 34

och dojo toolkit (http://www.dojotoolkit.org/). F¨or att kunna utnyttja de f¨ordelar som f¨oljer med GWT s˚a kr¨avs att comet-koden skrivs i GWT. Detta f¨or att kunna nyttja GWTs f¨ordelar med Deferred Binding etc. D¨arf¨or har jag begr¨ansat mitt val av comet-implemetation till att bara titta p˚a bibliotek skriva f¨or GWT. Det finns flera comet-bibliotek f¨or GWT. De som jag har tittat p˚a ¨ar gwteventservice, gwt-comet och rocket-gwt. Eftersom b˚ade GWT och webbteknologin utvecklas snabbt s˚a ¨ar det en stor f¨ordel att anv¨anda ett uppdaterat bibliotek. Denna faktor leder till att rocket-gwt g˚ar bort som val eftersom dess senaste version ¨ar fr˚an 2008. I Mobile Documents vanliga webbapplikation s˚a anv¨ander den sig av gwt-comet. Av den anledning att Mobile Docu-ments redan anv¨ander sig av gwt-comet s˚a faller valet p˚a att anv¨anda denna applikation. Detta g¨or att jag kan ˚ateranv¨anda mycket av den kod som redan finns p˚a serversidan.

Comet-biblioteket visade sig fungera utm¨arkt p˚a alla webl¨asare f¨orutom p˚a Android, vilket ¨an en g˚ang visar att ¨aven att webbl¨asarna (mobile Safari och Android Browser) ¨ar byggda p˚a samma grund s˚a beter dom sig annorlunda. Efter en dialog med skaparen av gwt-comet s˚a fick jag tipset att felet kan bero p˚a ett fyllnads-problem. I biblioteket finns det redan en fix f¨or ett liknande problem som uppst˚ar i webbl¨asaren Chrome. I Chrome beror problemet p˚a att webbl¨asaren m˚aste l¨asa in MIME:n (information om vilken typ av data som transaktionen inneh˚aller) innan den b¨orjar processa data. D¨arf¨or m˚aste man fylla ut b¨orjan av comet-svaret med det antal bitar som MIME:n f¨orv¨antas vara. F¨or att r¨akna ut hur m˚anga bitar man m˚aste skicka innan webbl¨asaren svarar, s˚a finns en testallgoritm f¨or detta i gwt-comet. Vid test av Android s˚a blev resultatet 4097. Testet gjordes b˚ade via en Motorola Droid med Android 2.1 och via emulator p˚a datorn och alla tester visade p˚a samma bit-antal. Varf¨or webbl¨asaren beh¨over l¨asa in dessa 4097 bitar har jag inget s¨akert svar p˚a, men det verkar som om den har en buffert p˚a ca 4kb som m˚aste fyllas f¨or att den ska skicka ett svar [33].

Ett specialfall skapas d¨arefter f¨or Android-telefoner.

4.3.2

Protokoll

Eftersom gwt-comet redan finns implementerat f¨or Mobile Documents webbapplikation (f¨or fullskaliga webbl¨asare) s˚a v¨aljer jag att anv¨anda mig till stor del av den logik som redan finns p˚a servern. F¨or att inte servern ska skicka en massa information till klienten som inte ¨ar av intresse f¨or klienten vid det aktuella tillf¨allet, s˚a kr¨avs att klienten talar om f¨or servern vad den vill ha uppdateringar om. Detta g¨ors genom att klienten skickar information om vilken nod den f¨or tillf¨allet tittar p˚a. De argument som skickas till servern d˚a ¨ar:

4.3. Serverkommunikation 35

int arhiveId int nodeId

int archiveRevision int contentRevision

Med variablerna archiveId och nodeId s˚a beskriver man vilken node som det ¨ar man vill ha information om. Samt att man m˚aste tala om f¨or servern vilken revision man sj¨alv har tillg˚ang till. Eftersom man n¨ar man startar upp applikationen inte har lagrat n˚agon nod-data s˚a kommer webbapplikationen s¨atta revisionsnumren som skickas till noll. Detta resulterar i att servern svarar med den fullst¨andiga informationen som finns om positionen. P˚a detta s¨att kan man anv¨anda pollen som ett vanligt asynkront anrop d˚a den kommer att returnera direkt om revisionsnumren inte matchar. Om man d¨aremot skickar de senaste revisionumren s˚a kommer inte servern att svara f¨orr¨an det har skett en uppdatering av revisionerna p˚a serversidan.

Det kan finnas v¨aldigt mycket information i en nod (t.ex. s˚a kan en nod inneh˚alla 250 mejl), att skicka 250 mejl i en klump fr˚an servern till klienten, resulterar i v¨aldigt mycket information som ska skickas samtidigt. Eftersom man kan anta att anv¨andare i de flesta fall endast vill titta p˚a de senaste inkomna mejlen, s˚a ¨ar det v¨aldigt on¨odigt att h¨amta alla anv¨andarens mejl. D¨arf¨or s˚a har jag l¨ost detta genom att implementerat tre nya argument som skickas med pollen:

boolean mobileWeb = true; int offset

int limit

Argumentet mobileWeb s¨ager till servern att anropet kommer fr˚an en mobil webbklient. Detta beh¨ovs d˚a vi anv¨ander samma server som den vanliga webbklienten men d˚a flera saker i hanteringen av pollen skiljer sig. Argumenten offset och limit fungerar s˚a att man bara beg¨ar de barnelement till en nod som befinner sig mellan positionen offset och offset+limit. D.v.s. offset best¨ammer varifr˚an serven ska b¨orja r¨akna och limit best¨ammer hur m˚anga element man vill att servern ska svara med. P˚a detta s¨att kan man beg¨ara ett litet block av element ˚at g˚angen.

Eftersom pollen kan anv¨andas b˚ade f¨or att h¨amta information och f¨or att uppdatera data s˚a m˚aste klienten veta vad det ¨ar f¨or data som den f˚ar tillbaka. F¨or att h˚alla koll p˚a detta s˚a skapas en tillst˚andsvariabel pollState som kan anta v¨ardena:

4.3. Serverkommunikation 36

• newList V¨antar p˚a element fr˚an en ny nod.

• extendList V¨antar p˚a nya element fr˚an den nod vi st˚ar i. • listenOnUpdates Lyssnar p˚a uppdateringar av noden vi st˚ar i.

N¨ar man klickar p˚a en mapp som inneh˚aller 100 noder d¨ar den senaste arkivrevisionen ¨

ar 43 och contentrevisionen ¨ar 32, s˚a beter sig pollen s˚ah¨ar:

fr˚aga till server: pollState = newList;

&arhiveId=3&archiveRevision=0&node=14&contentRevision=0&

offset=0&limit=20&mobileWeb=true

N¨ar svar sedan kommer s˚a ¨andras tillst˚andet p˚a pollen till att lyssna p˚a uppdateringar f¨or de intressanta noderna:

fr˚aga till server:

pollState = listenOnUpdates ;

&arhiveId=3&archiveRevision= 43&node=14&contentRevision= 32&

offset=0&limit=20&mobileWeb=true

Om anv¨andaren t.ex. scrollar ner till sista noden som visas i listan s˚a kommer klienten att beg¨ara fler noder fr˚an servern.

fr˚aga till server:

pollState = extendList ;

&arhiveId=3&archiveRevision= 0&node=14&contentRevision= 0&

offset= 20&limit=20&mobileWeb=true

N¨ar sedan svaret kommer med de nya elementen s˚a ¨andra pollens l¨age till updatering igen ¨over det spann av element som ¨ar h¨amtat

4.3. Serverkommunikation 37

fr˚aga till server:

pollState = listenOnUpdates ;

&arhiveId=3&archiveRevision= 43&node=14&contentRevision= 32&

offset= 0&limit= 40&mobileWeb=true

4.3.3

Kommunikationsanrop

Kommunikationen sker huvudsakligen med hj¨alp av tv˚a anrop: startpoll och handlepoll. Dessa modulariserar val av backend i mobila plattformen. Implementationen fungerar s˚a att pollen startas och skickas till serversidan med ett antal argument i funktionen startPoll. N¨ar det sedan sker en f¨or¨andring p˚a servern s˚a kommer servern returnera ett paket som inneh˚aller de f¨or¨andringar som har skett till en funktion handlePoll.

Att f¨or¨andringarna returneras till en frist˚aende funktion och inte som ett asynkront anrop till den anropande funktionen visade sig ge en del f¨ordelar.

Till exempel har det under exjobbets g˚ang utf¨orts tester att l˚ata webbapplikationen kommunicera med en Android-applikation som i sin tur sk¨oter kommunikationen med servern. D.v.s. ist¨allet f¨or att webbapplikationen kommunicerar med servern s˚a kom-municerar den med Android-applikationen som om den vore en server. Det enklaste s¨attet att kommunicera mellan en webbapplikation och en Androidapplikation ¨ar f¨oljande: Android-applikationen kan skapa JavaScript-funktioner som webbapplikationen kan an-ropa. P˚a detta s¨att s˚a kan vi skicka en startPoll till Android-applikationen. N¨ar sedan Android-applikationen har registrerat en f¨or¨andring meddelar den webbapplikationen om f¨or¨andringen. Detta g¨or den genom att injicera ett JavaScript-anropp i adressf¨altet. P˚a detta s¨att kan den kommunicera med funktionen handlePoll. Att det injiceras i adressf¨altet resulterar i att funktionen kommer att k¨oras direkt. Genom att kommu-nikationen g¨ors p˚a detta s¨att s˚a beh¨ovs ingen Comet-implementation vid kommunikation med en Android-applikation.

4.3.4

Uppdatering av listvy

N¨ar det kommer en meddelande fr˚an servern med ett flertal element som ska l¨aggas till i listan som visas, s˚a ¨ar det enklast att l¨agga till elementen en efter en i listan som den ¨

4.4. Cache 38

till ett nytt element. En l¨osning p˚a detta problem ¨ar att man kan ta bort listan fr˚an DOM-tr¨adet under tiden d˚a den ska uppdateras. Detta resulterar i att DOM-tr¨adet bara beh¨over att manipuleras tv˚a g˚anger. En g˚ang n¨ar listan tas bort och en g˚ang n¨ar den l¨aggs till. Nackdelen h¨ar blir att det p˚a flera webbl¨asare syns att listan f¨orsvinner innan den l¨aggs till igen, samt att scrollpositionen inte kommer att bibeh˚allas. Med ett enkelt JavaScript s˚a kan man spara scrollpositionen och sedan s¨atta den till sitt gamla v¨arde n¨ar listan lagts till igen. Dock kan detta ocks˚a leda till att man ser att scrollpositionen hoppar fram och tillbaka. Resultatet blir att man m˚aste v¨alja mellan snabbhet och bra anv¨andarupplevelse. Eftersom snabbheten ¨ar n˚agot man str¨avar efter f¨or att f˚a en bra anv¨andarupplevelse, s˚a anser jag att den motarbetar dess ursprungliga uppgift om den resulterar i d˚alig anv¨andarupplevelse. D¨arf¨or v¨aljer jag att l˚ata listan vara kvar i DOM-tr¨adet hela tiden.

4.4

Cache

F¨or att ¨oka hastigheten p˚a webbapplikationen samt f¨or att minska datam¨angden som skickas mellan server och telefon s˚a har jag implementerat en cache.

Cachen kommer utnyttja webbl¨asarens cache att lagra JavaScript-objekt. Cachen kom-mer att fyllas p˚a med data d˚a man navigerar runt p˚a sidan. Alla noder som laddas hem lagras i cachen med dess revisionsnummer. P˚a detta s¨att g˚ar det snabbt att navigera in i en nod d¨ar anv¨andaren tidigare varit. Dock kommer cachen att f¨orsvinna s˚a fort anv¨andaren st¨anger ner sidan. Mer optimalt hade varit att lagra informationen i en data-bas. P˚a detta s¨att s˚a skulle man kunna spara information i minnet ¨aven d˚a webbl¨asaren ¨

ar nedst¨angd. Att lagra information fr˚an hemsidor i en databas ¨ar en del av HTML5-standarden. D˚a tyv¨arr inte alla de prioriterade webbl¨asarna st¨odjer detta s˚a v¨aljer jag att inte implementera lagring i databas. Anledningen till att jag inte g¨or en databaslagring f¨or de webbl¨asare som st¨odjer det ¨ar att den kommer bli s˚a olik cache-lagringen vilket leder till mer utvecklingstid, vilket inte fanns tid till under examensarbetet.

All data i cachen har jag valt att lagra i en tr¨adstruktur. Detta eftersom listan i sig ¨ar ett tr¨ad. Att lagringen sker i en tr¨adstruktur g¨or att det g˚ar snabbt att hitta till den aktuella nodens f¨or¨aldrar och barn, vilket ¨ar det som man kommer att g˚a till d˚a man navigerar runt i tr¨adet. Dock s˚a tar det l˚ang tid att s¨oka upp en nod som inte ¨ar f¨or¨alder eller barn till den aktuella noden. F¨or tillf¨allet finns det inga s˚adana fall, men kommer om applikationen vidareutvecklas med s¨akerhet att uppkomma.