Xcode 4

Jag tittade igenom en WWDC-presentation om Apples utvecklingsverktyg (allt från WWDC 10 finns på iTunes), och Xcode 4 verkar kunna bli the shizzle, jämfört med Xcode 3 som är typ scheisse:

- Ett fönster. Inte tusen fönster. Ett fönster. Steve Jobs har uppfunnit the one window application. Hurra för Steve Jobs!

- Interface Builder finns integrerat i Xcode. I det enda fönstret. Man kan se dem samtidigt, man kan dra outlets och actions från buildern till källkoden.
- LLVM tar hand om kod-komplettering och att berätta för en när man stavat fel till saker. På demona ser det fett ut, hur det ser ut i verkligheten vet jag inte. Man blir lite orolig när presentatörerna står och säger positiva saker om hur bra editorn i Xcode alltid har varit, medan jag själv tycker att den är pinsamt långsam ganska ofta.
- De har gjort något åt svn-stödet, och förhoppningsvis fått det att funka. Och lagt till stöd för git. Och en diff-viewer med timeline. Och i motsats till t.ex. Versions så ska de tydligen ha stöd för både branch och merge. Förhoppningsvis på ett sätt som är användbart, snarare än som i Tortoise, där merge-funktionaliteten är så kryptisk att man ändå blir tvungen att göra det från kommando-raden.

- En ny debugger, LLDB. De sa mest att den är snabbare än gdb, jag hoppas att den har mer att komma med, t.ex. debuggning av optimerad kod.


Jag sa så sent som för någon vecka sedan om Xcode att det är uppenbart att det har utvecklats helt utan inblandning från Apples legendariska interaktionsdesigners. De verkar ha kallats in till Xcode 4. Att basera vyer på filter/sökningar känns ganska mycket mer 2000-tal än statiska hierarkier. Däremot antar jag att mindre sexiga delar av UI:t, som t.ex. projektinställningar, fortfarande är en enda röra. Jag skulle vilja se en kompetent interaktionsdesigner stoppa det i sin crack-pipa och röka.

Sen vill jag inte hypea det här för mycket innan jag har testat själv, det som visas i presentationen är bara den yttersta ytan . Ingenting sägs t.ex. om sådant som sub-projekt, som antagligen kommer fortsätta ofunka även i Xcode 4.

Om att vilja springa iväg

Jag tittade lite på OCTest, ett unittest-framework för Objective C, som är integrerat i Xcode. Det lät inte så dumt, och det var lätt att komma igång med, även om artikeln på Apples developer-sajt verkade vara runt 8 år gammal och helt inaktuell.

Jag skrev lite tester och skrev lite kod och det funkade alldeles utmärkt, tills ett av testerna failade och det inte var uppenbart för mig hur jag skulle fixa det. Jag testade att sätta en breakpoint. Inget resultat. Testerna körs som ett steg i bygg-fasen av en separat app, så breakpoints man sätter i Xcode funkar givetvis inte.

"Tänk om någon annan på internet har haft samma problem som jag", tänkte jag. Mycket riktigt, det hade någon, som dessutom har bloggat om hur man får det att funka. Synd då att svaret är typ "gör 3000 inställningar, med kommandoradsparametrar och environment-variabler och annat jobbigt".

Som någon skriver i en kommentar: "This makes you want to run away from unit testing. Thanks for the write-up, Chris. But this so should be easier." Svårt att inte hålla med där. Och svårt att förstå hur man kan välja att integrera ett unittesting-framework i ett IDE och inte göra det möjligt att på något smidigt sätt debugga. Men när man hamnar under den polerade ytan på OSX så brukar det vara så här: det liknar väldigt mycket hur det var att köra Linux för 10 år sedan.

Dessutom är det trist om man försöker printf-debugga och råkar hamna i en oändlig loop. Det går inte att avbryta körningen med mindre än att man dödar test-processen. Om man sen försöker titta på utskrifterna så är det givetvis så ansträngande att Xcode antingen går in i badbolls-läge för evigt eller lägger sig ner och dör.

Donald Jobs

Jag hade tänkt kommentera det här med att utvecklingsverktygen till Mac känns lite Kalle Anka ibland. Tidigare har jag berättat om de positiva aspekterna, och det jag har gnällt på har gällt hanteringen av öppna filer i Xcode, som jag har insett hur man jobbar med på ett vettigt sätt.

Men några exempel:

