• En eksisterende server-komponent har værdifulde data
• For at kunne eksponere data fra server-komponenten, udvikles der et API
• App’en henter data via API’et og viser disse på mobiltelefonen – gerne på en ny og frisk måde
• Ofte kombineres data fra server-komponenten med andre data eller andre services, så der skabes en helt ny service tilpasset en mobil kontekst

I mange af disse projekter skal API’et udvikles eller der eksisterer allerede et halvfærdigt API, som skal justeres og gøres klart.

Udviklingen eller opdateringen af API’et gøres alt for ofte til et rent teknisk spørgsmål – skal API’et laves som REST eller SOAP? Skal det anvende JSON eller XML? Disse spørgsmål er bestemt relevante og vigtige.

Men, de vigtige spørgsmål om hvilke forretningsmuligheder API’et kan åbne op for, hvordan laves API’et på en måde så det reelt kan genbruges stilles ofte ikke.

Min erfaring er, at der spildes mange penge og mange muligheder, fordi der laves dårlige, ikke-gennemtænkte og ikke-dokumenterede API’er. Fordi det er svært for ikke-teknikere at tjekke et API og svært at forstå det, så overlades API’et fuldstændigt til teknikere. Og fordi det mærkeligt nok tit er lav-status at udvikle API’er, så er det ofte ”den nye mand” eller junior-udviklere der laver API-opgaverne. Resultatet er dårlig kvalitet, manglende forretningsforståelse og spild af forretningsmuligheder.

Det lyder måske banalt – men min erfaring er, at API’et både nedprioriteres og at dets reelle værdi ikke forståes. Der er selvfølgelig undtagelser – men vi ser fere dårlige API’er end gode.

Var jeg projektleder eller forretningsudvikler i en større organisation ville jeg sikre mig, at følgende spørgsmål blev stillet inden man satte en udvikler i gang med at kode og dokumentere:

1. Skal der udvikles et API der senere kan genbruges?
2. Hvordan skal API’et dokumenteres, så det reelt kan anvendes af 3. part?
3. Vil det være en fordel at gøre API’et åbent eller lukket?
4. Hvilke services eller data er relevante? Kan vi forudsige kommende services?
5. Et API er en ”kontrakt” mellem forskellige IT-systemer – hvordan sikrer vi at vi overholder denne ”kontrakt”?
6. Hvordan tjekker man som ikke-tekniker et API?

Lad os tage spørgsmålene et ad gangen:

1. Skal der udvikles et API der kan genbruges senere?

Et  APIs funktion er at eksponere data eller services, så andre IT-systemer kan anvende disse data eller services på en enkel og sikker måde uden at skulle kende til de bagvedliggende systemer.

Lad os sige vi har en virksomhed der driver togdrift og vi er ved at lave et API, der kan eksponere data om køreplaner og forsinkelser. Vil det senere være relevant at eksponere disse data i andre IT-systemer? Vil vi måske skulle lave notifikations-services, vise køreplaner på elektroniske tavler eller på anden vis offentliggøre disse? Svaret på disse spørgsmål er uomtvisteligt ja. Derfor skal der selvfølgelig udvikles et API der kan genbruges senere.

Skal API’et kunne genbruges til andre projekter, skal det selvfølgelig skal dokumenteres og det skal kodes på en måde, så det kan anvendes uden at man har viden om interne systemer og terminologier etc.

Det er klart at det øger udviklingsomkostninger en smule at lave et generelt API. Men, det er minimalt i forhold til hvad der alligevel skulle investeres.

2. Hvordan dokumenterer vi et API, så det reelt kan anvendes af 3. part?

I 4 ud af 5 API’er vi har arbejdet med det sidste år, har den eneste dokumentation været en url og måske et kodeeksempel. Så, en god start er lave noget dokumentation. Næste udfordring er, at dokumentationen skal være skrevet til eksterne programmører. Ofte er navngivning og forklaringer indadvendt – forstået på den måde at API’et fortsætter med at bruge serversystemet termininologi og kontekst. Dette giver bare sjældent mening set udefra.

