Det skal du lige være opmærksom på, inden du begynder på en moderne Android-app

Der er en række muligheder og faldgruber, det er værd at holde sig for øje, inden udviklingen af en Android app-begynder. Dem fortæller ITU-lektor her nærmere om.

Måske går du med en lille Android-app i maven, der skriver på at komme ud? Inden du sætter dig til tasterne i håbet om at blive den næste Flappy Bird til Googles platform, så er der en række ting, det er værd at overveje.

»Først og fremmest skal man tage stilling til, om der overhovedet er behov for en app. Man skal jo ikke udvikle den, bare for at udvikle den,« siger ekstern lektor på ITU Jacob Avlund, der underviser i Android-udvikling, og derudover er partner i firmaet Siblingsoft, som laver apps.

Som eksempel nævner Jacob Avlund en webbutik. Her er der ikke nødvendigvis behov for en app, der ligger permanent på folks mobiltelefoner, og som de først skal ind og hente via Google Play, hvilket er besværligt, og der er derfor større sandsynlighed for at de slet ikke orker. I stedet for at bruge tiden på app-udvikling, vil den være bedre brugt på at lave en hjemmeside i responsivt design, der også fungere på en mindre mobil-skærm, påpeger han.

Til udvikling af app’en er der forskellige værktøjer, man kan anvende. Hvilket der er mest egnet, afhænger af app-typen. Hvis det eksempelvis er et grafisk krævende spil eller en app der benytter ny funktionalitet, så kan det være en god idé at kode den direkte til Android-platformen i Java - eksempelvis med Eclipse og Android Development Tools (ADT), selvom det kan være en omstændelig proces, fortæller Jacob Avlund.

I den forbindelse understreger han, at det er vigtigt ikke at undervurdere, at langt de fleste Android- og iOS-udviklere koder native Java/Objective C som udgangspunkt. Og det vil sige, at det som virksomhed er nemmere at finde ressourcer, der kan det, og tilsvarende er nemmere for udviklere at få job med det.

HTML5

Men ofte kan lettere tilgængelige alternativer, være en mulighed. Eksempelvis kan app’en laves i HTML5 via udviklerværktøjet phonegap. Fordelen er, at det let kan testes i en browser, og at det kører nogenlunde uden videre, ikke bare på Android, men også på andre enheder, hvor HTML5 er understøttet, forklarer Jacob Avlund.

Dog kan en app, der bliver afviklet som HTML5 på telefonen, have nogle performence-udfordringer, og så bliver resultatet næppe heller en fuldstændig gnidningsfri integration med telefonens øvrige brugergrænseflade.

»Mit indtryk er, at man som regel godt kan se, når en app er lavet med Phonegap. Det er meget svært at lave noget, der ligner og specielt opfører sig som telefonens øvrige grænseflade. Man skal virkeligt have styr på sit CSS, hvis det skal se ordentligt ud,« siger Jacob Avlund.

Han tilføjer, at selvom HTML5 som sådan ikke understøtter eksempelvis adgang til info fra telefonens accelerometer, så har phonegap implementeret egen api til HTML5, der alligevel gør det muligt at få fat i eksempelvis data fra accelerometeret.

Hybrid-frameworks

En anden tilgang kan være de såkaldte hybrid-frameworks som Titanium. Her kan man skrive sin kode i javascript. Og den bliver også afviklet i telefonens javascript-fortolker, kombineret med native-kald til det underliggende styresystem, hvad enten det er Android, IOS eller i visse tilfælde Windows Phone, forklarer Jacob Avlund.

Lige netop Titanium understøtter dog ikke Windows Phone endnu, selv om det er på vej, fortæller Jacob Avlund.

Fordelen ved native-kaldene er, at telefonens egen brugergrænseflade bliver anvendt, og derfor kommer app’en også til at have samme udtryk, som den øvrige brugergrænseflade. Og så yder app’s lavet på denne måde relativt bedre sammenlignet med app’s lavet via Phonegap og i HTML5, vurderer Jacob Avlund.

