Cocoa Programming for Mac OS X - tråden för den som läser boken...

Får du det inte att fungera så säg till...

du måste spara filen innan du öppnar IB.

Jag lyckades med att öppna .nib-filen från IB utan att dubbelklicka på den i XCode. Men, som boken säger, man måste spara .h-filen som man editerar först, för annars vet ju inte IB hur klassen ser ut.

Det går att få det att fungera enbart med IB (dvs utan att gå via XCode) men då måste man importera .h-filerna först. Det gör man i menyn Arkiv->Read class files.

Kan å kan. Det blir mycket, mycket, lättare om man använder XCode och hanterar både källkod och IB genom XCode. Speciellt om man försöker lära sig tycker jag att man skall börja med att använda XCode och IB därifrån. Nuvarande version har ett mycket bra stöd för att synkronisera ändringar i källkodsfilerna. Det går helt enkelt lättare att utveckla så. Gör det bara, vettja

Som Xcode-nybörjare har jag svårt att fatta varför Xcode och IB ska vara två program. Har just börjat ta upp programmering i OS X, men har för några år sedan kodat för Windows i Visual Basic, Delphi och C++ Builder. I dessa program var allt integrerat och lättbegripligt. Jag antar att de har kommit än längre med användarvänligheten sedan dess, men Xcode fattar jag ingenting av trots att jag inte anser mig själv vara "trög" när det gäller att ta till sig nya miljöer

Det finns många åsikter om XCode. En av dem är just den du uttrycker, att det är svårt och krångligt att förstå sig på.

Jag har själv en fråga angående boken. Började läsa idag och de nämner att jag ska ha nib-filer i projektet, men har bara xib-filer som verkar uppföra sig på samma sätt. Är det något nytt som släpptes efter boken skrevs? Vad är skillnaden i så fall?

xib är nib som inte är kompilerad. Du kan använda dom på samma sätt.
Xibbar är the new black

Instämmer.

Tänkte ta tillfället i akt och fråga efter bra bundles eller plugins till Xcode? Som förbättrar för oss nybörjare/utvecklare?

för att förtydliga lite, xib är "ren" XML, och fördelen med detta är bla att det fungerar bra om man jobbar med versionshantering.

ett tips i övrigt om man är intresserad av att lära sig att utveckla för mac är att ladda ner senast xcode (version 3.1) istället för den som följer med leopardskivan (som är 3.0) det är en hel del skillnad och på många sätt betydligt bättre och enklare att använda.

Har precis börjat komma in på deklarationer av objekt, och jag vet inte om det är jag som är extra trög idag men har lite svårt att förstå vad som egentligen händer. Kanske ni skulle kunna förklara lite bättre?

NSMutableArray *array;
array = [[NSMutableArray alloc] init];

Som jag förstått det deklarerar man en pekare, array, som pekar till en instans (vilket är ett objekt av en klass) av NSMutableArray.
Därefter allokerar man utrymme till denna instansen, för att sedan initiera den.
Rätt?

Det är väl främst andra raden som inte riktigt sitter som den ska. Allokerar man inte utrymme till instansen redan när man deklarerar den, och vad är det egentligen init innebär? Att den initieras säger mig inte så mycket jag önskar att det gjorde.

Nej, den första raden säger bara till kompilatorn att du vill ha en pekare till en NSMutableArray, vilket namn pekaren ska ha. Utrymme för pekaren allokeras på stacken.

alloc på andra raden allokerar minne för ett NSMutableArray-objekt. init skickas sedan till det allokerade objektet för att göra det klart för användning. Till slut sätts pekaren till det nyligen skapade objektet.

Objektet kommer att leva kvar i minnet tills du väljer att skicka release till det.

Nej, du skaffar bara utrymme till en pekare. Variabeln du deklarerar är en pekare som du kan använda till att peka på objekt som redan finns, eller ett objekt du strax skall allokera.

Då den är allokerad vet du ingenting om vad objektet innehåller. Potentiellt sett kan det innehålla skräp och goja (även om det kanske inte blir så i praktiken). Då du initierar objektet så "nollställer" du det. Först då vet du att du har en ren och tom array.

Ah, nu känner jag mig genast lite mer förståndig. Jag tackar och bockar!

Det finns en del fallgropar/svårigheter och saker som upplevs som ologiska eller knöliga. Samtidigt som vissa grejer är så genialt enkla och briljanta (testa något coredata-exempel så får du se på magi), så kan andra grejer upplevas som direkt idiotiska.

Men håll ut; Aarons bok är bra. Kanske inte väldigt bra, men definitivt en av de bästa. Läs den från pärm till pärm (fuska inte). Ett tips är att läsa tre kapitel, när man gjort det hoppar man tillbaka läser dom igen. Läs ytterligare tre kapitel, hoppa tillbaka och läsa igen. Då fastnar det till slut.

Det finns en inlärningskurva som i vissa fall kan vara lite väl brant, speciellt om man sysslat med "rak" programmering a'la VB. Bara grejen med att allokera i minnet och pekare som pekar på den delen av minnet kan ställa till en del frågetecken i början;

Om man sätter två variabler i VB; a="FOO" och B="BAR" och ställer frågan IF A=B får man ju FALSE. Gör du samma grej med två NSString, sätter dom till samma innehåll som ovan kommer du att få TRUE om du gör en direkt "IF A=B"-jämförelse. Varför? För att i ObjC-jämförelsen så är det två pekare du jämför, inte innehållet i dessa.
I ObjC skulle du istället skriva "if ([a isEqualToString: b])"

Allt sånt kan göra en lite tokig i början. Men som Aaron skriver i boken (har jag för mig); "det _är_ svårt och det är inte du som är dum".

Nu lägger jag mig i också.. Det var ett tag sen jag läste om pekare.. jag känner till det där men jag fattar inte varför den inte reagerar på att det är två olika pekare/de pekar på olika saker?

När du säger att VB är "rakare" menar du då enbart att det är mer högnivå och inte så mycket trassel med pekare och minneshantering?

jag kanske var lite otydlig; VB är mer linjärt och för många lite mer logiskt. det är ju oftast bara att lära sig en syntax och sätta igång.
En objektorienterad miljö som ObjC kräver en hel del nya konceptuella baskunskaper. Dessutom är det onekligen krångligare med pekare och minneshantering, även om det såklart är betydligt smidigare och vettigare när man väl lärt sig.

Resultatet blir ju betydligt bättre och snyggare kod med ObjC/SmallTalk/etc än med spagettiprogrammering a'la VB.

Tycker jag alltså

/ja, det är ett annat konto, mitt andra råkade jag låsa av nån anledning

Nu är vi på väg mot ett programmeringsspråkskrig, men jag kan inte låta bli... Pratar du om gamla VB 6 och tidigare här eller? Isf håller jag med om att det är lite spaghetti över det. VB.NET (som kom 2002 och är det enda som används numera) är helt objektorienterat och jämlikt med t ex C# (om inte bättre).

Att pekare och manuell minneshantering skulle vara "smidigare och vettigare när man väl lärt sig" har jag svårt att se. Möjligen att det är lite "coolt" att jobba närmare hårdvaran. Men det finns ju en anledning till att programmeringsspråk hela tiden blir mer och mer högnivå, och det man ser till att bli av med är just att behöva sköta sådant manuellt (det tar massor av tid, ger snudd på inga fördelar, och ger hemska buggar när man missar något). Jag är uppriktigt nyfiken på vilka fördelar du ser med att manuellt behöva ägna sig åt detta.

Tror det är vettigt att känna till hur en dator fungerar på åtminstone det abstraktionslager närmast under det man jobbar på. Om man programmerar med garbage collection, tror jag man kan lyckas skriva ett riktigt slött program om man inte har en aning om hur GC fungerar.

Fördelen med Obj-C är ju att du i någon mening kan välja abstraktionsnivå:

Du kan skriva med GC, och inte bry dig om minneshanteringen alls. Att det fungerar är ju nya Xcode ett exempel på. Men Xcode använder sig av (eller skickar data till) GCC (the Gnu Compiler Collection) för kompilering. Är det möjligt att tänka sig GCC med GC? Skulle det finnas några problem med det? Skulle man kunna tänka sig något spel med GC?

Du kan använda den gamla Obj-C metoden med retain count. Detta kan ju vara vettigt om du skriver ett mycket minnesintensivt program, som riskerar bli alltför långsamt med GC. Risken ökar ju då för läckor och krascher, och det blir något råddigare att programmera.

Du kan optimera en metod genom att skriva den som ren C-kod, eller t. om. göra om en metod till att bli en C-funktion (om en kort metod anropas tillräckligt ofta tillbringar datorn, relativt sett mycket tid med att skicka meddelanden till metoden).

GC måste du välja att slå på eller av för hela ditt program. Men du kan skriva ett helt Obj-C program och bara skriva om en metod i C (förslagsvis den som är flaskhalsen)

Vänligen, Ylan