Xcode har inget stöd för subprojekt, vilket finns i alla andra IDE-er jag har använt: Visual Studio har det, CodeWarrior hade det, Eclipse har det. Xcode har fastnat i någon idé om att man utvecklar libs/frameworks och appar separat, och att man inte vill vara inne och gräva i lib-kod när man skriver appar. Men det är inte tillräckligt generellt, det täcker inte in alla fall. T.ex. inte min situation på jobbet, där jag har ett framework, som är det jag utvecklar, som jag har olika frontends till. För frameworket (som i sin tur består av flera libs) vill jag ha separata projektfiler, som jag kan inkludera i projekten som jag bygger frontendsarna med. Nicht gut, säger herr Jobs, innan han går över till sin Monika Danielsson-röst och säger "det _vill_ du inte göra".

Det verkar inte finnas någon riktigt vettig grafisk frontend till Subversion. Jag gjorde en utvärdering och kör sedan dess Versions, som är bättre än att använda kommandoraden, men inte har stöd för merge och inte riktigt verkar fatta externals. Det känns nästan lite som en förolämpning när Apple väljer att ge pris till utvecklarna av programmet. Hur som helst, vill jag göra en merge eller uppdatera en katalog med externals till en viss version så är det kommandoraden som gäller.

FileMerge, som är Apples eget diff/merge-verktyg, är något av ett skämt. Man kan inte editera texten manuellt, utan kan bara välja den ena eller båda text-sekvenserna som diffar. Dessutom finns det ingen information om vilka snabbtangenter man kan använda. Jag har inte listat ut hur man väljer både versionerna. Klick, klick, klickety-klick. Eventuellt finns det bättre merge-verktyg, det har jag inte haft tid att kolla upp. (Dessutom är det fult och har dålig syntax-highlighting. Låna koden från Xcode, kanske?)

På WWDC var jag på en presentation om vad som var nytt i Xcode, där fick jag lära mig att det finns en feature i Xcode som kallas Snapshot. Man kan ta snapshots av sin källkod och gå tillbaks till tidigare snapshots. Om det nu finns Kalle Anka-kodare som inte har vett nog att använda ett versionshanteringssystem, är det då bättre att ge dem ett enklare sätt att sköta lokal backup-hantering än att tala om för dem att det finns något som kallas versionshantering och som är ett mycket bättre alternativ? Eller är det så att Xcode-utvecklarna själva inte har koll på hur man använder versionshantering på ett vettigt sätt?

Det här är detaljer, men detaljer som stör om man bara vill kunna göra vettiga grejer med vettiga verktyg. Det är som om det finns någon uppfattning om att nybörjare som kodar Hello World-program är de viktigaste användarna. Men visst, samtidigt har vi DTrace, Instruments, Interface Builder och LLVM som pekar i en annan riktning. Om några år kanske allt är riktigt bra, och jag kan sluta gnälla.

Sluttwittrat och wwdcbörjat

Som jag sa på twitter tidigare idag: nu lägger jag ner twitter. Jag fattar inte poängen med det. Det ger mig ingenting. Det är jobbigt att följa andras kvitter och det känns som om det enda man kan säga är att posta länkar. Det blir helt enkelt väldigt lite substans på 140 tecken.

WWDC började idag. På keynoten sas väl ungefär vad jag hade väntat mig: mycket Snow Leopard, mycket iPhone-OS 3.0, en ny iPhone med ungefär vad man hade väntat sig. Det var några detaljer som var bra, t.ex. video-editeringsmöjligheterna på nya iPhonen och i nya Quicktime.

WWDC är väldigt välarrangerat i allt utom maten, som man får mindre av än läsken och snacksen. Alla presentationer under dagen har varit välrepeterade. Jag har installerat Snow Leopard. VPN funkar inte, vilket kanske löser sig under morgondagen. Nu ska jag titta närmare på nya Xcode.

Ska de va så svårt då?

Vad är svårt när man försöker lära sig Cocoa?

Objective-C: 19%

Om det är ett ganska klassiskt objekt-orienterat språk som är det värsta med att lära sig Cocoa så låter det som beröm till Apple. Beroende från vilket håll man kommer ifrån så är det olika saker man tycker är krångligt med Objective C.

I Didn't Know ANSI C: 12%