Et andet problem vi nogle gange møder er, at dokumentationen er et 400 siders langt dokument. Hvis man siddder med et lille 80 timers projekt – så kan det virke en smule overvældende.

Den dokumentation vi foretrækker er når dokumentationen er lavet som et lille website med små kodeeksempler og forklaringer. Vi har lavet en lille opave baseret på data fra Google Analytics Reporting Engine – og deres dokumentation er forbilledlig: https://developers.google.com/analytics/devguides/reporting/core/v3/

De typiske problemer ved implementeringen og dokumentationen af API’er er:

• Der er ingen dokumentation eller forældet dokumentation
• Navngivningen er dårlig
• Navngivningen er baseret på det interne systems (legacy)-terminologi
• Forskellige services og feeds i det samme API bruger forskellige navne for de samme data
• Der anvendes dansk navngivning

3. Vil det være en fordel at gøre API’et åbent eller lukket for vores virksomhed?

Tager vi igen eksemplet med jernbaneselskabet  – så er det oplagte svar ”ja”. Det er i selskabets interesse, at der er så mange services som muligt der integrere data om togafgange – så disse f.eks. vises sammen med tidsplaner for andre trafikformer, så de advarer kunderne om forsinkelser etc.

I nogle tilfælde er svaret selvfølgelig ”Nej”, hvis virksomheden igen lever af at sælge disse data. Men, igen kan det være en fordel at indbygge en generisk sikkerheds-model, så virksomheden kan begynde at sælge data via API’et til partnere.

Vores erfaring er, at langt de fleste virksomheder og organisationer har en interesse i at deres data bliver brugt og integreret i andre systemer. Derfor skal API’et være åbent.en det reelle værdi ikke forståes.’ styr på. Men, nu har jeg bare set fejlen en hel  har finansieret. et godt API, så se lige DS

4. Hvilke services eller data er relevante? Kan vi realistisk forudsige kommende services?

Den er faktisk sværere. I eksemplet med togdriften er det ret oplagt – men det er ofte svært at forudsige hvilke data der er relevante i kommende projekter eller IT-systemer. Hvis det er svært vil det ofte være klogt at lade være med at forsøge, og kun eksponere præcist de data der skal bruges her og nu.

Men, det er helt sikkert, at det kræver reel domæneviden og forretningsforståelse for at kunne afgøre hvilke data og services der skal gøres tilgængelige. Så, hvis man sætter den senest ansatte programmør til at udvikle API’et – så kan vedkommende helt sikkert ikke afgøre hvad der formentligt bliver relevant.

5. Et API er en ”kontrakt” mellem forskellige IT-systemer – hvordan sikrer vi at vi overholder denne ”kontrakt”?

En anden typisk problemstilling er, at der er udviklet en app som trækker på data fra et API  som en intern IT-afdeling har bygget. Et år senere holder app’en eller servicen op med at virke – fordi API’et er slukket, blevet ændret eller er flyttet til et nyt domæne. Med andre ord blev den ”kontrakt” som API’et er, ikke overholdt.

Det vigtigste er, at sikre sig hvem der har ansvaret for API’et. Hvem ved hvilke systemer der trækker på data fra API’et og hvem er ansvarlig for at API’et kører? På den måde er et API fuldstændigt ligesom et website eller en ydelse – der er nogen der skal ”eje” det”. Har virksomheden et overvågningssystem til sine websites er det oplagt at koble API’et på dette system, så det overvåges.

Dernæst skal der laves en plan for hvordan API’et opdateres og udvides. Den typiske løsning er, at man versionerer API’et, så man ved at f.eks. version 1.0 fortsætter med at fungere efter at version 1.1 er releaset.

6. Hvordan tjekker man som ikke-tekniker et API?

Som ikke-tekniker kan et API godt være svært at gennemskue. Men, i praksis er det faktisk ofte ret simpelt hvad det er der foregår. De fleste API’er vi arbejder med er åbne – og følger en helt simpel struktur:

