Derfor skal du kode mobile apps i HTML5

Ved at pakke en webapplikation ind som native kode på smartphones, kan man genbruge koden på alle platforme. Se her hvornår det giver mening.

Du skal udvikle en lækker mobil-applikation og skal dække Android, iOS og måske også Windows Phone.

Det betyder normalt, at du enten skal kode både i Android-Java, Objective-C og C#, eller bruge et værktøj til at oversætte koden til flere platforme, med svingende held.

Men hvorfor ikke bare holde dig til webteknologier som Javascript og HTML5, som kan køre på alle platforme, og så pakke det ind som en normal, lokal applikation?

Sådan lød det fra Kristian Langborg-Hansen på konferencen Community Day i sidste uge. Han har ved siden af sit arbejde som udvikler hos Schneider Electric blandt andet skrevet undervisningsbøger om HTML5.

»Du kan lave helt rigtige apps som Angry Birds og Wordfeud med Javascript og HTML5. Det er teknologier, som de fleste af os kender, og så kommer du ud på alle platforme på én gang. Med lidt held også Blackberry,« forklarede han de fremmødte udviklere i salen.

'Yes we can' tilgå kameraet

Han jog med Obama-sloganet ’yes, we can’ en pæl gennem nogle af de myter, han støder på, når han nævner konceptet native applikationer kodet med HTML5.

»Kan man pakke det som en rigtig app? Ja, man kan. Kan det sælges i App Store? Ja, og for brugeren ligner det fuldstændig en normal app. Kan det tilgå kamera og GPS? Yes – det kan vi også, der er API’er til det,« forklarede han.

På nej-fronten understregede han, at brugerne ikke først skulle åbne deres browser eller være online for at køre sådan nogle apps.

»Er det så ikke super langsomt? Nej – for på telefoner i dag er browseren som et ekstra lag ikke det, som vil give problemer,« sagde han.

Læs også: Sådan laver Version2 gratis apps til Android og iPhone

Helt rosenrødt er det dog ikke at bruge webteknologier til applikationen, for Write Once, Run Anywhere holder ikke. Selvom alle telefonernes browsere kan køre koden, kan det ske på lidt forskellig vis, fordi det ikke er de samme browsere overalt.

»Det er som dengang, man skulle tilpasse websider til forskellige browsere. Der er også skærmstørrelsen at tage hensyn til. Med smartphones ved du ikke engang, om skærmen er bred eller høj,« forklarede han.

I nogle situationer er en web-applikation også bare en dårlig idé, og så er det bedst at holde sig til den normale fremgangsmåde, lød rådet.

»Hvis du virkelig har brug for total kontrol over telefonen, trækker det i retning af native. For eksempel hvis du vil live-streame fra kameraet, eller at app’en bare skal tage et billede. Så er der ikke så meget grund til at køre HTML og Javascript ind over,« forklarede Kristian Langborg-Hansen.

Det samme gælder, hvis hastighed er meget afgørende, for eksempel hvis målet med applikationen er at plotte data i realtid, så selv en bette forsinkelse på 10 millisekunder er for meget. En applikation med meget beregning og kompliceret kode bør man også holde native.

»Hvis det meste er logik, er Javascript ikke førstevalg. Men hvis det mest er UI [brugergrænseflade, red.], så giver det mening,« lød budskabet.

Hvorfor lave en iPhone-brugergrænseflade?

Her ville han også gerne gøre op med mantraet om, at en smartphone-applikation skal have en brugergrænseflade som alle andre. Faktisk mente han, at det kunne give lige så meget mening at gå efter en brugergrænseflade á la webapplikationer, for dem har folk også masser af erfaringer med.

»Det skal ikke ligne en grim hjemmeside, men noget, som brugeren er vant til, og det kan man også sagtens. Hvorfor skal det ligne en iPhone-app, hvis man kan lave noget, der passer bedre til? Alle, der har en smartphone, har været på nettet og har brugt en web-app. Så det vil ikke være fremmed,« sagde han.

Selve kodearbejdet anbefalede han foregik med hjælp fra værktøjer som Sencha og Jquery Mobile. Han var selv lige skiftet væk fra Sencha, fordi det ikke understøtter Windows Phone, men var ellers glad for det. Så bliver koden automatisk pakket ind som en applikation, som så åbner en browser og kører web-koden.

»Det er rigtig skægt at skrive det hele fra bunden i en blank editor – men kun indtil der kommer testere på, som finder en masse fejl,« forklarede Kristian Langborg-Hansen.