Det kan låta som science fiction för vissa av oss: någon gång i framtiden, t.ex. 1984, så finns det folk som programmerar men inte kan det etablerade standardspråket C. Men nu för tiden får man inte ens lära sig det när man pluggar datavetenskap. Tydligen är det alldeles för nischat att syssla med sådana lågnivågrejer nu för tiden, trots de ganska uppenbara pedagogiska fördelarna med att utgå från hur hårdvaran ser ut. Det är en sådan där sak som det är svårt att få in i huvudet utan att skriva kod.

Cocoa is Really Big: 11%

Översatt till svenska: jag är för inkörd på ett specifikt ramverk. Vet man ungefär vad som brukar finnas och hur det brukar se ut så är ett klassiskt designat system som Cocoa väldigt lätt att hitta i. Sen finns det naturligtvis en massa detaljer som är oklara, men sådant har en förmåga att släppa ganska fort. Åtminstone inom ett par år, vilket är ungefär vad som behövs för att lära sig en programmeringsmiljö ordentligt.

Memory Management: 10%

Låter som en underkategori till Objective C och I didn't know ANSI C. Minneshantering är ofta klurigt när man ska lära sig ett nytt språk som är mer eller mindre högnivå än vad man är van vid. Själv trodde jag att jag skulle göra det lättare för mig genom att slå på garbage collection. Det gav mig istället kluriga problem när jag skulle blanda ihop vanlig C-kod och Objective C.

Interface Builder and NIBs/XIBs: 10%

Ja, det är en del magi som pågår här. Det blir mindre kod att skriva, men saker blir inte mer nybörjarvänliga för att man flyttar ut dem till ett grafiskt verktyg. Det är snarare så att det är mer kryptiskt i början, innan man har lärt sig hur det verkligen funkar under ytan. Personligen har jag mycket lättare att förstå Glade, där det bara finns callbacks. Men om man sätter sig in i data bindings så kan jobba mer effektivt med Interface Builder, istället för att koda sina observers själv.

I Was Used to Java or C++: 10%

Ännu en språkkategori.

Delegates: 8%

Nu ser jag ut som ett frågetecken. Kanske är det dokumentationen, kanske är det att de som har valt det här alternativet helt enkelt röker för mycket hasch, eller så är det jag som är för 1337. Delegates är ett ganska grundläggande koncept, så om man har svårt att förstå det så har man nog helt enkelt programmerat för lite.

Overall Cocoa Model: 8%

Javisst, det är det här som det tar tid att lära sig. Och kanske är ovanstående punkt helt enkelt ett specialfall av den här. Man kan lära sig att göra grejer ganska snabbt, men att förstå hur man ska göra dem på bästa sätt tar en massa tid.

I Didn't Know Object-Oriented Programming: 8%

Samma som ovanstående punkt: det tar tid att lära sig en ny typ av språk. Det är som Othello: det tar en minut att lära sig reglerna (eller kanske en vecka) och en livstid att bemästra (eller kanske ett par år).

Learning How Documentation is Structured: 5%

Jag vet inte om det är strukturen på dokumentationen som är problemet. Den är helt enkelt dåligt strukturerad. Det finns en väldig massa dokumentation, men jag har inte hittat något vettigt sätt att navigera i den, bortsett från att skriva saker i sökrutan. API-referensen är för kortfattad och guiderna är alldeles för pratiga. Ungefär som det brukar vara alltså.

Cocoa Bindings: 5%

Ett specialfall av Overall Cocoa model och/eller Interface Builder.

Xcode: 3%

Det här handlar mer om frustration. Det är rätt okej som IDE, men på många sätt har den bit kvar till Visual Studio, Eclipse och t.o.m. Codewarrior. Framför allt gäller det debuggern och det knepiga fönsterhanteringssystemet.

Pristävling!

Dock utan något vettigt pris. Men whatever. Hjälp mig fixa en fin ikon till Lister. 512x512 pixlar i något vettigt format, typ PNG. Den som vinner, vinner inte bara juryns gunst utan även äran i att ikonen kommer synas på skärmen hos alla som kör Lister för att unfuxxora Xcode.

Som inspiration så erbjudar jag följande ord och fraser:

- White ninja
- X
- Kärlek
- Ödlor
- Dans
- Bra data
- Matprodukter.
- Food products.
- Spökis hoaaa... hoaaa...
- Trollstav
- Spijkenisse
- Listor av saker man vill göra
- Nu får du väl för i helvete ta och kamma till dig!
- Dödskalle

Freedom!