1. App’en kalder API’et og efterspørger data
2. API’et sender data tilbage på struktureret form – typisk som XML eller JSON

Nogle gange laves der først et login, hvor API’et sender en ”Nøgle” tilbage. Og denne ”nøgle” bruges så ved alle kald.

I et enkelt REST API kan man kalde API’et direkt via et link. Prøv f.eks. at åbne følgende link i en browser: https://raw.github.com/currencybot/open-exchange-rates/master/latest.json.

Dette API returnerer en liste over valutakurser i forhold til US$ i JSON-formatet og kunne f.eks. bruges til at lave en simpel valutaomregner.

Prøv så at åbn websiden http://jsonformatter.curiousconcept.com/ og læg https://raw.github.com/currencybot/open-exchange-rates/master/latest.json ind i feltet “JSON data url” og klik på “Proces”. Nu formatteres JSON’en pænt – og det er tydeligt hvad der foregår.

Hvis det var din IT-afdeling der havde eksponerer centrale data for jeres virksomhed, vil du kunne tilgå data sådan.

Andre typer af API’er er “pakket ind”, så det er nemmere at arbejde med disse i udviklingsprocessen. Men, der er altid værktøjer, som kan åbne API’er – tjek med udviklingsafdelingen hvordan man kan gøre dette.

Morale – DSB har fattet det

Og for lige at komme med et eksempel på en organisation der virkelig har fået fuld valuta for at lave et godt API, så se lige DSBs fine DSB Labs: http://dsblabs.dk/webservices – og nyd hvor mange apps og services der trækker på API’et – http://dsblabs.dk/category/show/1281442209 – vel at mærke både apps og services som DSB har finansieret og apps og services som andre har finansieret.

iOS og egen hardware
Enheden består af:
1) et Wi-Fi-modul (Gainspan GS1011M) med tilhørende antenne
2) en mikroprocessor (Atmel ATmega328)
3) en LED, som er den ting, der faktisk bliver kontrolleret fra app’en.

Mikroprocessoren er programmeret til at konfigurere Wi-Fi-modulet og til at lytte efter bestemte kommandoer og tænde eller slukke lysdioden, afhængigt af hvilke kommandoer den modtager.
I en rigtig enhed ville både det Wi-Fi-modul og den mikroprocessor, der er brugt her, være udmærkede valg. Men lysdioden burde nok skiftes ud med noget mere brugbart: en kaffemaskine, garagedørsåbner, regnmåler eller lavalampe.

App’en
iPhone-app’en er ligeledes simpel og består grundlæggende af tre knapper; tænk, sluk og blink samt en stepper til at vælge antal gange lysdioden skal blinke. Der er også et tekstfelt, som bruges til at vise debug-informationer, så man kan se, hvad der foregår.

Hvordan fungerer det?

Systemet fungerer på den måde, at den eksterne enhed opretter et trådløst netværk, som iPhonen først skal kobles på. Det gøres ved at brugeren åbner applikationen “Indstillinger” og vælger det pågældende netværk. I dette tilfælde er netærket password-beskyttet, men det kunne også være åbent, så man ikke behøver password for at koble på.

Derefter startes app’en, og de forskellige knapper sender kommandoer til enheden (som UDP-pakker). Mikroprocessoren har konfigureret Wi-Fi-modulet som en UDP-server, og de datapakker, der bliver modtaget bliver sendt videre til mikroprocessoren, som enten tænder eller slukker lysdioden eller får det til at blinke et bestemt antal gange, alt efter hvilken kommando der blev modtaget.

