Ctrl + Z

5 grunner til å utvikle app for iOS før Android. Eller?

I en artikkel på sin blogg (publisert 27. juli 2012) og en kommentar på Mobilen.no (publisert 1. august 2012) argumenterer min navnebror Hans-Petter Nygård-Hansen for hvorfor man bør utvikle mobilapplikasjoner for iOS før  Android. Artikkelen har mange gode argumenter og poeng. Men den har også en del faktafeil og, etter min mening, feiltolkninger som ved nærmere analyse kan være med på å gjøre hans konklusjon mer nyansert.

Tablet-markedet
Jeg helt enig med Nygård-Hansen om at iPad er enerådende i dagens tablet-marked, både når det gjelder markedsandel, bruksopplevelse og utvalg av apps. Å utvikle for iPad først virker derfor, per dags dato, som et fornuftig valg.

Et interessant ting som Nygård-Hansen ikke nevner er at Google i samarbeid med Asus i slutten av juni lanserte sin Nexus 7-tablet. En lansering som av mange blir sett på som et veiskille når det kommer til Android-tablets. Nexus 7 har fått svært gode tilbakemeldinger, også fra selvproklamerte iOS-fans. Blant annet skriver MG Ziegler fra TechCrunch følgende: “I like the Nexus 7. I really like it.” Nexus 7 forventes lansert i Norge i begynnelsen av september. Med imponerende hardware-spesifikasjoner, og ikke minst en pris på rundt 2000 kroner, er jeg ikke i tvil om at den vil falle i smak hos mange nordmenn, og seiler kanskje opp til å bli den første virkelige konkurrenten til iPad.

Utviklernes interesse rundt utvikling av tablet-apps for Android har vært tilnærmet fraværende, hovedsaklig på grunn av mangelen på brukere. Det er for tidlig å si om Nexus 7 vil endre på dette. Men salgstallene den har hatt i USA mistenkes å være gode, uten at Google har gått ut med konkrete tall enda, og med mange brukere kommer også incentivet om å utvikle apps – enten det er for betal-apps, reklamefinaniserte apps eller apps for markedsføring.

Utviklertilhørighet
Nygård-Hansen skriver: “De fleste utviklere i dag – kan det synes som – er unisont enige om at det beste er å utvikle apps til iOS-plattformen først.” Etter hva jeg kan se understøttes dette i kommentaren kun med tilbakemelding fra én utvikler.

Egen erfaring som utvikler sier at det blir stadig vanligere å utvikle side-ved-side. Den unisone enigheten Nygård-Hansen forteller om var der kanskje for ett år eller to siden, men er der ikke nå lengre, eller er i hvert fall sterkt avtagende.

Og mener Nygård-Hansen at det er enklere for norske utviklere å lære Objective-C enn Java? Norske studenter lærer i dag i all hovedsak et av to objektorienterte programmeringsspråk; Java (som også er språket som brukes i Android-utvikling) eller C#. Førstnevnte brukes typisk i offentlige utdanningsinstitusjoner (for eksempel NTNU), mens sistnevnte brukes av private utdanningsinstitusjoner (for eksempel NITH). C# er svært likt Java i syntaks, og man hører ofte at en god Java-utvikler kan bli en god C#-utvikler på noen uker, og vice versa. Med unntak av Smalltalk er ikke Objective-C et programmeringspråk som, for eksempel syntaksmessig, ligner veldig på andre objektorienterte språk (se for eksempel denne sammenligningen). At det da skal bli enklere å utvikle i Objective-C enn Java må jeg be Nygård-Hansen utbrodere, for det har jeg aldri hørt noen si – ei heller at noen har sagt at det er enklere å komme i gang med Objective-C-utvikling.

Ukorrekte sammenligninger
“23. mai i år lanserte Finn.no sin Android-app på Google Play, to dager etter at de hadde lansert iPad-appen sin på App Store. På en måned hadde iPad-appen blitt lastet ned 100,000 ganger mot 10,000 ganger på Android.”