»Et hybrid-framework som Titanium vil tit og ofte være godt nok, men det egner sig ikke til at lave store, grafisk tunge spil, der skal man stadig udvikle en native-app,« siger han.

Og så kan der være en anden udfordring med udvikling i et hybrid-framework. Jacob Avlund forklarer, at de af og til kan vise sig at anvende mindre officielle api’er fra Google og Apple, som egentlig ikke er ment til at skulle anvendes af andre end leverandørens egne udviklere. Formålet er tit at opnå en højere ydeevne på det færdige produkt, men problemet kan være, at disse api’er ikke fungerer i nye versioner af eksempelvis Android. Eller at de bliver udskiftet med andre.

»Og hvis du skal bruge noget af det allernyeste funktionalitet, så skal du vente på, dem der laver hybrid-løsningerne, får fulgt op på, hvad man kan på forskellige platforme,« siger Jacob Avlund.

En anden udfordring

En anden udfordring, primært på Android, som Jacob Avlund kalder klassisk, er de mange forskellige skærmstørrelser, der skal tages højde for, og de forskellige Android-versioner, der er på markedet. Hvis app’en ellers skal virke ordentlig på tværs af forskellige enheder, så er det en rigtig godt idé at teste den godt, fortæller Jacob Avlund.

Hvis det bare er til intern brug i en virksomhed, så er det dog ikke nødvendigt at bruge tid på at teste og understøtte eksempelvis ældre versioner af Android, påpeger han.

Sidst men ikke mindst, så er det ikke kun formålet med app’en, man bør have for øje, når udviklingsmetoden skal vælges.

»Man skal ikke undervurdere den fordel det er ikke at skulle til at lære et nyt programmeringssprog. Hvis ellers kravene til app’en er til forhandling, så er det en rigtig god idé at vælge et programmerings framework, der understøtter et sprog, man kender godt, eksempelvis javascript. Det kan tit og ofte lette hele udviklingsprocessen enormt og gøre en stor forskel,« siger Jacob Avlund.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ole Dahl

Som eksempel nævner Jacob Avlund en webbutik. Her er der ikke nødvendigvis behov for en app, der ligger permanent på folks mobiltelefoner, og som de først skal ind og hente via Google Play, hvilket er besværligt, og der er derfor større sandsynlighed for at de slet ikke orker. I stedet for at bruge tiden på app-udvikling, vil den være bedre brugt på at lave en hjemmeside i responsivt design, der også fungere på en mindre mobil-skærm, påpeger han.

vil man udvikle tema design til mindre mobilskærme skal man ikke bruge responsivt design men lave et tema der er skræddersyet til små skærme så brugerne undgår hente store mængder data ned i form af bla. billeder der derefter krympes til de passer.

  • 5
  • 1
Tore Julø

Han tilføjer, at selvom HTML5 som sådan ikke understøtter eksempelvis adgang til info fra telefonens accelerometer, så har phonegap implementeret egen api til HTML5, der alligevel gør det muligt at få fat i eksempelvis data fra accelerometeret.

Det er muligvis sandt hvis brugeren benytter den hæslige Android standard browser i visse af dens mange afskyelige udformninger, men hvis man benytter Chrome, burde det være muligt. Der er en ældre artikel om det på HTML5Rocks.

Der er også adgang til kamera og mikrofon (via getUserMedia), mulighed for fil-upload direkte fra galleri eller kamera, geolokation, vibration, hardwareaccelererede animationer (via CSS), WebGL og tonsvis af andre ting. Med Appcache kan man gemme sine statiske assets som css, js, fonte og ui-billeder i browseren, så de ikke kun loader hurtigere, men kan bruges når man er offline. Derudover er der localstorage, indexedDB og filewriter.