Forbedringer
Hvis dette ikke bare var en simpel prototype, men en rigtig enhed, burde man lave et par forbedringer:
1) Lade app’en selv kontrollere, om der er kontakt en enheden. Det kan gøres ved mere eller mindre avanceret. Fx ved at lade app’en sende broadcast UDP-pakker og få et svar tilbage i et aftalt format som tegn på, at enheden er aktiv og på de samme netværk.
2) Bruge en mere robust kommunikation. Fx TCP-forbindelser i stedet for UDP-pakker.
3) Lade enheden koble sig på et eksisterende netværk. Når enheden starter kan den scanne for Wi-Fi-netværk og sende en liste til app’en, som spørger brugeren, hvilket netværk (og evt. password), der skal bruges. På den måde behøver man ikke at skifte væk fra det netværk, man normalt er koblet på i hjemmet eller på kontoret. Og det giver en væsentligt bedre brugeroplevelse.
4) Få en rigtig ingeniør til at bygge hardwaren i stedet for at lade en selvlært hobby-elektroniknørd som mig bakse noget sammen :)

Og det er en fremragende idé! En iPhone har en stor berøringsfølsom skærm og er et godt alternativ til en dedikeret kontrolenhed: udover skærm og multi-touch-interface, er der indbygget GPS, Wi-Fi, kamera, mikrofon, højttaler, accelerometer og gyro, SMS og mobiltelefon.
Og man har altid sin telefon på sig eller i nærheden.

Et eksempel på denne trend er, at firmaet Sonos, som laver trådløse musikanlæg, har besluttet helt at holde op med at lave deres egne controllere og vil for fremtiden kun benytte smartphones som controllere. (læs mere her). Og deres controllere er ellers glimrende. Men hardwaren i en iPhone eller iPod touch er endnu bedre. Og meget billigere…

I dette indlæg vil jeg gennemgå, hvordan man kan få en app til at snakke sammen med et stykke hardware.

Der er flere forskellige måder at integrere en iPhone eller iPad til eksternt hardware på. De mest brugte er:

1) Apples MFi-program
Den “rigtige” måde at gøre det på er ved at tilmelde sig Apples MFi-program. “MFi” står for Made for iPhone, Made for iPod eller Made for iPad.
Når man er registreret som MFi-udvikler, har man adgang til teknisk information og mulighed for at købe hardware, som gør det muligt at lave apps, som bruger enten Bluetooth eller stikket i bunden (“dock connector”) til at kommunikere med eksterne enheder.
Uheldigvis gør Apple det ikke nemt at blive medlem af MFi-programmet. De skal godkende ansøgerne, og man skal have forretnings- og udviklingsplaner klar. Og man skal betale for det. Og det er stort set umuligt at finde noget information om MFi-programmet, og hvilke krav og priser der er gældende. Det skyldes, at Apple gerne vil have, at det kun er “seriøse” firmaer med “modne” produkter, som bliver godkendt af Apple som “Made for iPhone”.
Desuden skal alle enheder indeholder en særlig chip fra Apple – som koster penge, og som stiller krav til den hardware, man bruger.

Fordele:
+ Giver den bedste brugeroplevelse, fordi det er meget nemt at parre en iPhone og en ekstern enhed.
+ Virker enten trådløst med Bluetooth eller med kabel via en dock connector.

Ulemper:
÷ Man skal være med i MFi-programmet.
÷ Nødvendig hardware og godkendelser koster en hel del.
÷ Alle enheder skal indeholde en Apple iAP-autentificeringschip.
÷ Svært at finde information: alt om MFi er dækket af fortrolighedsaftaler, så det er meget svært at finde konkrete priser osv.

Eksempler:
iHome iA17 clockradio-vækkeur
Sony S300BTX Bluetooth bilradio

2) Wi-Fi-modul
En anden mulighed er at lave en enhed, der kan kommunikere via Wi-Fi. Det er ret enkelt at lave en app, der bruger almindelige internet-protokoller (HTTP, TCP eller UDP) til at hente og sende data fra og til en ekstern enhed, der grundlæggende fungerer som en lille webserver.
Til gengæld kræver det, at iPhonen er tilsluttet det samme trådløse netværk som enheden. Det kan enten være enhedens eget netværk, eller det kan være et eksisterende netværk, som enheden også er koblet på. Og desværre er det ikke muligt at lave en app, som selv skifter til et bestemt netværk. Det skal brugeren selv gøre ved at gå ind i telefonens indstillinger.

