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

Tråden skapades och har fått 48 svar. Det senaste inlägget skrevs .

Jag tänkte börja leka lite med ObjC, jag har länge velat lära mig ett programmeringsspråk men har aldrig funnit inspiration till att lära mig något efter de 10 poängen i C.
Det var inge roligt att ta dem men men säkerligen nyttigt.

Sitter då på OS X och insåg att det nog vore skoj att lära sig ObjC så i tråden om vilka böcker man ska välja valde jag båda föreslagna. Nu har jag börjat läsa och jobba mig igenom Cocoa Programming for Mac OS X.

Men jag falerar på första exemplet, RandomApp.
Problemet som uppstår är när jag ska göra en instance av min klass Foo.
Det ska jag göra i Interface Builder men i Identify Inspector ska jag sätta klassen till Foo.
Jag kan inte välja Foo i drop menyn, skriver jag in det för hand får jag inte med in- & outlets.
Författaren skriver att om det inte sker är det något fel i Foo.h.

//
//  Foo.h
//  RandomApp
//

#import <Cocoa/Cocoa.h> 
@interface Foo : NSObject { 
    IBOutlet NSTextField *textField; 
} 
-(IBAction)seed:(id)sender; 
-(IBAction)generate:(id)sender; 
@end

Det funkar inte ens när jag kopierar texten från boken.

Vad gör jag för nybörjarfel?

Jag tror mig hittat felet om jag gör som det står i boken kanske det funkar...

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

Det fel jag gjorde var att jag öppnade Interface Builder (IB) själv och inte via XCode vilket gjorde att kopplingen saknades mellan IB och projektet.

  • Medlem
  • Stockholm
  • 2008-08-01 21:01

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

Det vet jag inte om jag gjorde eller inte men nog ska det gå att öppna .nib filen från IB istället för att dubbelklicka på den i XCode?

  • Medlem
  • Stockholm
  • 2008-08-02 08:21

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.

Ah du har den boken du med... och en än gång har jag inte läst tillräckligt noga.
Mmmm jag har dåligt tålamod och läser därav snabbt och uppenbarligen slarvigt.
Jag ska skärpa mig och inte tappa fokus.

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.

  • Medlem
  • Stockholm
  • 2008-08-02 22:59

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

  • Medlem
  • Stockholm
  • 2008-08-03 01:09

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

  • Medlem
  • Mölndal
  • 2008-08-03 09:26

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å.

  • Medlem
  • Göteborg
  • 2008-08-03 11:59

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 = xml kind of

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

Ahhh den frågan hade även jag. Super!

Skönt att se att det finns några stycken som kan hjälpa till när vi nybörjare springer på problem.

Ursprungligen av Mattias Hedman:

Ahhh den frågan hade även jag. Super!

Skönt att se att det finns några stycken som kan hjälpa till när vi nybörjare springer på problem.

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.

Jo jag drog ner 3.1 och jag har tittat på 3.0 förut och undrade ett tag om det var samma program.

  • Medlem
  • Göteborg
  • 2008-08-03 16:09

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.

Senast redigerat 2008-08-03 16:41
Ursprungligen av Kanin:

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.

  • Medlem
  • Stockholm
  • 2008-08-03 18:56
Ursprungligen av Kanin:

Allokerar man inte utrymme till instansen redan när man deklarerar den

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.

Ursprungligen av Kanin:

, och vad är det egentligen init innebär? Att den initieras säger mig inte så mycket jag önskar att det gjorde.

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.

  • Medlem
  • Göteborg
  • 2008-08-03 19:17

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

Ursprungligen av Kanin:

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".

  • Medlem
  • Stockholm
  • 2008-08-03 21:51
Ursprungligen av thompabompa:

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.

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?

  • Medlem
  • Mölndal
  • 2008-08-03 20:31

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?

Ursprungligen av memark:

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

  • Medlem
  • Mölndal
  • 2008-08-04 02:15
Ursprungligen av thompabompa2:

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.

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.

  • Medlem
  • Stockholm
  • 2008-08-04 06:38
Ursprungligen av memark:

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

Ursprungligen av memark:

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).

Ja, det var det ja menade. Annars hade jag skrivit VB.NET

Ursprungligen av memark:

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.

Jag kanske var otydlig; det behöver inte vara smidigARE att göra sånt själv, jag menade att det var smidigt när man väl lärt sig.

Själv gillade jag skarpt gamla HyperTalk (Hyper Card alltså), för er som inte kommer ihåg/vet, ett programmeringsspråk som var ganska likt vanligt språk. Så man behöver inte gilla en viss nivå rakt av, man kan gilla/förespråka flera

Vill man ha datakrig/språkkrig/teknikkrig är det nog bättre att hänga i IDG.se's forum

Vad skönt att jag hänger med i snacket än så länge.

Bra tips det där med 1 steg framåt 3 tillbaka för att verkligen allt ska fastna.
Det är lätt att ha bråttom när man kör själv och på så sätt fastnar inte allt.
En sak jag då gör är att jag handskriver i alla exempel och buggrättar mina egna fel bara för att bli lite mer van.

Jag håller på att tränga genom Kapitel 3 i Aarons bok, efter detta ska jag faktiskt gå tillbaka till kapitel 2 och tränga genom det igen.

Bevaka tråden