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.

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.

woes of the n00b

så jag tänkte att jag skulle fixa klart en 0.2 av lister men det går inte så bra för jag vet inte hur man kan få tableviewen av ändra storlek när man ändrar storlek på fönstret det borde gå automatiskt i och med att autoresizes subviews är ikryssat överallt i buildern men det kanske inte alls betyder vad det låter som att det skulle betyda och eventuellt måste jag hålla på och ta hand om delegerade saker någonstans ifrån men det borde bara funka automatiskt jag har säkert gjort något idiotiskt n00b-fel men det finns inget sätt att få reda på det och inte ens google verkar ha något att komma med så det är lite jobbigt i övrigt har det inte hänt så mycket med programmet jag är ganska nöjd med det så när jag har fixat lite mera smågrejer så kommer det kanske snart en version 1.0 och stor internationell lansering med tårta och fyrverkerier vi får se

sen en liten reflektion över det här med klassiska ui-toolkits som cocoa det blir väldigt stora api:er eftersom man låter ett lager i api:et ta hand om både kontrollen och det visuella vilket gör att api:ets storlek exploderar och man får tusentals kontroller eftersom en kontroll inte bara måste ta hand om kontrollen utan dessutom måste klara av att se ut på olika sätt vilket en typisk kontroll inte klarar så man får göra en ny kontroll om man vill att den ska se lite annorlunda ut mwc for the win yo och om man applicerar det på viewen så inser man att ui-toolkit inte är en view utan en kombination av control och view

nu är jag lite trött på att skriva oläsbar skit så nu ska jag posta det här

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.