Fordele:
+ Trådløs forbindelse. Endda med længere rækkevidde end Bluetooth.
+ Enheder kan kobles sammen med eksisterende Wi-Fi-netværk.

Ulemper:
÷ Bruger skal manuelt skifte Wi-Fi-netværk for at forbinde; det giver en kluntet brugeroplevelse.
÷ Ikke helt billigt: et Wi-Fi-modul koster ml. 100 og 300 kroner.

Eksempler:
AR.Drone fjernstyret helikopter
Sonos flerrums trådløst musiksystem

3) Audio
Det er jo både højttaler og mikrofon i hovedtelefonstikket, så det er faktisk muligt at sende og modtage information på den måde. iPhonen kommer til at fungere som et modem (for dem af jer, der er gamle nok til at huske den slags forældet teknologi).
Men fordi det går så langsomt, er det reelt kun en farbar vej for enheder, der skal overføre meget lidt information til iPhonen.
De teknisk interesserede kan læse mere her: Sensor Data to iPhone Through the Headphone Jack

Fordele:
+ Det er billigt

Ulemper:
÷ Information sendes og modtages meget langsomt. Kun ca. 5-10 tegn i sekundet!
÷ Det er ikke trådløst: enheden skal være forbundet via hovedtelefonstikket.

Eksempler:
Square kreditkortlæser

4) Bluetooth LE
En helt ny måde at kommunikere med eksterne enheder på er ved hjælp af Bluetooth Low Energy. Det er understøttet i iOS 5, og det er ikke nødvendigt at tilmelde sig MFi-programmet for at benytte Bluetooth LE.

Men der er et par ulemper:
÷ Det virker kun på iPhone 4S med iOS 5 eller nyere.
÷ Det kræver specielle (dvs. dyrere) Bluetooth LE-moduler.

Til gengæld er der også en masse fordele. Læs fx her Bluetooth 4.0 Solutions for Apple iOS Devices og her The amazing iOS 5 API nobody talks about .

Der er ved at blive lagt sidste hånd på designet, og derefter vil udvikleren gå i gang med at lave det om til WordPress-kode, så vi kan tage det i brug.

Vi synes selv, at det ser superflot ud – her er en smagsprøve:

(Klik for stor udgave)

Om jobbet:

• Du skal udvikle iOS apps
• Du vil indgå i vores team på lige fod med alle andre
• Du skal hurtigt kunne stå på egne ben og både være med på projekter og køre dine egne

Det vi leder efter er:

• iOS-erfaring
• Selvfølgelig “native”
• Positiv indstilling
• Opfindsomhed
• Interesse og forståelse for hvordan apps er noget unikt
• En kandidat der både sætter en ære ikvaliteten af koden og i kvaliteten af GUI’en

Du kan nok bedst få et indtryk af Greener Pastures fra vores hjemmeside, de apps vi har lavet og fra vores blog – men nøgleordene er “kvalitet”, “native”, “apps”, “fairness” og “small is beautifull”. 90% af tiden bruger vi på kundeopgaver. 10% af tiden bruger vi på “egne apps” – mest fordi vi synes det er sjovt.

Vores kontor ligger i Kødbyen på Vesterbro i kontorhotellet SOHO.

Greener Pastures har ingen HR-afdeling, vi har ingen Joint Creative Directors, du skal ikke regne med tre-timers ugentlige afdelingsmøder, og vi laver ikke organisationsændringer hver måned, fordi vi har været på ledelsesseminar og fundet på en ny strategisk metode.

Til gengæld har vi masser af udfordrende og spændende iOS-opgaver, vi holder til i SOHO i Kødbyen, vi tager typisk de opgaver, der er for langhårede til bureauerne, du får fem kollegaer der alle både kan finde ud af at programmere, skrue et interface sammen og snakke med kunderne – og vi sætter en ære i at lave gode apps af højeste kvalitet.