Nygård-Hansen fremstiller dette som to identiske apps, rettet mot to ulike OS. Faktumet er at FINN i mai i år lanserte to apps for iPad og Android som hadde helt forskjellig funksjonalitet. Førstnevnte er en app hvor brukerne kan se annonser for de ulike markedene (Torget, Bolig osv.) på FINN , mens sistnevnte lar brukerne publisere annonser for salg fra sin Android-enhet.

Det burde si seg selv hvilke app som får flest nedlastinger. I tillegg til dette nevner ikke Nygård-Hansen det svært sentrale poenget at Android-appen har hatt bedre konvertering sammenlignet med tilsvarende innleggings-app for iPhone (7,03 betalte annonser per 100 nedlastinger for Android, mot 4,64 for iPhone). Skal man tolke disse tallene sort-hvitt så har man faktisk her et argument for å utvikle for Android først. Tallene fremgår klart i bloggposten fra FINN som Nygård-Hansen linker til.

Fragmentering
Nygård-Hansen bekymrer seg over fragmenteringen på Android, både når det gjelder hardware-egenskaper og hvilken versjon av Android de ulike telefonene bruker. Og han er ikke den eneste; det publiseres utallige artikler, forum- og bloggposter om temaet daglig.

Selv har jeg som utvikler til gode å oppleve utfordringer med versjonsfragmentering, med ett unntak hvor jeg slet noen timer med å få bildeimportering til å fungere på et sett Sony-Ericsson-telefoner. Jeg har også til gode å møte andre app-utviklere for Android som har møtt på store utfordringer når det kommer til  versjonsfragmentering. Spillutviklere har større utfordringer, har jeg hørt og lest.

På tross av at Nygård-Hansen retter artikkelen mot apputvikling i Norge, presenteres statistikk fra webbruk, i tillegg til en “skremmende illustrasjon” fra amerikanske Business Insider for å illustrere fragmenteringsproblemene. Et av tingene Nygård-Hansen her glemmer er at Norge ikke er verden. Applikasjonen som datagrunnlaget for illustrasjonen har blitt hentet fra har blitt installert av personer fra hele verden, ikke bare nordmenn. Det sies at folk flest bor i Kina, og Android har en svært stor markedsandel i Asia, Afrika og Sør-Amerika. Om man skal generalisere så kan ikke inntektsnivået i disse verdensdelene på noen måte sammenlignes med inntektsnivået vi har her i Norge. Naturlig nok kjøper derfor brukere i disse markedene enheter med både eldre programvare og dårligere hardware-spesifikasjoner.

Dette reflekteres i grafen til Business Insider, og det reflekteres også i de offisielle statistikkene som publiseres av Google om Android sin versjonsutbredelse, kontra tilsvarende statistikk for Norge (vist under). Som en utfordring oppfordrer jeg herved Nygård-Hansen til å markere hvor mange Android-enheter vist i den “skremmende illustrasjonen” som er lansert i Norge. Jeg vil anta at han står igjen med rundt 1/30.

Nygård-Hansen bruker også FINN sin webstatistikk for å trekke konklusjoner rundt Android-versjoner som brukes. Dette på tross av at  bloggposten  omhandler apputvikling. Før jul lanserte jeg appen Kvotekalkulatoren i Play Store. Når jeg skriver dette har 1066 personer kjøpt appen. Ikke et overveldende stort tall, men ved meningsmålinger er ikke et så lavt sample uvanlig. Man kan derfor anta at tallene som fremgår har en viss validitet. Det faktum at appen også, etter eget utsagn, appellerer til et relativt godt tverrsnitt av den norske befolkningen burde også tale i favør av dette.

Så, hvilke Android-versjon bruker de som har kjøpt Kvotekalkulatoren? Jeg lar diagrammet og tallene under tale for seg selv. Her er det også verdt å nevne at man finner omtrent tilsvarende tall i andre applikasjoner som jeg har vært med å utvikle i jobbsammenheng – applikasjoner som har mye større nedlastingsvolum enn Kvotekalkulatoren. Dersom du som leser dette er Android-utvikler, vet du sikkert at du kan hente ut tilsvarende tall for dine egne apper i Google Developer Console.

TweetDeck

I bloggposten skriver Nygård-Hansen om appen TweetDeck som har “hatt over 36,000 betatestere fordelt på over 244 håndsett og 108 forskjellige OS-versjoner av Android til å teste den over lengre tid.” Og tallene stemmer de. Det som ikke stemmer er Nygård-Hansens tolkning.

Med 108 forskjellige OS-versjoner mener TweetDeck egentlig 108 forskjellige ROMer. I Android-verden er det mange spesielt interesserte som tilpasser OSet, og publiserer disse tilpassede versjonen på nettet. På tross av at disse ROMene har andre navn (for eksempel AOKP eller CyanogenMod) betyr det ikke at de ikke er bygd på en offisiell Android-versjon (f.eks. 4.1). APIene som tilbys utviklere vil derfor være eksakt de samme, og vil ikke by på noen større utfordring for app-utvikleren.

Bloggposten til TweetDeck fremstår i et negativt lys og han glemmer også å ta med følgende sitat: “From our perspective it’s pretty cool to have our app work on such a wide variety of devices and Android OS variations.”. Det fremgår heller ikke av TweetDeck sin bloggpost at de har sett variasjonen i Android-utgaver som et problem. Så, kan det være at TweetDeck har sett “fragmenteringen” som et problem, men enkelt og greit ikke tatt opp dette i den aktuelle bloggposten? Nei. Som et eksempel på hvor forfedelig det er å utvikle Android-applikasjonern brukte Steve Jobs samme statistikk i en keynote i 2010. Dessverre for Jobs viste det seg at også han hadde tolket bloggposten på feil måte. TweetDeck sin CEO på den tiden, Iain Dodsworth, var raskt ute på Twitter og skrev følgende: “Did we at any point say it was a nightmare developing on Android? Errr nope, no we didn’t. It wasn’t.”

Nygård-Hansen fortsetter: “Det (utvikling av TweetDeck-appen, min anm.) høres ikke billig ut, og bortimot umulig hvis vi snakker om norske forhold.”. Her mistenker jeg at han ikke har inngående kunnskap om app-utvikling for Android . Som nevnt over har jeg tilgode å møte på store problemer knyttet til fragmentering ved utvikling knyttet til software. Ønsker man å bruke ny funksjonalitet på eldre Android-versjoner så lar dette seg fint gjøre med offisielle biblioteker for bakoverkompabilitet fra Google, og open-source tredjepartsbiblioteker (for eksempel ActionBarSherlock fra Jake Wharton). Her vil det også vært interessant om Nygård-Hansen og Thomas Olsson kan nevne én norsk app som det ikke vil la seg gjøre å utvikle for Android like raskt som til iOS. Jeg har fortsatt tilgode å høre om en.

 

Feilaktige tall fra Telenor

For å synliggjøre versjonsfragmentering på enheter i Norge bruker Nygård-Hansen tall fra Telenor som grunnlag. Men tallene han presenterer er etter hva jeg kan se både utdaterte og ukorrekte. Samsung Galaxy SII og Sony Ericsson Xperia Active er oppgradert til Android 4.0, og det samme gjelder meg bekjent også Huawei U8800. Tilbake sitter man altså med én telefon, Samsung Galaxy Gio, som har Android 2.3.6.

Nå virker det kanskje som om jeg ikke anser fragmenteringen i Android-versjoner som et problem. Det stemmer ikke. Leverandørene (HTC, LG, Samsung, Sony Ericsson m.fl.) fortjener all mulig kritikk for å ha vært sent ute med sine oppdateringer. Dette ganger ikke brukerne, siden det naturlig nok har kommet ny funksjonalitet i nyere versjoner (nytt UI i versjon 4.x, Project Butter, Google Now med mere). Men trenden har bedret seg det siste året. At enkelte (for eksempel LG med sin Optimus 2X)  likevel ikke publiserer videre oppdateringer til sin telefon snaut et år etter at de er lansert er utilgivelig, og skader Android sitt rykte.

At Google lanserte PDK (Product Development Kit) på Google I/O vil også forhåpentligvis sikre både raskere oppdateringer. Tradisjonelt har leverandørene fått tilgang til Android-kildekoden samtidig med deg og meg. Med PDK vil leverandørene få tilgang til kodebasen seks måneder i forveien av offentlig release, og kan allerede da begynne å arbeide med tilpasninger til sine enheter.

Over har jeg stort sett diskutert det jeg kaller versjonsfragmentering. Men er det også en negativ ting at man har flere ulike leverandører, med tilsvarende flere ulike enheter, alle med ulike hardware-spesifikasjoner? Når Nygård-Hansen skriver at det blir “bortimot umulig å utvikle” basert på de ulike hardware-spesifikasjonene som enhetene har, lurer jeg på om han har tenkt på alternativene. Det vil nemlig være et monopol, hvor én leverandør skal være enerådende i markedet. Slikt fører sjelden til hverken innovasjon, konkurranse eller prispressing – noe som kommer oss som kunder til gode.

Bedre markedsføringseffekt?
Nygård-Hansen argumenterer for at det er lettere å markedsføre en iOS-app. Her skal jeg være helt ærlig og si at jeg synes han presenterer et svært dårlig og lite underbygget argument. Uten en eneste kildehenvisning blir dette for meg stående som ren synsing.

Forretningsmodeller og inntjening
Her har Nygård-Hansen helt rett. At iOS-brukere bruker mer penger på apps enn Android-brukere er et velkjent faktum.

At Nygård-Hansen derimot bruker økonomiske forutsetninger finner jeg imidlertid mer problematisk. Om jeg igjen skal bruke min egen app som eksempel, så har majoriteten av enhetene (Samsung GS III, Samsung GS II, Samsung Galaxy Note, Samsung Galaxy Nexus, Samsung Galaxy Tab 10.1, HTC One X, HTC Desire HD og HTC Sensation) som brukes, en pris som ved lansering lå i samme prissjikt som iPhone eller iPad. At de samme brukerne ikke skal ha råd til å kjøpe apps har jeg derfor liten tro på.

En mer plausibel årsak, tror jeg, er at Google ikke har vært like flink som Apple til å få til en strømlinjeformet kjøpsprosess for applikasjoner. Android-brukere har for eksempel hatt Play Store-applikasjonen (tidligere Market) som en helt vanlig app i “appskuffen”. I Android version > 3 har man nå fått et sticky ikon øverst i nevnte “appskuffe”, og et ikon som møter brukeren på “hjemskjermen”.

Nygård-Hansen snakker bare om betal-apps, og glemmer at det finnes et marked for både gratisapplikasjoner (typisk markedsføringsapplikasjoner, for eksempel appen fra Rema 1000) og applikasjoner som bruker reklame for inntjening. Norske Zedge er et selskap som lykkes svært bra med denne forretningsmodellen. Med 22 millioner brukere og en app som brukerne stadig vender tilbake til sikrer man en langvarig inntektsstrøm, og ikke en engangssum som man ville fått med et engangssalg. Et liknende er eksempel er Wordfeud, som ikke trenger noen nærmere introduksjon, og som også har majoriteten av inntektene sine fra reklame.

Bruksaktivitet

Det kanskje svakeste punktet i bloggposten til Nygård-Hansen er et den ikke tar for seg trender i de tall og den statistikk som presenteres, men kun snakker om tall som er eller har vært. Med henvisning til statistikk fra Statcounter viser han nettbruk på de ulike OSene. På tross av at nettbruk ikke er direkte sammenlignbart med app-bruk, som vi har sett over, skal jeg likevel ta for meg denne grafen.

Av grafen kan man se av statistikken at iOS har hatt en andel på rundt 50% det siste året. Android hadde for ett år siden an andel på 26%, men har steget 11% til 36% i juni i år. Fortsetter denne trenden så vil Android altså ha tatt igjen iOS rundt neste sommer. (Oppdatering: Etter at denne kommentaren ble skrevet har FINN publisert sin statistikk for juli 2012 som understøtter overnevnte argument om Android også på web.)

En app utvikles ikke på én dag. Skal man lykkes med en app må måneder med nitid arbeid legges ned. Derfor er trender essensielt: det som er riktig i dag, er ikke nødvendigvis riktig om en måned eller et år.

Se på trender i stedet for historiske tall
Vi har alle sterke meninger om hvilken plattform eller produkt som er best, noe hverken jeg eller Nygård-Hansen legger skjul på.

Når plattformer har tilnærmet lik utbredelse mener jeg at man gjør lurt i å utvikle for de ulike plattformene i parallell. Tittelen på kommentaren til Nygård-Hansen impliserer nemlig at man skal utvikle en Android-applikasjon før eller senere, og sier indirekte at de økonomiske forutsetningene for utvikling til både Android og iOS  er tilstede.

Og hvis man må velge? Da mener jeg at trender er mer interessant enn historikk.

Getting Rid of Kernel Panics When Running The Android Emulator Under OS X Lion

Kernel Panic

Photo by badcrc (flickr)

After OS X Lion was released a few months ago, both me and a lot of other people have experienced

kernel panics at seemingly random times when running the Android emulator from Eclipse. Seemingly unrelated I also noticed that Eclipse sometimes used 100% CPU after it had been running for some time. I increased the heap space allocated to Eclipse, and after doing this the problem disappeared. What is even better is that this seems to have prevent the kernel panics from occuring as well, at least I haven’t experienced any since increasing the heap space.

Personally I set the minimum to 256MB and the maximum to 1024MB, which have worked well for me. But, this depends on the specification of your computer, so take a look at this guide for an idea of what values you should use.

The fix for the problem is easy. Find the Eclipse executable in Finder, double-click and select “Show contents in package”. Open the file eclipse.ini, located in Contents/MacOS. Adjust the memory allocation using the following values:

--launcher.XXMaxPermSize256m
-Xms256m
-Xmx1024m

Using Netflix Outside The US On Your Android Device

Europe had Spotify, the US had Netflix. Now the US has Spotify, but Europe still doesn’t have Netflix.

Time to do something about that. By using a US DNS provider you can access Netflix and similar services on your PC, Mac, Android device, iOS device and numerous other units. In this guide I will focus on Android, but it is also working perfectly on my Mac and Boxee Box, and should also work on whatever other device that has a Netflix application available for installation, and the possibility to set a custom DNS address.

Note! The following instructions will only work for rooted devices.

  1. Download the Netflix APK and create a Netflix account. Be sure that you have permitted installation of unknow sources by checking “Unknown sources” under Settings -> Applications.
  2. Using a file manager (I recommend Astro File Manager) open and install the APK you downloaded in step 1.
  3. Once the APK is installed it’s time to setup a custom DNS. I use UnblockUs. Register for an account on their site.
  4. Then, download and install Set DNS from Android Market. From the dropdown select “Custom”. Under DNS1 input 184.106.242.193. Delete whatever is set under DNS2.
  5. Open a browser, and open a random webpage. You should now be prompted to login to UnblockUs. Use the account details that you provided when registering in step 3.

If you have a rooted device, or don’t want to root your device, I guess that it is also possible to set the DNS in your routers DNS-settings.

Good luck, and enjoy :-)

Disable Fast Dormancy, Improve Battery Life On The Galaxy S II

By default, the Samsung Galaxy S II has Fast Dormancy support enabled. One of the goals of Fast Dormancy is to increase the battery life of a device, by limiting the amount of signaling between the phone and the cell network. But, when Fast Dormancy it is not enabled in the network and is enabled on the phone it ironically works the other way around, and actually drains more battery than before.

Luckily, Fast Dormancy can be disabled on the phone. For the Galaxy S II, do the following:

  1. Dial *#9900#
  2. Press “Disable Fast Dormancy
  3. Press “Exit“.

Easy as that!

I Norway NetCom has confirmed that they don’t support Fast Dormancy, while Telenor supports Fast Dormancy “to a certain degree”, whatever that means.

Fix For Low Microphone Volume On The Samsung Galaxy S II

Since I received my Galaxy S II a month ago, people have been complaining that they can barely hear me in calls. I first found out that turning off the noise reduction (by pressing the menu button while in call, and then pressing “Noise Reduction Off”) partially solved the problem, but this naturally also meant that the noise reduction feature was gone.

So I started click around the menus on the phone trying to find a way to fix this. At last it seems that I have found a solution:

  1. In the phone dialer type in *#*#197328640#*#*
  2. A menu should now be shown. In the menu, press  [5] AUDIO
  3. …then [1] NB (VOICE CALL)
  4. …then [1] HANDSET
  5. …then [1] VOLUME
  6. …then [1]SRC SPEECH RX Volume
  7. …then [5]5_lvl: 88 (note that you might have another value than 88 on your handset. Write down this value in case you want to revert to it later)
  8. The window that is now shown should have a line saying “Input?”. To input a new value press the menu button, then “Key Input”. Write 110 as the new value and press “OK“.
  9. You have now adjusted the microphone volume when noise reduction is disabled, and it is time to do the same when noise reduction is turned on.
  10. Press the menu button, and then “Back”. Do this four times in total, until you get back to the menu that the text “NB (Voice Call)” in the first row.
  11. Now, press [7] HANDSET(2MIC) and repeat steps 4 to 8 listed above.

I have had no complaints about the microphone volume after I completed these instructions. Hopefully it applies to you as well! The only downside with this trick is that it won’t survive a restart of the phone. A tip if you want to be unreachable without turning it off is by setting it in “Airplane Mode”. In this mode the phone barely consume any battery if it is not used.

Disclaimer: Although it is highly unlikely that it should happen, I take no responsibility if these steps should brick your device.

WebViewClient´s Error Constants

Android´s WebViewClient gives you an easy way of identifying errors when displaying webpages in your applications. The most convenient way to do this is through the use of the constants provided with this class. These constants were introduced in level 5 of the API, and are thus unavailable in the previous versions. When I needed them in a recent project using API level 4 I therefore dug them up from the API, et voilá, here they are for you as well:

    	public static final int ERROR_AUTHENTICATION = -4;
    	public static final int ERROR_BAD_URL = -12;
    	public static final int ERROR_CONNECT = -6;
    	public static final int ERROR_FAILED_SSL_HANDSHAKE = -1; 
    	public static final int ERROR_FILE = -13;
    	public static final int ERROR_FILE_NOT_FOUND = -14;
    	public static final int ERROR_HOST_LOOKUP = -2;
    	public static final int ERROR_IO = -7;
    	public static final int ERROR_PROXY_AUTHENTICATION = -5;
    	public static final int ERROR_REDIRECT_LOOP = -9;
    	public static final int ERROR_TIMEOUT = -8;
    	public static final int ERROR_TOO_MANY_REQUESTS = -15;
    	public static final int ERROR_UNKNOWN = -1;
    	public static final int ERROR_UNSUPPORTED_AUTH_SCHEME = -3;
    	public static final int ERROR_UNSUPPORTED_SCHEME = -10; 

Extend the WebViewClient class, copy and paste the error codes, and you’re ready to handle all those 404´s that might pop up.

Android Browser Not Loading Web Pages While On Wi-Fi

I recently came across a problem where the browser on my Nexus One would not load any web pages. More specifically I got the message “Web Page Not Available”, which typically shows when there is no internet connection available. The strange thing was that all other applications, e.g. GMail, had access to the internet.

To fix it, open Settings -> Wireless & networks -> Proxy settings. Press the “Clear” button, save, and reboot. If you’re as lucky as me, you should now have a working browser again.

Switch to our mobile site