Vad är en app?
Om du har en “smart” mobiltelefon eller en surfplatta har du redan sett och säkert använt appar. Moderna mobiltelefoner och surfplattor är egentligen specialanpassade datorer, och en app är ett program gjort för att användas på dem. De symboler som du kan bläddra bland på apparatens hemskärm visar vilka appar du har installerade – t ex webbläsare, e-postklient, musikspelare, fotobibliotek, telefon osv.
Du kan installera nya appar som du laddar ned från en central plats på Internet, där alla appar som utvecklats för din apparat finns. En del appar är gratis, medan det kostar att ladda ned andra. Många är billiga, och priser på under tio kronor per app är vanliga. Idén med en central marknadsplats för appar skiljer sig från hur traditionella datorprogram säljs och distribueras, där normalt varje leverantör eller återförsäljare har egna webbplatser, fysiska butiker etc. På senare år har även vissa program för normala datorer börjat distribueras på samma sätt som appar, och ordet app används numera även om de programmen.
För den historiskt intresserade: Ordet ”app” är egentligen mycket äldre än så. Ordet dyker upp i tryck redan under 1980-talet, men då som en förkortning (näst intill ett slanguttryck) för det engelska ordet ”application”, som på svenska blir tillämpning eller applikation – en term som för alla utom textilkonstnärer är det samma som datorprogram. Ett program som på 1980-talet var så revolutionerande – t ex de första kalkylprogrammen – att det ensamt kunde sälja en dator kunde t ex kallas en ”killer app”. Den användningen av ordet slog emellertid aldrig rot utanför datorvärlden. Först i samband med Apples lansering av mobiltelefonen iPhone 2007 blev ”app” ett ord i den stora allmänhetens medvetande.
Vad är affärsidén med en app?
När de första smarta telefonerna dök upp trodde man att många användare skulle nöja sig med de appar som redan fanns i telefonerna, och att marknaden för ytterligare appar skulle begränsa sig till vissa bestämda nischer, som t ex spel. Det skulle snart visa sig vara väldigt fel. Förutom sociala medier, som t ex Facebook, Instagram och Twitter, kommer många av de mest använda apparna idag från högst seriösa aktörer som t ex myndigheter, banker och matvarukedjor. För flera av de här aktörerna håller appar på att bli en av deras viktigaste kontaktvägar till deras kunder. Tanken bakom många av dessa appar är både att erbjuda bättre kundservice och att sänka administrationskostnader, och av de skälen är dessa appar som regel kostnadsfria. Att kunna utföra bankärenden via en app och att deklarera via en app är två tydliga exempel på den här typen. Spel finns naturligtvis kvar som en annan framgångsrik grupp av appar, och här är huvudsyftet att tjäna pengar – antingen på försäljning av själva appen, eller på försäljning av diverse ”tilläggsprodukter” som appen skapar ett behov av.
Fungerar alla appar på alla apparater?
Nej! Idag finns det två stora mobila plattformar för smarta telefoner, surfplattor och liknande: iOS, som skapats av datorföretaget Apple och omfattar deras produktfamiljer iPhone, iPad, iPod touch och Apple TV, och Android, som skapats av sökleverantören Google och stöds av en lång rad leverantörer av mobila apparater i industrisammanslutningen Open Handset Alliance, där Samsung, Sony, LG, HTC och Motorola är några av de stora namnen.
En app skapad för den ena plattformen fungerar inte på den andra, och vice versa. Därför väljer de flesta större appleverantörer att tillhandahålla separata appar för båda plattformarna. Det finns i skrivande stund över 1,4 miljoner olika publicerade appar för vardera plattformen.
Det finns fler mobila plattformar, men de är oerhört mycket mindre. Två av dem är Microsofts Windows Phone, med drygt 130000 publicerade appar, och Blackberry, med drygt 120000. Dessa är emellertid så pass mycket mindre att de flesta aktörer nöjer sig med att finnas på de två största plattformarna.
Appar kan vara ytterligare begränsade till att endast fungerar på vissa apparatmodeller, t ex endast på mobiltelefoner, eller endast på surfplattor.
Hur distribueras appar?
Appar för iOS distribueras via Apples tjänst App Store, medan appar för Android distribueras via Google Play (f d Android Market). I båda fallen är detta centrala marknadsplatser som alla globalt tillgängliga appar för resp plattform måste distribueras via. Genom det ovanliga greppet att skapa en sådan central marknadsplats för appar vinner man en lång rad fördelar, där användare söker efter, laddar ned och betalar för appar, alltid på samma sätt.
Att distribuera appar via en central marknadsplats skapar inte bara enkelhet och enhetlighet för användarna – det möjliggör också en helt annan nivå av kontroll för den som driver marknadsplatsen. Appar som publiceras måste passera en granskningsprocess, där en app kan bli refuserad av många olika skäl – allt från att den väcker anstöt till att den förbrukar orimligt mycket ström från apparatens batteri i förhållande till sin funktion. Hårdast är denna kontroll för Apples App Store. För en del kan detta upplevas som en sorts diktatur, men för många användare skapar det också ett visst mått av trygghet, och de appar som klarar granskningen håller en jämnare nivå.
Att driva en central marknadsplats medför naturligtvis dryga kostnader för granskning, bandbredd och lagringsutrymme. Av priset användare betalar för avgiftsbelagda appar går i båda fallen 70 % tillbaka till appens utvecklare. De återstående 30 % behålls i fallet App Store av Apple som ersättning för tjänsten, medan för intäkterna för Google Play fördelas mellan driftskostnader och distributörer, vilket ofta innebär att telekomoperatörer får en extra intäkt från appförsäljning till Android-apparater. (Google har också egna intäkter från reklam i samband med deras tjänster.)
Det finns en alternativ distributionsmodell, där ett företag får rätten att distribuera appar för internt bruk inom organisationen utan att behöva gå via marknadsplatsen.
Hur utvecklar man en app?
Många appar är så lätta att använda (när såg du senast en instruktionsbok för en app?) att man lätt kan förledas att tro att appar därmed också måste vara extremt lätta att utveckla. Det kanske inte ens krävs ”riktig” programmering? Tyvärr är sanningen den motsatta: de flesta appar du ser idag är frukten av gammal hederlig programmering, och det kan vara en tuff uppgift att bygga en app som från användarens sida sett upplevs som enkel och uppenbar.
Faktum är att inte heller Apple, som var först ut med appar 2007, trodde att man skulle behöva förse utvecklarna med verktyg för fullskalig programmering av appar. Man tänkte sig att det bara skulle behövas riktig programmering för de mer avancerade appar som Apple själva byggde. Utvecklarna skulle klara sina behov genom att bygga webbsidor för den inbyggda webbläsaren Safari med en kombination av HTML (för att beskriva webbsidor) och skriptspråk (för att få det att hända saker på webbsidan). Det tog mindre än ett år innan Apple tvingades krypa till korset och göra en helomvändning, där man gav utvecklarna en integrerad utvecklingsmiljö – faktiskt samma som används för utveckling av traditionella Macintosh-program – men med bibliotek anpassade för apputveckling.
Idag är det en självklarhet för båda de stora mobilplattformarna att de flesta appidéer endast kan realiseras via normal programmering i ett fullskaligt programspråk. För vissa mer förutsägbara typer av appar finns verktyg som kan generera hela eller delar av programkoden, men det vanligaste fallet är att en app utvecklas av en eller flera professionella programmerare.
Vad skiljer apputveckling från ”vanlig” programutveckling?
Så om det handlar om riktig programmering i båda fallen, finns det då någon skillnad? Svaret är definitivt ja!
De som idag utvecklar programvara för vanliga datorer – t o m om det gäller en enkel dator som man köper i konsumenthandeln – har under de gångna åren alltmer kunnat vänja sig vid att även den enklaste dator har enorma resurser i processorkraft, arbetsminne och massminne för lagring av data. Det är lätt att glömma bort vilken otrolig teknikutveckling vi sett sedan persondatorer först såg dagens ljus. De klockfrekvenser mätt i gigahertz som säljare i konsumenthandeln älskar att mata oss köpare med leder oss att tro att en dator blivit ungefär 20 gånger snabbare på de senaste 15 åren. Sanningen är betydlig mer uppseendeväckande: alla andra förbättringar som gjorts under tiden leder till en total effekt där dagens datorer blivit ungefär 200 gånger snabbare på 15 år! Det är inte underligt att detta lätt kan göra en utvecklare lite bortskämd!
På samma sätt är dagens datorer försedda med enorma lagringsutrymmen i form av inbyggda och externa diskar, optiska media (CD, DVD och BluRay), USB-minnen och minneskort i olika format. Det finns en ofta citerad konspirationsteori att flera av de stora leverantörerna skulle vara i maskopi med tillverkarna av lagringsmedia, eftersom systemprogram och vanliga program ofta kräver så mycket plats vid installation. Sanningen är mycket enklare än så: det lönar sig inte för programmerare att lägga ned tid på att göra programmen så kompakta och resurssnåla som möjligt, när datorerna ständigt blir mer och mer kraftfulla. Uttryckt på ett annat sätt – det slarvas mycket mer med resurser idag!
Apputveckling bryter den trenden. Apputveckling tar oss tillbaka till en värld med klart begränsade resurser. En mobiltelefon eller en surfplatta påminner om en dator, men i så fall en dator som är betydligt svagare än de konsumentdatorer vi vant oss vid under de senaste åren:
- Processorn i en mobil apparat – den som kör all programvara och därmed får apparna att bete sig som de ska – är betydligt svagare än i en vanlig dator. Samtidigt förväntar sig en användare att få se ett snabbt och mjukt beteende på skärmen, inklusive avancerade animationer. Det gör det viktigt för programmeraren att hushålla med bearbetningskraften. Att välja rätt sätt att utföra en komplicerad beräkning kan t ex betyda mycket mer än man än van vid.
- Arbetsminnet är mycket mer begränsat än i en dator. En typisk smart telefon av idag har kanske en halv eller en gigabyte (GB) arbetsminne, medan dagens konsumentdatorer typiskt säljs med mellan 4 och 8 GB arbetsminne. Detta minne ska räcka till allt, så när apparatens fasta systemprogram fyllt sina behov, återstår kanske som bäst hälften av det minnet för en app att disponera. Och när det minnet är förbrukat uppstår akut minnesbrist. Den teknik som kallas ”virtuellt minne”, där man på normala datorer kan ”överutnyttja” arbetsminnet mot en förlust i prestanda genom att mellanlagra delar av minnet på disk, existerar inte på mobila plattformar. Akut minnesbrist kan leda till att appar stängs ned utan förvarning, med en bedrövad användare som följd.
- Det är också snålare tilltaget med massminne för långtidslagring av appar och data. Mobila plattformar använder ofta lagringsmedia som påminner om det som används inuti minneskort, och de är dyrare per lagringsvolym än de tekniker som används i vanliga datorer. Eftersom användaren därtill förväntar sig att kunna använda mycket av det utrymmet för att lagra musik, bilder och videoklipp, bör appar inte vara större än vad som absolut behövs.
- Bildskärmen på en mobiltelefon eller surfplatta är betydligt mer begränsad i storlek än de stora skärmar vi ofta ser tillsammans med dagens datorer. Även om upplösningen på mobila apparater kan vara ovanligt hög räknad i bildpunkter per kvadratcentimeter, är skärmen fortfarande fysiskt liten, och en knapp i ett användargränssnitt kan inte vara hur liten som helst, om en användare ska kunna träffa rätt. Ett användargränssnitt får inte bli ett datorspel där det är en utmaning att klara av att använda det!
- En användare av en vanlig dator har tillgång till ett fysiskt tangentbord och en mus eller en styrplatta. De gör det lätt att snabbt skriva in stora volymer text och att utföra precisa rörelser i användargränssnittet. En smart telefon eller en surfplatta har en tryckkänslig skärm där användaren ska peka och utföra gester, och det är svårt att göra det med samma precision. Det finns ett skärmtangentbord som dyker upp vid behov för att skriva text, men det är långtifrån lika bekvämt att använda som ett fysiskt tangentbord. Dessa skillnader betyder att användargränssnittet måste se ut på ett annat sätt om en användare ska uppfatta en app som lättanvänd.
Det är viktigt att inse att rätt svar på flera av dessa begränsningar inte är så enkelt som att förse apparaterna med en snabbare processor och mer arbetsminne. Det skulle ge apparaten en högre prislapp och en kortare batterilivslängd per laddning – inget som en konsument skulle uppskatta. I stället är det utvecklaren som måste anpassa sig till en värld med restriktioner.
Kan jag använda vilket programspråk som helst?
Nej! Till ”vanliga” datorer finns det ofta en uppsjö av programspråk, verktyg och bibliotek att välja mellan, och där kan en erfaren programmerare kanske hitta stöd för sitt absoluta favoritspråk. För apputveckling är man mycket mer styrd till vad plattformsleverantören tillhandahåller, och det handlar inte bara om valet av programspråk. För att utveckla appar effektivt krävs en bra kombination av programspråk, utvecklingsverktyg och kraftfulla bibliotek. Att försöka gå vid sidan av det och ”skriva hela programmet själv, så jag får det som jag själv vill ha det” är dömt att misslyckas.
För Apples plattform iOS sker all utveckling i Apples eget integrerade utvecklingsverktyg Xcode. Det finns numera två programspråk att välja mellan, Objective-C och Swift, som båda utvecklas av Apple. Apple har flera kraftfulla bibliotek som ger stöd för appar i iOS, där det viktigaste biblioteket är Cocoa Touch.
För Googles plattform Android sker all utveckling i programspråket Java, ett språk som från börjat utvecklades av Sun Microsystems. Flera integrerade utvecklingsverktyg för Java kan användas, men det mest omfattande stödet för apputveckling har historiskt funnits som tillägg till det populära verktyget Eclipse. Eclipse är emellertid ett verktyg med hög inlärningströskel, och därför satsar Google nu på alternativet Android Studio, som är mera lättillgängligt och bygger på Java-verktyget IntelliJ IDEA. Den s k virtuella maskinen, som kör Java-koden, är inte den samma som för normala datorer, utan en resurssnål variant framtagen av Google. Biblioteken bygger på Javas standardbibliotek, men har anpassats och byggts ut kraftigt av Google.
(Faktum är att det även för normala datorer blir allt mindre av en sanning att man kan välja sitt favoritspråk bland programspråken. De flesta plattformsleverantörer har något eller några språk som de stödjer mer än andra, eller verktyg och/eller bibliotek som styr valet av språk.)
Varför har Apple två programspråk, när Google klarar sig med ett?
Svaret på den frågan har mycket med den bakomliggande historien att göra. Medan Java är ett objektorienterat programspråk som närmar sig sin 20-årsdag, är Objective-C ett objektorienterat programspråk med rötter ända tillbaka till 1983, då som ett av de första försöken att komplettera det tekniska programspråket C med objektorienterade tillägg. Apple tog över äganderätten till Objective-C när man köpte upp företaget NeXT, som startats av Steve Jobs (som ju också var en av dem som grundade Apple). Köpet av NeXT handlade om att komma över systemprogramvaran NextStep, som 2001 bildade basen i Apple nya datoroperativsystem Mac OS X (numera omdöpt till OS X). De innovativa verktygen Project Builder och Interface Builder i NextStep blev basen i det som idag är verktyget Xcode. Stora delar av NextStep, inklusive verktyg och bibliotek, hade utvecklats i Objective-C, som därför med automatik blev det dominerande huvudprogramspråket för Mac OS X.
Som redan sagts är smarta telefoner och surfplattor en sorts specialiserade datorer, så när Apple 2007 lanserade iPhone, behövde den ett operativsystem. Man valde att skapa en nedbantad och förändrad version av OS X, och resultatet blev den plattform som idag kallas iOS. Eftersom Objective-C var huvudspråket för OS X, fick det automatiskt samma roll för iOS. Fram till 2014 var det det enda alternativet, vilket under ett antal år gjorde Objective-C till det snabbast växande programspråket i världen, mätt i tillväxttakten av programmerare som använde det.
Objective-C ett kritiserat val – Apple lanserar nytt språk ”Swift”
Så kunde det förblivit, men det fanns kritik mot Apples val av Objective-C. Ett programspråk med över 30 år på nacken kan lätt upplevas som gammalt, och många tyckte dessutom att det var olyckligt att språket C ingick som en delmängd i Objective-C. (C är illa beryktat som ett språk där det är sällsynt lätt att skapa instabila program som kraschar eller hänger sig – något man absolut inte vill se hända i en mobiltelefon.)
Få hade nog väntat sig att Apple skulle bry sig om den kritiken, men i början av sommaren 2014 överraskande man världen genom att berätta att man under fyra års tid i hemlighet utvecklat ett helt nytt programspråk, Swift. Swift skulle, precis som Objective-C, kunna användas på alla Apples plattformar, vilket nu omfattande tre alternativ: OS X, iOS och watchOS, en plattform för ”smarta” klockor. (Android-världen har en motsvarande plattform, Android Wear.) Dessutom, och tvärtemot hur man hanterat Objective-C, avser Apple att senare under 2015 släppa Swift som öppen källkod. Därmed skulle vägen ligga öppen för den som vill att flytta språket till exempelvis Windows.
Apple beskriver Swift som modernare, säkrare, snabbare och inte byggt på språket C – kort sagt, de tycker att det är bättre. Att språket är modernare är svårt att säga emot. Det är få andra språk födda på 2010-talet som ännu hunnit få genomslag, men Swift är också modernt i termer av de språkidéer man lånar från andra moderna språk. Säkerhet är ett ännu mer tydligt signum, där Swift framstår som ett av de mest typsäkra språk som någonsin skapats. Med typsäkerhet menas till vilken grad en kompilator, dvs det verktyg som översätter skriven kod till körbara program, kan fånga upp och förhindra typfel, där programmeraren av misstag använder värden av en annan typ (sort) än vad som förväntas. Hög typsäkerhet leder till stabilare program som mer sällan kraschar eller beter sig illa, vilket naturligtvis är attraktivt. Faktum är att Swift är så typsäkert att restriktionerna säkerligen kommer att reta en del programmerare, men det görs för ett gott syfte.
Betyder lanseringen av Swift att Objective-C kommer att försvinna?
Nej, troligen inte. Apple avslöjar i och för sig inget om deras planer på längre sikt, så det går inte att veta säkert, men det förefaller inte sannolikt. Tvärtom vidareutvecklas Objective-C fortfarande, och nya egenskaper i språket lanseras i år (2015). Såväl dessa tillägg till Objective-C som vissa egenskaper hos Swift pekar tydligt på en sak: man anstränger sig för att de båda språken ska kunna fungera tillsammans och utnyttja samma bibliotek. Det är rent ekonomiskt förnuft från Apples sida, eftersom de lagt ned stora resurser på att ta fram avancerade bibliotek för alla sina plattformar, och man är knappast road av tanken att behöva underhålla två versioner av allt.
Därför är det sannolikt att båda programspråken kommer att existera sida vid sida under lång tid. Det är dessutom redan nu möjligt inte bara för Apple utan även för vanliga utvecklare att få de båda språken att samarbeta inom ett och samma projekt.
Hur har utvecklarna reagerat på det här? De som redan har stora projekt med mycket tid investerad i Objective-C, fortsätter ofta med språket. Samma sak gäller de som utvecklar familjer av appar med en stor gemensam kodbas i Objective-C som nya appar kan utnyttja. Det verkar också vettigt – dessa utvecklare har antagligen mer att vinna på att bygga ut utbudet med ny funktionalitet eller nya appar, jämfört med att sätta igång ett massivt projekt för att skriva om all kod – något som användaren inte skulle märka så mycket av. Även detta talar för att Apple kommer att fortsätta underhålla Objective-C.
Däremot är det många som väljer Swift bland de utvecklare som startar nya projekt från scratch. Apple-utvecklare tenderar att vara ganska lojala mot Apple och lyssnar uppmärksamt när Apple säger att de tycker att Swift är bättre. Därför är det sannolikt att Swift går en blomstrande framtid till mötes. Den här trenden syns tydligt i de böcker som publiceras för apputveckling för iOS, där flertalet som kommit ut sedan Swift lanserades valt att bygga på Swift. En ambitiös bokserie finns faktiskt i två varianter – en för Objective-C och en för Swift – men annars dominerar Swift nyutgivningen.
Så, även om det beror på historiska tillfälligheter, har båda språken sitt berättigande framöver.
Är det verkligen viktigt att förstå plattformens arkitektur?
Ja! Som redan nämnts är både iOS och Android plattformar där det är viktigt för programmeraren att hushålla med resurserna. En viktig strategi för att lyckas med det är att lära sig plattformens arkitektur, dess designprinciper och vilka programmeringsregler som gäller, så att man arbetar med plattformen – inte mot den.
Vi kan ta ett enkelt, konkret exempel. Även om du bara sett några få appar, har du antagligen redan sett appar som visar en lista med många rader där användaren snabbt kan bläddra med fingret över listan och välja en listrad genom att trycka på den. Anta att du som programmerare för iOS-plattformen vill hålla reda på lite information tillsammans med varje listrad – lite mer än bara det som står på listraden. I förstone kan det låta som en bra idé att försöka lagra dessa data ihop med själva listraden. (De som behärskar objektorienterad programmering inser att detta t ex kan åstadkommas med det som kallas en underklass.)
Den här idén, som till en början kan låta vettig, bryter emellertid mot en grundläggande designidé i iOS-arkitekturen. Designidén kallas Model-View-Controller (MVC) och innebär enkelt uttryckt att de objekt som håller i applikationens data (Model), de som presenterar applikationens data (View) och de som innehåller applikationens affärsregler och verksamhetslogik (Controller) ska hållas strikt åtskilda. MVC är en gammal och väletablerad designidé, men få arkitekturer tillämpar den så renlärigt och ihärdigt som iOS.
Om du inte känner till arkitekturen, kanske du av oförstånd bryter mot principen genom att lagra verksamhetsbärande data (Model) tillsammans med listraden (View). Straffet kommer tämligen omedelbart, när du upptäcker att iOS för att spara resurser tar sig rätten att hejdlöst återanvända objekt för listrader så fort de rullar ur bild! De data som du lagrat i dessa objekt skulle därmed snabbt gå förlorade, och din app skulle sluta fungera som tänkt.
Det här är bara ett bland många exempel som visar hur viktigt det är att faktiskt lära sig plattformens arkitektur.