Vores firmafilsofi er, at small is beautiful. Hvis du kender Rework fra 37Signals, så går du ikke galt i byen.

Så er det dig? Eller ved du, hvem vi skal have fat i? Send en mail til jakob@greenerpastures.dk.

Vi behandler selvfølgelig alle henvendelser med fuld fortrolighed.

En hurtig uvidenskabelig test viser at Berlingskes app er 7 sekunder om at have hentet sin forside – hvorimod Politiken er 24 sekunder om at hente forsiden. Det får mig til at fravælge Politiken og læse Berlingske.

Moralen er, at performance er en af de vigtigste features i en iPhone eller Android app. Måske den vigtigste.

(Testet på min iPhone 4S via Wifi – og inden testen har jeg fjernet begge programmer fra telefonens hukommelse og sikret mig at jeg har seneste version).

Nedenfor er de slides vi plejer at starte mødet med. Slides’ne udgør eksempler på marketings-aktiviteter, som vi har set brugt i forbindelse med en app-lancering – og en række lessons learned fra disse.

Historien er, at Pingo sendte en film til info@greenerpastures.dk der lå ret tæt på den film, der er vist nedenfor. Konceptet var stort set klart og grafikken var lækker. Det kunne vi slet ikke stå for – så sammen med Pingo har vi lavet Typon.

Konceptet er simpelt: Man kan skrive tekst på et billede, man kan flytte, skalere og rotere teksten, man kan vælge fonte og farver – og man kan dele resultatet på Facebook, gemme det i telefonen eller sende det som en email. Det hele pakket lækkert ind – med inspiration fra diverse billederedigerings-programmer.

Så er det bare at være kreativ – og finde på nogle gode tekster.

Se filmen eller hent app’en her.

Succesen har har naturligt nok affødt en stigende efterspørgsel på apps til Android hos Greener Pastures, og vi er kommet godt fra start med bl.a. Aftensmad, Studier KU og Radio24syv.

En af de interessante udfordringer ved Android platformen i forhold til iOS er den enorme spændvide i hardware. Hvor iPhonen siden sin lancering “kun” har eksisteret i 5 forskellige modeller, er der i dag over 600 forskellige modeller Android telefoner registreret i Android Market.

Dette gør det selvfølgelig til en større opgave at sikre sig, at en app fungerer godt på de fleste devices “i marken”. Hvor man på en time eller to kan teste alle iPhone modeller, er den manøvre praktisk taget umuligt på Android, uanset hvor meget tid man afsætter.

Heldigvis bliver langt de fleste hardware-forskelle håndteret automatisk af Android operativsystemet, og er altså ikke noget, der giver problemer i udviklingssammenhæng. Men, der er navnlig ét sted, hvor den store variation skal indtænkes fra start: Skærmopløsningen.

Jeg har forsøgt at håndgribeliggøre variationen i skærmopløsning på Android med denne illustration af de forskellige iPhone og Android skærmopløsninger, der findes — jeg har endda udeladt et par Android variationer!

På iPhone siden er der kun 2 forskellige opløsninger. Disse udmærker sig ved, at iPhone 4 er nøjagtig dobbelt så høj opløsning på hver led, end de tidligere modeller. Det betyder, at en grafisk designer kan arbejde med brugergrænsefladen inden for et kanvas med velkendte proportioner og nemt kan klippe grafikken op direkte i Photoshop.

På Android siden er der et virvar af forskellige opløsninger og propertionsforhold. Ikke alene skal man, hvis man ønsker at understøtte hele spektret af devices optimalt, producere grafikken i 4 forskellige opløsninger (I Android-termer kaldet LDPI, MDPI, HDPI og XHDPI). Forholdet mellem disse 4 opløsninger er illustreret hér.

Variationen i størrelse og proportionsforhold gør også, at det i praksis er umuligt at specificere placering og marginer præcist i pixels: man må istedet ty til “procentdele af skærmbredden” eller såkaldte “device independent pixels” og den slags abstrakte begreber, der kan give enhver æstetiker med bare en smule kontrol-behov hovedpine.