Bruger man Jquery Mobile er værktøjet Phonegap en stor hjælp til at få lavet applikationer til de forskellige platforme, så man ikke selv skal sidde og kompilere og uploade, lød rådet.

Og til alle dem, der får nervøse trækninger ved tanken om applikationer bygget på Javascript var budskabet, at det sagtens kan lade sig gøre - om nødvendigt ved at skrive i Java først og så få det oversat.

»Man kan godt lave dårlig Javascript-kode. Men man kan også bare stramme sig an og lave god Javascript-kode,« sagde han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Bjerregaard

Nu udvikler jeg en stor mobil web applikation til daglig, og jeg må indrømme at jeg endnu har til gode, at prøve en applikation udviklet med PhoneGap, eller Jquery Mobile, eller lignende frameworks, som jeg synes var god, eller bare nogenlunde brugbar. Synes at de ting jeg har prøvet føles som at kærtegne et stykke viskelæder. Men jeg er meget åben for gode links, til apps der virkeligt viser det bedste fra de frameworks (hint hint).

  • 0
  • 0
Jacob Christian Munch-Andersen

Jeg har personligt aldrig brugt frameworks til webudvikling, man mister for meget kontrol med hvad der rent faktisk foregår.

Jeg vil dog også sige at blandt brugerne af den slags frameworks er begynderudviklere generelt kraftigt overrepræsenteret. Når de fleste brugere er begyndere bliver gennemsnittet af applikationer derefter, men det betyder jo ikke nødvendigvis at man ikke kan lave noget fornuftigt hvis man ved hvad man foretager sig.

  • 2
  • 5
Kim Madsen

Jeg har altid syntes at udvikling af applikationer via HTML, Javascript og CSS har været en forfejlet mission.

Det er min overbevisning, at hvis et udviklingsmiljø gør tingene vanskeligere for en, sværere at debugge, sværere at dokumentere, sværere at udvikle i første omgang, så er der noget galt med det udviklingsmiljø.

Jeg er af den skole at jeg vil fokusere på funktionalitet, og ikke på at slås med/mod udviklingsmiljøet, og det er den følelse jeg har hver gang jeg udvikler i HTML/Javscript/CSS. Debugging og browser kompatibilitet er nogle af de væsentlige issues, men ikke de eneste. DOM modellen hvor Javascripts tillades at oprette og overrule hvad som helst hvor som helst, er en rod til mange potentielle problemer. Inkluder en ekstern JS pakke, og din applikation kan begynde at opføre sig fuldstændigt anderledes, selv i områder som intet har med den eksterne JS pakke at gøre.

Istedet har jeg en del år advokeret for Adobe's AIR løsning. De har lavet en cross platform løsning, som faktisk virker rigtig godt, med fuld GPU accelleration, adgang til underliggende platform APIier m.m.

Men idag er jeg nok ved at vende tilbage til mine rødder... Jeg har altid syntes at Delphi har været det udviklingsværktøj af alle, som giver mig mulighed for på kortest tid at lave en prototype og flytte denne til at blive en fuldt funktionel releasebar applikation. Man slås efter min mening mindre mod udviklingsmiljøet, og kan bruge sin tid på funktionalitet, og man er ikke låst fast, hvis de medleverede biblioteker mangler een eller anden specifik native funktionalitet. Så deklarerer man den og så er der adgang til den.

Delphi har, indtil XE2 været fokuseret på Win32. Men fra XE2 kan Delphi nu også krydskompilere til Win64, MacOSX og IOS. I nærmeste fremtid er det Embarcaderos plan at levere support for Android.

Det er værd at bemærke, at det er muligt at lave en application med een source code og med ingen eller meget få ændringer, rekompilere til en anden platform.

En side gevinst er at der findes en gratis, open source 99% Delphi kompatibel compiler (FreePascal - www.freepascal.org) som giver dig mulighed for at tage din source kode og rekompilere til andre targets end dem som Delphi XE2 direkte understøtter, inkl. Linux, FreeBSD, WinCE, WII, Java m.m. Dog kan der være udfordringer hvis du bruger Delphi 3.parts biblioteker da ikke alle er porterede til FreePascal.

Men da Embarcadero officielt understøtter/vil understøtte Win32, Win64, MacOSX, IOS (iPhone/iPad/iPod Touch) og Android, og har på roadmap at understøtte Linux, så er hovedparten af alle interessante platforme for de fleste applikations udviklere på listen.

Check www.embarcadero.com

mvh
Kim Madsen
kbm@kbmitexperts.dk

  • 6
  • 1
Karsten Bo Andersen

Vi har en APP til Android som communikere med en GSM controller via SMs beskeder, dette virker fint på Android, Ved installation spørger Android om det er OK at denne APP bruger funktioner på telefonen som kan koste penge.
Dette kan man ikke på Iphone, så derfor må Iphone brugere sende SMSer manuelt og ikke have den smarte APP http://www.danamp.com/Velkommen/index.php/danampdownloads
Kan man løse dette problem ved at bruge HTML5 ?

  • 0
  • 0
Lars Bjerregaard

Den nye LinkedIn app til iPad er 95% html5 og den er virkelig lækker.

Her er lidt om den:
http://venturebeat.com/2012/05/02/linkedin-ipad-app-engineering/


Men artiklen siger ikke noget om, hvorvidt klienten er deres egen handcrafted HTML kode, eller om de bruger et rigt framework til klienten. Det er det som er det interessante for mit vedkommende. Jeg har prøvet diverse demoer, fra Jquery Mobile og andre, og er mildt sagt ikke imponeret. Jeg kan godt se hvad de prøver at gøre, jeg synes bare ikke de slipper godt fra det. Og de PhoneGap apps jeg har prøvet betragter jeg som rent junk. Prøv f.eks. Version2's app, og læs dens ratings på Google Play. Det strander altid meget hurtigt med elendig performance, og en touch brugeroplevelse som er helt ødelagt. Det kan man ikke bruge til noget seriøst. Så jeg venter stadig på et par links til noget der er rigtigt godt, med disse frameworks, helst installerbart på min Android smartphone.

  • 0
  • 0
Michael Lykke

Det er lidt spøjst at artiklen påstår app'en er stort set ren HTML5 fordi hvis man nu åbner ipa pakken op og kigger lidt på indholdet så indeholder den rigtige mange NIB filer - Både til hele views såvel som table-cells. NIB filer er Interface Builder filer der indeholder det visuelle interface til et view. Faktisk er der umiddelbart ikke meget HTML at finde i selve app'en, men derimod en del tableviews som netop 95% af deres app består af...

  • 0
  • 0
Michael Lykke

Lige netop emnet omkring native vs hybrid vs HTML5 er noget der kan skrives tykke bøger om så derfor er det umuligt at komme ind på alle punkter i en kommentar. Med det sagt så er jeg ret uenig i indlægget.

Rent teknisk så er det muligt at lave en app baseret på HTML5 og tilhørende teknologier men der er fortsat meget langt fra en HTML5 app til en native app - Både hvad angår performance såvel som UX. Netop UX er af afgørende betydning på de mobile enheder. Uanset hvor meget man forsøger at efterligne en native app ved at simulere en normal app så er det altid meget tydeligt når det sker og det går voldsomt udover brugeroplevelsen og den effektivitet brugeren kan navigere med.
Det er rigtigt at folk er vant til websites men folk er også vant til applikationer på deres computere og mange andre ting - Det betyder ikke at en webløsning er den rigtige løsning til alt. På samme måde som applikationer på din Windows og Mac computer ikke er lavet i HTML5, af åbenlyse årsager, så gør det samme sig gældende på smartphones.

Hvis din app på ingen måder benytter sig af standard UI elementer og den fastsætter sin helt egen navigering så vil der være situationer hvor en HTML5 app kan være en løsning. Men er det tilfældet så skal man virkelig spørge sig selv om man opnår den mest effektive brugeroplevelse og UX. Faktum er at en bruger af fx en iPhone eller en Android telefon forventer en bestemt måde at navigere på, på samme måde som en Windows bruger forventer en bestemt placering af menuer, hvordan musen fungere m.m. Det er den forventning man som udvikler/producent skal leve op til hvis man ønsker at give brugeren en så transparent oplevelse som muligt og det er netop her at en stor del af problemerne med HTML5 apps opstår. Uanset hvor meget du forsøger at simulere en native oplevelse så vil der altid være smpå variationer der mærkes tydeligt af brugeren.

Det er på tide at forstå at HTML5 er ikke en magisk løsning der pludselig gør at dit team af webudviklere formår at udvikle den ene kvalitets-applikation efter den anden. Det er og bliver en second-rate løsning både hvad angår UX, performance, udvikling m.m.
De fleste ved idag at skal man lave et website så foregår det via HTML, CSS, JS m.m. På samme måde bør folk snart forstå at hvis du vil udvikle en applikation til en smartphone så gøres det i de rette teknologier som dikteres af platformen - Det rigtige værktøj til den rigtige opgave.