Vi har haft fria aktiviteter på jobbet i dagarna två. Jag hade tänkt lägga dem på att lära mig lite om shaders, men ändrade mig till att titta på Core Animation istället. Core Animation är Apples API:er för compositing och animationer i UI:t.

Jag började med att titta lite på att animera UI-komponenter, men det var ganska trist, så jag gav mig på lågnivå-API:erna istället, så jag slängde ihop ett fönster med en custom view i Interface Builder. Sen började jag lägga in lite lager med olika innehåll: text, genererad grafik och film. Jag avslutade med att testa lite olika blend modes. Om du har en Mac och är intresserad så finns min fina demo-app att ladda ner här. Tryck på space för att få nya saker att hända.



Så vad har jag lärt mig? Core Animation är ganska smidigt att jobba med, även om det för en nybörjare är vissa saker som är smått ointuitiva. T.ex. så fattar jag inte riktigt det här med att inställningen av storlek på lager är så tillkrånglad. Det krävs ganska mycket kod för att lägga till animationer, men den är enkel att wrappa i hjälpfunktioner. Det känns ganska trevligt att man kan göra allt genom att helt enkelt skriva Objective C-kod, snarare än att behöva slajda runt i någon editor eller skriva saker i något domänspecifikt språk. Nu är jag inte den som anser att det är en brist att man skriver det mesta av sitt UI i XML i Cascades, men som nybörjare känns det ganska tryggt att kunna sköta rubbet i Objective C.

Det finns dock någon typ av grafisk editor, som heter Quartz Composer, som jag inte orkade titta på speciellt mycket. När det gäller sådana grejer så känner jag att inlärningströskeln är ganska hög för min del.

En dålig sak jag upptäckte var att gdb-integrationen i Xcode, och delvis gdb själv, är sämre än vad jag tidigare trott. Jag har i och för sig inte läsa på så mycket om det, men det är nu ganska uppenbart för mig att debuggern är ganska mycket sämre än den i Visual Studio.

Allt som allt är det dock ännu mer win för Apple.

Linus - Xcode 1 - 0

Xcode är svårjobbat av en anledning: det envisas med att öppna varje källkodsfil i ett eget fönster. (Det finns sätt att ha flera filer i ett fönster och växla mellan dem, men inte på något vettigt sätt.) Om man har ett projekt med ett par tusen källkodsfiler och en djup katalogstruktur så funkar det inte att växla mellan filer genom att klicka på dem i projektvyn, och Exposé hjälper inte när man har 30 öppna fönster med vit bakgrund och svart text.

Kommer man från Visual Studio så kanske man tror att tabbar för källkodsfiler är en bra idé. Det är det, om man inte har flera än 8-10 stycken öppna, i så fall duger inte det heller. Det jag vill ha är en vertikal lista, sorterad i bokstavsordning, eftersom det skalar bättre.

Så jag gav mig på att skriva ett program som listar Xcodes öppna fönster, visar dem i en lista som hålls uppdaterad när man öppnar och stänger fönster, och där man kan visa ett fönster överst genom att klicka på dess namn i listan. Det var lite knepigare än vad jag hade trott, inte minst för att jag inte kan varken Objective-C, Cocoa eller Interface Builder. Men det gick att få till i alla fall, även om det är ett antal grejer i implementationen som är rätt märkliga. Såhär kan det se ut:



Vill man testa så finns källkoden här: http://www.puterman.se/lister-0.1.zip

För att få det att funka så måste man slå på möjligheten att pilla på programs UI:n utifrån, vilket man gör genom att gå in i System Preferences, till Universal Access och där kryssa i Enable access for assistive devices. Jag har inte en aning om varför det inte är påslaget som default, men så är det.

Saker som återstår att fixa:

• Inställningar, t.ex. kanske man vill använda det här med andra program än Xcode.
  
• Pollnings-intervall, det är just nu hårdkodat till 5 sekunder, d.v.s. det är så ofta fönsterlistan uppdateras. Det bästa vore givetvis om man kunde sätta en observer på appen man vill bevaka, men det är jag osäker på om det går.
  
• Sökning i listan via textfält, så att man kan börja skriva namnet på fönstret man är ute efter.
  
• Hitta på lite mindre märkliga lösningar i koden. Det borde gå att göra utan att embedda AppleScript, plocka events från listan via shouldSelectRow etc.
  

Men för tillfället är jag hyfsat nöjd. Nu ska jag ut i solen.