I praksis er det heldigvis ikke helt så slemt som det lyder: For det første er der kun et meget lille antal ‘LDPI’ telefoner i marken, og dette er typisk ældre modeller. Vi anbefaler derfor vores kunder ikke at bekymre sig om denne opløsning, eftersom app’en stadig vil kunne benyttes, men blot have en mere gnidret grafik. ‘MDPI’ svarer til iPhone 3, og XHDPI til iPhone 4, hvorfor der er en stor grad af genbrug.

9-patches

Dertil kommer, at Android i stort omfang benytter sig af et smart type grafik kaldet ’9-patches’ til at håndtere variationen i proportioner. Formattet er i sin enkelthed en .png fil, hvor den yderste række af pixels angiver, hvor en grafik må “strækkes”, når den eksempel vis skal fylde hele bredden eller højden af skærmen (husk på at højden og bredden i praksis er en ukendt størrelse på en Android telefon!).

Lad os som eksempel forestille os, at vi skal lave en fejl-boks, der glide frem, når der ikke er net-forbindelse. Vi vil gerne have, at den fylder hele bredden af skærmen, men ved i sagens natur ikke hvor mange pixels det er.

Ved hjælp af 9-patches kan et passende grafik-element fremstilles således:

Som det fremgår er det angivet med sorte pixels, at grafikken skal strække området under og til højre for cirklen med udråbstegnet, men ikke selve cirklen. Til højre kan man se resultatet af at strække grafikken til hhv. dobbelt bredde og højde. I 9-patch’ens højre og nederste rand kan man endvidere angive hvor teksten skal placeres, hvis grafikken bruges som baggrund for em tekst som hér.

System er utroligt fleksibelt, og selvom en grafiker typisk er nødt til at folade sin “comfort zone” for at kunne levere det nødvendige materiale til en Android app, tager det ikke længe, før man forstår systemet.

Afslutningsvis er her en liste af ting, du skal huske på, hvis du som kunde ønsker selv at påtage dig arbejdet med at klargøre grafik til en Android app:

• Du kan ikke angive størrelser og marginer eksakt i pixels, men må ty til relative mål som procent af bredden eller ‘Device Independent Pixels’ (“cirka-pixels”).
• Udover de opløsninger, i forbindelse med iPhone 3 (MDPI) og iPhone 4 (XHDPI) skal der altid laves en opløsning midt imellem, kaldet HDPI — 1,5 gange større end MDPI.
• Næsten alle grafik-elementer, der skal fylde hele (eller dele af) skærmens højde/bredde skal konverteres til 9-patch format.

Hvis du som kunde hellere er fri for det ekstra arbejde med at gøre grafikker strækbare, er det selvfølgelig også noget vi gerne hjælper med.

Du kan læse om håndtering af de mange skærmopløsninger på Android, til du bliver grøn i hovedet i Android’s officielle dokumentation hér: http://developer.android.com/guide/practices/screens_support.html

Endvidere er der em mere omfattende introduktion 9-patches på engelsk hér: http://radleymarx.com/blog/simple-guide-to-9-patch/

Sammen med og for bureauet Gefühl har vi udviklet en iPhone og Android app til Københavns Universitets studiekampagne 2012.

Et spændende koncept i kampagnen er, at man med sin telefon kan se videoer om  hverdagen for otte nye studerende på universitet. Sidste år lavede KU kampagnen på web – og udvider nu konceptet til SmartPhones. Hver uge laves kommer der fire nye videoer – og det er således en lille føljeton – eller KUs egen lille TV-kanal.

Læs mere om Studier KU.

Udover nyheder, program for kongressen med integration til iPhonens kalender og en QR-scanner, så brugerne kunne scanne 2D-stregkoder ved Novo Nordisks stand og få mere information om produkter o.lign., skulle app’en fungere som controller til et spil, der kørte på en 50″ storskærm på standen:

(Billede fra Designit)

Her er slides’ne: