Kategorier

Har iPhone et brukervennlig programmeringsspråk?

  • 19. februar 2010

    Postet av Kolbjørn Bredrup
  • Kommentar ikon  4

Det er ikke det at Objective-C og rammeverkene er dårlige. Men i forhold til andre nyere språk mener jeg at produktiviteten er lavere. Hvor er det så skoen trykker?

iPhone apps

For noen dager siden ble jeg intervjuet av NetCom om iPhone-utvikling  og om våre erfaringer med salg av iPhone-appen Sitater på norsk.
(Du kan lese intervjuet på NetComs iPhone-blogg.)

Jeg sammenliknet forskjellen mellom programmeringsspråkene Objective-C og C# eller Java ved å bruke en analogi om  forskjellen mellom norsk og gammelnorsk, og min påstand var at produktiviteten ved utvikling i Objective-C er lavere enn produktiviteten ved utvikling i c# eller Java.

Spørsmålet er altså om iPhones programmeringsspråk, som heter Objective-C, er brukervennlig i forhold til andre programmeringsspråk?

Brukervennlighet (usability)defineres slik på Wikipedia:

Usability is a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal.

Vanligvis tenker vi på brukergrensesnitt når vi snakker om brukervennlighet, men hvis vi ser på brukervennligheten til et programmerinsgspråk betyr det at vi ser på hvor lett det er å få laget det man vil, men også hvor fort man får gjort det. Ved programmering er det kombinasjonen av programmeringsspråkets mekanismer, hvilke rammeverk som finnes, og hvilket IDE (wikipedia) man bruker som avgjør brukervennligheten, og dermed i stor grad påvirker produktiviteten og utviklingshastigheten.

XCode IDE

I denne artikkelen viser jeg noen eksempler på forskjeller mellom c# og Objective-c for å bygge opp under analogien, og noen eksempler hvor forbedringer i Cocoa i ytterste konsekvens ville bidratt til en mer miljøvennlig verden (!).

Men først starter vi altså med noen syntaktiske forskjeller mellom C# og Objective-C.

Dot-notasjon

Dot-notasjon brukes til å kalle metoder eller properties på et objekt. Skal du kalle en metode på et objekt bruker nesten alle språk punktum på denne måten:
C#:

person = PersonService.GetPerson(4);
firstName = PersonService.GetPerson(4).GetFirstName();

Objective-c har denne syntaksen:

person = [PersonService GetPerson:4];
person = [[PersonService GetPerson:4] GetFirstName];

Hva man liker best er smak og behag, men det tar mer tid å taste inn et tegn “[" foran, en space i midten og en "]“ etter kallet enn det gjør å bruke et punktum i midten (selv om XCode hjelper bra til). Det er også lettere å knote til  syntaksen når man har parenteser inni parenteser.

Properties

Apple har nok sett at dot-notasjon kanskje er bedre, og har innført muligheten for bruk av punktum på properties i språkoppdateringen som kom i 2006. Koden man må skrive for å lage en property på et objekt er ganske forskellig i c# og objective-c.

I C# lager man en string property ved denne ene kodelinjen i klassen:

public string FirstName { get; set; }

I Objective-C gjør man følgende i header-filen (.h –filen):

NSString *firstName;
...
@property (nonatomic, retain) NSString *firstName;

og i klasse-filen (.m-filen) må man synthesize property‘en, og release strengen med dealloc:

@synthesize firstName;
...
[firstName release]

Det tar meg to sekunder å lage en string property i C#, mens det tar kanskje 20-30 sekunder i Objective-C, siden jeg må legge til kode fire steder i to filer.

Stringhåndtering

Stringhåndtering løses på forskjellige måter i alle forskjellige språk.  Det å sette to strenger sammen etter hverandre en en vanlig operasjon.

Syntaksen for å sette sammen fornavn og etternavn med en space mellom  er slik i C#

fullName = firstName + " " + surName;

I Objective-C må vi til med:

fullName = [
    [firstName stringByAppendingString:@" "]
    stringByAppendingString:surName
];

Eller man kan bruke string format-metoder, som her i C#:

fullName = string.Format("{0} {1}", firstName, surName);

Eller i Objective-C:

fullName = [NSString stringWithFormat:@"%s %s", firstName, surName];

Her mener jeg at syntaksen med + er mest elegant, lettes å lese og lettest å skrive.

Garbage collection

Jeg tror det var ca 12 år siden sist jeg release’et et objekt selv (i  C++), så jeg ble rent nostalgisk da jeg lagde min første dealloc-metode igjen. Objective-C fikk garbage collection i 2006, men det gjelder ikke for iPhone.

Man må altså selv passe på å rydde opp etter seg når man er ferdig med objektene, og jeg må nok innrømme at jeg glemmer det av og til. Men heldigvis har Apple laget et bra verktøy for å teste dette, slik at alle memory leaks blir borte før vi slipper appene ut fra utviklingsmodus. De har dermed laget en slags garbage inspector, mens jeg hadde spart tid hvis de isteden hadde laget en garbage collector.

Norske tegn

Jeg bruker ofte CoreData-rammeverket til lagring av data på iPhone. Et veldig bra rammeverk som gjør det lett å lage funksjonalitet for å legge til, endre og slette f.eks. favoritter slik:

Favoritter

Ulempen for oss nordboere og våre særnorsk bokstaver er at sorteringen av norske bokstaver i CoreData-databasen blir feil. Ø kommer etter Å. Jeg hadde samme problem for 15 år siden i noen gamle MSSQL-databaser, og  ble nostalgisk nok en gang  da jeg lagde mine egne sorteringsattributter og byttet ut “æ”,”ø”, og “å” med  ”[", "]” og “|” for å få riktig sortering, også på “aa”:

Sitater

Grunnleggende ting som korrekt sortering burde rammeverket håndtere automatisk.

Cocoa og “convention over configuration”

Hvis Apple hadde fulgt paradigmet convention over configuration når de lagde Cocoa ville rammeverket vært mer brukervennlig enn det er. Misforstå meg rett. Cocoa er et veldig bra rammeverk, men de kunne gjort det lettere å falle into the pit of success.

Poenget med convention over configuration er å gjøre den vanligste oppførselen til default oppførsel, slik at man ikke trenger å skrive kode med mindre man skal gjøre noe uvanlig. Vi snakker ofte om en 80/20-deling, hvor 80% av utviklerne gjør det samme, men 20% trenger å gjøre noe mer uvanlig.

UItextfield Et eksempel på dette er bruk av input-tekstfelt (UITextField). Default-oppførselen til et UITextField er slik at når man touch’er i teksfeltet kommer keyboardet fram (som jo er veldig bra og det man forventer at skal skje). Bruker kan da taste inn innhold i tekstfeltet og klikke på “Done.” Men hva forventer du at skjer når du klikker “Done”? Og hva er default-oppførselen til UITextField?

Jeg vil tro at i (minst) 80% av tilfellene vil det å klikke på ”Done” bety at bruker er ferdige med å taste inn tekst, og at keyboardet skal lukkes. Dermed tenker jeg at default oppførsel ved å klikke “Done” i et UITextView burde være at keyboardet lukkes. Men det som faktisk skjer default er ingenting, og keyboardet blir værende.

Hvordan lukke et keyboard?
Så det jeg og noen hundre tusen andre utviklerne må gjøre er følgende:
UIViewController’en som inneholder tekstfeltet må utvides til implementere protokollen UITextViewDelegate (dette gjøres i header-filen slik:):

@interface MyController:
UIViewController<UITextViewDelegate> {

I interface builder må jeg koble tekstfeltets delegate med MyController. Dette gjøres visuelt i XCode, slik:

MyController

Og i klassefilen til MyController må jeg implementere en metode som tar seg av lukkingen av keyboardet:

- (BOOL) textFieldShouldReturn:
UITextField *) theTextField {
    [txtFirstName resignFirstResponder];
    {txtSurName resignFirstResponder];
    return YES;
}

Første gang jeg gjorde dette brukte jeg kanskje 30 minutter, og måtte google litt for å finne ut hva man faktisk måtte gjøre. Nå vet jeg hvordan det gjøres, og da går det jo fortere.

Men hvis Cocoa hadde implementert default oppførsel etter convention og 80/20, og latt keyboardet lukkes av seg selv når man klikker “Done” ville det på verdensbasis vært kanskje 200.000 utviklere som hadde spart en halv time hver, eller altså 100.000 timer. Og så kunne heller de 20%(?) som synes at det ikke burde skje noe når man klikker “Done” implementert det.

100.000 timer koster våre kunder ganske mye penger, og 100.000 timer forbruker en god del strøm. Hadde rammeverket vært mer brukrvennlig vill det også være bedre for miljøet. (Litt far fetched kanskje men men…)

Så?

Jeg synes det er gøy å lage iPhone-apper, og jeg mener ikke at Objective-C og rammeverkene er dårlige. Men relativt i forhold til andre nyere språk mener jeg at produktiviteten er lavere, og det trenger man å ta hensyn til når man estimerer og priser iPhone-prosjekter.

Det vært veldig kult hvis Apple hadde utviklet språket Objective-C videre, og gjort det enda bedre slik at vi kan lage flere apper på kortere tid.  Kanskje ikke er så sannsynlig at det kommer noen særlig endringer her men …

Derimot ønsker jeg meg et noen lager et mer brukervennlig rammeverk, basert på 80/20-prinsipper med convention over configuration. Kanskje det allerede finnes noe slikt? Jeg vil ihvertfall tro at det finnes et marked for dette. Jeg er vel nærmest sykelig opptatt av produktivitet, og ville kjøpt det aller meste som øker utviklingshastigheten min enda mer, selv om jeg jo har blitt ganske rask nå også da. ;-)

4 kommentarer
  • Christian A. Strømmen
    28. februar 2010

    Kjekt å se litt diskusjon rundt Objective-C/Cocoa på norsk for en gangs skyld. Dette burde vi ha mer av!

    Objective-C er jo som du sier et gammelt språk, men det vil jo ikke si at det ikke har foregått en utvikling av språket siden det først så dagens lys. Etter at Next dro med seg Objective-C inn til Apple på slutten av 90-tallet har det kommet mange mindre oppdateringer til språket, og ved introduksjonen av Objective-C 2.0 i 2006 ble jo det sagt av Apple at de kom til å fortsette å videreutvikle språket aktivt, så jeg tror ikke du skal bekymre deg for at språket skal stagnere. Og snakker man om arv fra tidligere språk så er jo både Java, C# og Objective-C avarter av C, men jeg kan ikke se at noen av disse språkene nødvendigvis er umoderne av den grunn. Den moderne funksjonaliteten i alle disse språkene er jo mer å regne som tillegg til språkene, og krever ikke nødvendigvis et helt nytt fundament for å kunne regnes som moderne.

    Rammeverkene rundt iPhone OS er jo også under kontinuerlig utvikling med en major release hvert år, og var størrelsen på 2.0 og 3.0 en indikasjon vil nok de fleste innvendelser eller mangler bli rettet opp i løpet av de kommende årene. Husk at selv om dette bygger på Mac OS X sine rammeverk, så er det fortsatt et ganske ungt miljø. Ikke at det er en unnskyldning for eventuelle mangler, men det kan kanskje forklare hvorfor etablerte utviklere av og til føler de mangler enkelte bibliotek eller funksjonalitet. Personlig har jeg nylig opplevd at støtten for webservices er skremmende dårlig, men jeg tiltro til at dette vil bedre seg med 4.0 eller eventuellt 5.0 neste år.

    Når det gjelder dot-notasjonen så syns jeg personlig ikke dette har noe å si. Dette er mer en vanesak enn noe annet. Bruken av output fra andre metoder som input i en metode ser også mye “renere” ut i mine øyne med Objective-C, og det samme gjør oppdelingen av metodenavnet når man har flere parameter inn. Tror nok at dette er det som skremmer flest utviklere vekk fra Obj-C ved første øyekast da det ser ganske så fremmed ut for en, for eksempel, C#-utvikler. Men igjen er nok dette mer en vanesak enn noe annet.

    Properties er jo som du sier ganske så nytt for Obj-C, og jeg er forsåvidt helt enig at dette gjøres enklere i C#. Det samme gjelder garbage collection (som er borte fra iPhone av ressurs-grunner) i Objective-C 2.0. Dette er definitivt områder hvor Objective-C 3.0 har mye å lære fra språk som C#. Når det gjelder norske tegn så får vi krysse fingrene for at dette blir fikset i 4.0 til sommeren. Har du rapportert dette inn til Apple?

    Lukkingen av tastaturet er jeg derimot ganske uenig med deg i. Når man lager en UITextField i en iPhone applikasjon får man for det første tastaturet “innebygd”. Man trenger ikke gjøre noe for at dette skal komme opp når man trykker i et tekstfelt, da dette er den eneste naturlige konsekvensen av at en bruker trykker på et tekstfelt (med unntak av å ville kopiere teksten). Det som ikke nødvendigvis er gitt er hva som skal skje når brukeren er ferdig med tekstfeltet. Å fjerne tastaturet etter at man er ferdig med et tekstfelt er noe man burde unngå, og som kun vil være aktuelt for et fåtall tilfeller. I de fleste tilfeller vil jo brukeren gjerne at noe skal skje når de er ferdig å fylle ut informasjonen, som i ditt tilfelle ville det være naturlig med en “neste” knapp for det første tekstfeltet, og en “logg inn” knapp når de har fyllt ut det andre feltet. Å bare lukke tastaturet fører til et ekstra steg for brukeren når de da må trykke på en egen logg inn knapp i tillegg til done knappen.

    Derav er dette ikke standard, da dette antageligvis hadde ført til mange dårlige design-valg av utviklere som ikke har dratt denne konklusjonen eller som ikke har lest Apples iPhone Human Interface Guidelines. Denne knappen bør skreddersyes til et spesifikt formål hver gang man bruker et tekstfelt. Litt arbeid å lære seg første gang man gjør dette? Ja, men av god grunn.

    Takk for et flott innlegg Kolbjørn, selv om jeg kanskje er litt uenig i et par ting. I motsetning til andre utviklingsmiljøer mangler vi et aktivt forum for Mac/iPhone OS utviklere her i Norge, og jo flere som bidrar til en aktiv debatt slik du gjør her jo bedre!

  • Visit Norway samler sine mobilapper på én plattform | Nimble
    10. september 2014

    [...] 3,5 år siden skrev jeg et blogginnlegg om forskjellen på Objective-C og C#, og argumenterte for at utviklingshastigheten ved bruk av C# [...]

  • Ronaldphesy
    22. desember 2016

    Exactly as you say.

  • fitflop chaussures
    19. mars 2017

    fitflop chaussures…

    Har iPhone et brukervennlig programmeringsspråk? | Nimble…

Beklager, kommentarfeltet er stengt.