Hvad man ikke har adgang til, er OS-specifikke ting som f.eks. at udsende et share-intent, modtage push-beskeder samt at benytte kort-funktionalitet (kort som i Google Maps) der kan nærme sig noget der ligner native ydelse. Det er tre ting jeg håber at se bliver muligt inden alt for længe. Både Safari og Chrome understøtter allerede push-beskeder på MacOS og Windows og ordentlige WebGL-kort er også noget der ikke kan ligge alt for langt væk, men intents er lidt værre. Web-intents projektet er, så vidt jeg ved, helt stoppet, så der skal findes på noget andet.

  • 0
  • 2
Tore Julø

Og hvis man ikke benytter nogen af dem?

Som i at man slet ikke bruger en browser? Ja, så kan web apps ikke bruges til ret meget. Ellers bruger man nok en anden. Der er mange forskellige browsere og de understøtter hver især en delmængde af de nye browserfunktioner. Hvis man vælger en browser der understøtter færre funktioner, så vil man støde på på ting man ikke kan, men som folk der bruger andre browsere godt kan.

  • 1
  • 2
Johnnie Hougaard Nielsen

Og hvis man ikke benytter nogen af dem?

Så afhænger det jo af om den pågældende browser understøtter den efterspurgte "HTML5" funktion. Det kan lidt være en blandet landhandel, så der er risiko for at en HTML5 webapp må sige at den aktuelle browser (eller aktuel hardware) ikke understøtter funktionen. Til gengæld har den chancen for at virke på flere forskellige mobil OS, hvilket kan være til gavn for de mindre platforme, som ikke nødvendigvis bliver ladt tilbage.

  • 1
  • 0
Jesper Sandberg

Nu har jeg været undervisningsassistent for Jacob de sidste par semestere kurset har været udbudt og synes det er rigtig fint at der her kommer lidt fokus på nogle ting folk ofte laver. Jeg er derudover også undervisningsassistent på Dynamic Web Development kurset på ITU, der netop har stor fokus på "mobile first" konceptet, så jeg har godt indblik i netop begge retninger. Som Jacob netop også siger, er det vigtigt at lave en analyse på hvilke behov der er for app'en, da det ofte ikke er værd at lave en standalone native app, men blot have en god web app til de besøgende. For lige at lave lidt skamløs reklame, har jeg et lille firma der kan hjælpe indenfor alle behov der måtte være for dem der har indset at mobil er fremtiden :-)

  • 0
  • 0
Rasmus Kaae

Jeg synes det mest interessante er at mange virksomheder ikke overvejer om der er behov for en app. En webshop, bilforhandler eller tilsvarende der blot ønsker at udstille varer og ikke tilknytte yderligere funktionalitet bør holde sig langt væk fra apps!

  • 0
  • 0
Martin Bay Pedersen

Jeg undrer mig over hvor den opfattelse kommer fra - at man med responsivt design henter den samme mængde data ned, uanset hvor stor skærmen er. For det er altså ikke tilfældet..

Jeg peger ikke fingre :) jeg har set mange andre sige det samme. Men måske kan du fortælle mig hvor du har informationen fra?

  • 1
  • 0
Tore Julø

Det skyldes at man med responsivt design som regel blot mener brugen af CSS mediaqueries, i hvilket tilfælde man ikke har kontrol over størrelsen af indlejrede billeder. HTML'en er uændret, men det bliver benyttet andre CSS regler.

Man kan naturligvis implementere server-side komponenter og/eller hente billeder og lignende asynkront via Javascript, når man kender størrelsen på brugerens skærm eller viewport, men dette er ikke hvad der normalt menes med responsivt design.

  • 0
  • 1
Martin Bay Pedersen

Det skyldes at man med responsivt design som regel blot mener brugen af CSS mediaqueries, i hvilket tilfælde man ikke har kontrol over størrelsen af indlejrede billeder.

Nej ok, så er det nok et spørgsmål om gradbøjning.

Man kan jo ændre src på baggrundsbilleder via mediaqueries, og så kan man, som du nævner, bruge andre metoder som ikke nødvendigvis er relateret til CSS. Men det betyder jo ikke, at de ikke tæller med i setuppet med responsivt design.

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