Hele facinationen af HTML5 bunder ofte i en misforstået tanke om at det er et nærmest magisk værktøj der kan udvikle alt fra websites, mobilapplikation til det nye playstation spil - Men det er altså "bare" en opgradering af HMTL standard - No more, no less.
Jeg kan sagtens forstå direktørens drøm om at kan få hele sit hold af webudviklere til pludselig at være hardcore applikations udviklere, men det er og bliver drømmen om utopia. Udvikling af mobil applikationer kræver et helt andet sæt kompetencer både hvad angår det tekniske men i endnu højere grad på UI/UX fronten.

I øvrigt er udvikling af en HTML5 app ikke noget der bare lige sker med et par linier HTML - Der kan være store forskelle mellem de mange forskelle browsere og versioner af det underliggende OS at man skal bruge enormt mange ressourcer på bare at få det til at virke odentligt på 80-90% af enhederne - Alt sammen fordi man nægter at bruge det rette værktøj til opgaven.
Alene det faktum at du skal replikere hele UI miljøet fra bunden gør HTML5 til et dårligt valg i langt de fleste situationer - Du går glip af at kunne bruge en rigtig debugger, performance profiler, interface builder og de mange lignende værktøjer(Afhængig af om vi snakker Android, iOS eller WP).
Du kan ganske givet benytte dig af frameworks som Phonegap, Titanium, Sencha osv. men de åbner op for en helt ny verden af problemer - Og i sidte ende vil du ende med en app der bærer præg af laveste fællesnævner, ringe peformance, begrænset muligheder osv. Selv de hurtigste telefoner afvikler HTML og JS MANGE gange langsommere end en native app - Hvor du i en native app kan scrolle igennem lange tunge lister uden problemer så vil du ofte opleve det "hakke" på selv korte lister i en HTML app - Og når man kan se performance forskelle alene her så vil du se dem endnu tydeligere på transitions, udregninger og mange andre steder.

Nøjagtig som det kræver andre kompetencer at udvikle en windows applikation så kræver det også andre kompetencer at udvikle mobil applikationer. Det er ikke en opgave for dine webudviklere med mindre de får tilført den fornødne viden(Ikke kun teknisk).

Det handler som regel om at man vil slippe for at skulle omskole folk til fx Objective-C, men så er det altså heller ikke mere kompliceret at lærer det sprog. En god udvikler vil kunne få fornuftigt styr på det basale i løbet af 2 dage. Udfordringen ligger i at lærer SDK'erne, UI mulighederne, brugernes forventning til den specifikke platform, forskellene imellem enhederne osv.

Som Lars Bjerregaard siger, så har jeg endnu ikke set et eneste eksempel på en virkelig god HTML baseret app som giver en oplevelse der er fuldt på højde med en native løsning.

  • 2
  • 0
Michael Lykke

I forlængelse af mit indlæg skal det kort nævnes at frameworks så som Titanium m.fl. der forsøger at benytte webteknologier til at kalde de native elementer er en ualmindeligt dårlig løsning der på ingen måder kan anbefales.
Her er virkelig tale om en løsning baseret på laveste fællesnævner. Det virker lovende når man starter men man finder hurtigt ud af at forskellene på tværs af platformene er ret store og det gør det umuligt at få den samme stump kode til at virke optimalt på tværs af alle enheder.

Write once, run anywhere forbliver en utopisk drøm - Langt de fleste Windows og Mac applikationer skrives fortsat heller ikke i Java - Som jo ellers i mange år var den våde drøm blandt både nørder og direktører.

  • 0
  • 0
Palle Simonsen

Nu kan jeg jo være særlig uheldig i valg af apps, men når jeg sammenligner UI på de apps jeg bruger mest: eBay, GPS, camera, FM radio, Webbrowser, Gmail, Exchange, DMI, RunKeeper, DSB Billet, Amazon Kindle og Spotify kan jeg ikke finde fællestræk, der går igen mellem alle apps, endsige næsten ingen fællestræk mellem apps parvist. Så jeg køber ikke argumentet om UI elementer.

Mht. performance af HTML5/CSS3 er der stor forskel mellem performance på iphone / ipads og low-end android og tildels også endnu hi-end android, hvilket bl.a. skyldes, at Apple glimrende udnytter HW acceleration i browseren. Så lige pt. er det sikrere at sigte efter og markedsfører sig som mobile enhanced webpage end app, hvis man er igang med HTML5. Men udskiftningen af devices går dog ret hurtigt og på de bedste, kan det være svært at se forskel.

Så det kan godt være, at "Utopia" til at starte med kun anvendes til nogle få mere specialiserede anvendelser, men mon ikke det breder sig ;)

  • 1
  • 1
Log ind eller Opret konto for at kommentere