Beginning to learn Obj-C

This is the best book there is for learning the basic language: http://qgf.in/crUpxP

I've read it cover-to-cover several times; it was a gift from clanmills (who knew Obj-C and therefore had no use for it). The first part covers the underlying C language (loops, decisions, etc.), the second part covers Foundation (NSStuff), the third is a brief intro to Cocoa (writing an iPhone app). Very, very good for people who know no C or very little.

Buy both Programming in Objective-C 2.0 and Cocoa Programming for Mac OS X -- both are references in the Mac world. The Hillegass in particular even has its own forum dedicated to it! The Book

I don't have any criticism of ObjectivCBook.pdf.  However I do have some words of caution.  Many (most?) newcomers find Cocoa puzzling at first.  And reading a book which doesn't refer to the current edition of the tools will add to your confusion.

I of course recommend the book by Kochan that I gave to K.  Aaron Hillegass' book (3rd Edition) is a very good follow on (and K purchased his copy).  I didn't want to give K my copy of the 2nd edition, because it's out of date and will confuse him.

I've written some tutorials:  http://clanmills.com/articles/cocoatutorials/ which you might find helpful.  Most of them have been derived from conversations on this forum.  In fact I added one this weekend because of something K and I have discussed.

I think you'll find Clock is very basic and simple (a few minutes), Diary is quite difficult, QuartzClock is fun and useful (maybe even beautiful).  Please take a look.  I'll be happy to fix errors, clarify things, add new tutorials - or even give you (free) 1-to-1 coaching over Skype (and  VNC or TeamViewer so we can screen share).

Even if it's quite demanding to enter the world of cocoa, you'll be delighted by the garden you find on the other side of the wall of learning.  The system is elegant and easy to use.  It's well worth the price of admission.

I think the learning difficulty is caused by the design patterns used by Cocoa.  Most of them are unfamiliar to new users and it's learning "to think in cocoa" that causes the learning hump and pain.  Once you climb over the fence, you'll be very happy and productive.
 

I find it already rewarding that I was able to add a color-well to my application and write all the related code in pure Obj-C without having a look at tutorials, manuals...but the learning curve is steep :) I take your word about the coach in the future, if I have some tough (to me) problem to solve!

I'll check also the book by Kochan...maybe Father Christmas (my wife) will bring both this and Hillegas :)

Thanks!

Fabio

There's a well-earned productivity boost with Cocoa -- takes a learning curve. Once you get what has to be declared or not, and how to set stuff, and to read documentation, you're ready to be more productive.

Fabio
 
If you already know C or C++, you won't learn much from Stephan Kochan's book.  I bought it by mistake and read it in an hour.  However K has found it very helpful because he didn't have a strong background in C.
 
The book by Hillegass is very useful for getting to grips with Cocoa and Obj/C.  I'm very impressed that you have been able to use the color well (and his delegates) without the book.  I got the HIllegass book from the public library (3rd edition) and then decided to buy my own copy. Make sure you get the latest version of the book (3rd edition) which is based on XCode 3.
 
Incidentally, I did read ObjectivCBook.pdf on Sunday evening and that does seem like a good book and still totally relevant.  I have laser printed a copy of that book about 3 years ago (and never got round to reading it!).  Obj/C 2.0 (in XCode 3) brought some syntatically improvments to Obj/C - however I think everything in that book will work with the current tools.

I have stop studying Cocoa so that I can learn C. After I get that down I will be going back to Cocoa. I have both "Learn Cocoa on the Mac" and "Cocoa Programming" and they very focused books but I think it would be better to go with the "Learn Cocoa on the Mac" first then tackle "Cocoa Programming". This is just the course I have chosen.

When I was a boy, I went for piano lessons (and still play the piano today).  My teacher said "learn the piano and you'll be able to play any instrument you choose later".  And I discovered this to be true.  My piano foundation helped me pick up the guitar, trumpet and accordian.

I think the software equivalent is "Learn C".  No matter what follows, C will be a useful grounding.  C++, Obj/C, Perl, Python (to only name 4) are all descendants of the "C".  You're doing yourself a big favor by coming to grips with C.

Stephan Kochan's book is very well written.  You're going in the right direction.  Good Luck.

I still remember my approach to C. Although I started programming in basic and assembler (!) on the C64 (when I was 8). In later years I moved to Amiga and lost interest into coding (at the age of 16, videogames are better than programming - and then guitar, girls...) I then entered the PC era with a Dx2-66 when I started University. In the first lab course, they started Fortran 77. After the first lesson I went like "Hey, this is *really* a dinosaur! I can feel the smell of puch cards!" and decided to go with C. In a class of about 40 I was the only one to have chosen this (well, to be honest, there was another guy who actually *knew already* C). I will never regret to have done this!

I bought a second-hand copy of Kernigham and simply read it some 10 times, swallowing and digesting every single letter. Still, I believe for plain C nothing beats K&R. It may be old, out of fashion, lacking bells&whistles but it's short, well written and *damn effective*. So these are my two-cents: try K&R! :)

Concerning foundations, I think Robin is *so damn* right. Starting with C provides you the most effective way to actually *do* whatever you like. When I started playing with Cocoa I knew not a single statement in Obj-C but still it hasn't been *that* hard or slow to write code which actually works.

Just a old-fashioned advice: be sure to have the pointers concept crystal clear. That will save you a lot of pain when the projects become complicated!

I agree that K&R (the white book) was the first, and still the best book about C.  I think it's still in print after 40+ years.  http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)  (be sure to get the second edition).

Pointers in C are like the black notes of the piano. You don't have to use them - but all the pros do!

I still don't understand pointers. I found a tutorial online on pointers, but I still don't get them.

All programming languages compile code that use pointers  - however C is unusual because it allows the programmer direct access to the pointer.

Let's take a simple (and very common) example (this a bit like the cp command)
#include <stdio.h>
int main(int argc,const char* argv[]) // WARNING 100% untested
{
if ( argc != 3 ) return printf("syntax error!  Syntax: %s from-file to-file\n");
char* buffer[1024];
const char* in = argv[1];
const char* out = argv[2];
FILE* fin = fopen(in,"rb") ;
FILE* out = fopen(out,"wb");
int n = 1;
while ( fin && fout && n > 0) {
  n = fread(buffer,1,sizeof(buffer),fin);
  if ( n > 0 ) fwrite(buffer,1,n,fout)
}
if ( !fin ) return printf("unable to open %s",in); else fclose(fin);
if (!fout ) return printf("unable to create %s,out); else fclose(fout);
return 0;
}

The C language doesn't have a string type (yes, really!).  You have a char* - a pointer to characters.  When you pass an argument in C, it's always 4 bytes (or 8 in 64bit mode).  So you can't pass the buffer, you can only pass the address of the buffer.  So when you call fread(buffer.....), you're passing the address of the buffer and fread can read from the file, into the buffer.  Similar for fwrite (who reads from the address of the buffer to the file).

Notice the FILE*.  When you open the file, you get a pointer to the FILE (not the FILE itself).  You have to have the pointer to call fread and fwrite.  You can't pass the FILE (it's more than 4 bytes), however you can pass the address of the FILE.

Still confused?  Yes, I'm sure you are.  The black notes are more difficult than the white notes!  You have to practice and then you'll feel OK about them.

Think about NSString* - that doesn't make you unhappy to use that does it?  Sure you'd prefer NSString, however that's not how it is.

Pointers are also used to manipulate arrays (a C char* string is an array of bytes in memory and the trailing byte has the value of zero) - and that's when it gets confusing.  Practice!  Practice! Practice!  Everybody gets it in the end, however it's most certainly not intuitive.  I think it took me 3 years to "totally get it".

In the beginning, I've been fighting against pointers with all my energies - wasting tons of time. Here is a "motivational post" :) on the lines of the contribution by Robin.

My attitude towards pointers changed when I realized that in this way I can access *memory* [pun intended :) ]. True, it's still virtual memory, but it means *power* [again, pun :)]. You have the power to crash you own application and - given the right permissions - even to crash your entire machine. This is absolute control over your computer! 

From a less "God-like" perspective, some things get very easy with pointers: think for instance to a function which must return 2 or more results...without pointers, you should define a struct. In principle, one for *each* function you may need to use.

On yet another perspective, passing arguments by value is not the "natural way" per-se. As an example, in Fortran 77 you *only* pass arguments by *reference* (meaning pointers). This is sure a hellish fun, when you want to cross-link a C application with a library written in Fortran (been there, done that).

The first time I realized I actually fell in love with pointers is when I wrote an (admittedly awful) CD-Player for Linux with Gtk for the interface (still, mp3 was not that popular at the time!). The program (called CdMio, there should be some trace somewhere on the net) was sampling the CD data and we wanted to have several "satellite" displays showing a dancing power spectrum, the waveform, etc...I "discovered" this dlopen() thing which allows you to load an object file (basically in my case a subroutine compiled as position-independent code) in memory and returns to your program a *pointer* to the function. Bang! Plugins were loaded and unloaded dynamically from the memory much to our delight. Think on how to do this *without* pointers :)

The bottom line is that you'll learn to use them. And, without noticing, you'll cross-over from trying to avoid them, to use them in a seamless fashion. Like the black keys on a piano :)

Ciao!

Indeed, your project is available here: http://sourceforge.net/projects/cdmio/

In Objective-C I don't see the use of pointers, in fact. I know there are some methods declared like this:
-(id)doSomethingRiskyWith:(id)object error:(NSError **) err;
They can be implemented as such:
-(id)doSomethingRiskyWith:(id)object error:(NSError **) err {
    // do something
    if (err != NULL) {
        *err = [NSError errorWithinfo:blabla];
    }
}
And can be run with:
theObject = [receiver doSomethingRiskyWith:receiver error:&oops];
Or:
theObject = [receiver doSomethingRiskyWith:receiver error:NULL];
Ah, the joys of programming.

Sticking to a superset of C (which does not alter the fundamental structure of C), you sort of can't avoid using pointers if you want to implement OO programming. And avoiding to make reference to the errors returned by a routine is not an excuse :)

Funny that the ugly duck is still around...it will never become a swan, though :)

Then there's NSColor's getR:G:B:A: method. Used as such:
[myColor getRed:&r green:&g blue: &b alpha: &a];
Declaration:

- (void)getRed:(CGFloat *)red green:(CGFloat *)green blue:(CGFloat *)blue alpha:(CGFloat *)alpha
Yep, pointers are fun!

...and this is fairly straightforward even in C...

FILE *f1;
int a,b,c;

f1=fopen("somefile.dat","r");
fscanf(fin,"%d\t%d\t%d\n",&a,&b,&c);
fclose(f1);

You can't avoid pointers - however you don't have to think too much about them either!

I had an interview at Microsoft and they asked 9 questions in a 4 hour interview.  Most of them involved heavy use of pointers.  Examples: convert a tree to a linked list, or reverse all the words in a sentence without using more that one byte of swap space.  (mary had a little lamb = lamb little a had mary).  I was able to answer all the questions, however I didn't get the job (my pride was hurt).

However in "the real world", you don't encounter such low level code so very often because you'll usually have libraries to do these kinds of things.  The Cocoa Foundation classes such as NSString provide a lots of functions for common operations on strings and of course dictionaries, array, files and so on.

For sure, Cocoa could easily hide many of the pointers.  If you declare:

#define NsString NSString* 

Then you can write:
NsString fred ...... bla bla ....

Not a pointer operator in sight (* or &).

However when it comes to updating variables by calling a function, you only have two choices:
1) you can return one (and only one) 4 byte quantity from the function
2) you have to pass the pointer (the address of the variable) and then the function can change it.

Consider: void getRGB(color, float* r,float* g,float* b)
which might be implemented as something like*r = (float) ((color & 0x00FF0000) >> 16) ; // g and b are much the same

And you'd call it as:
getRGB(color,&red,&green,&blue);

That's easy to understand isn't it?

Woops, I just read fabio's comment about the ugly duckling.  Goodness, I agree.  In 1984, I was the lead engineer on a project being built for the Apollo Workstation (the first window based OS, and the first with ethernet).  Apollo offered Fortran, C and Pascal compilers.  We adopted Pascal.  I discussed the language selection with one of Apollo's guys and he said "C is a complete abomination.  I wouldn't recommend it for anything.  We use Pascal".  Sadly, I've hardly written a line of Pascal in the last 20 years.

It's curious how some very ugly ducklings like C, DOS and bash thrive and some nice things like Pascal and Apollo die.

However a lot of good technology did arrive in the world around that time.  Obj/C, PostScript and C++ all first saw the light of day in the mid 80s and all are alive and well today.  Of course PostScript's rather overshadowed by his child PDF, just as C is rather overshadowed by C++.

For sure, C is an ugly duckling and has grown up to the very ugly duck C++.  I attended a presentation given by Stroustrup and he said "There are only two types of programming languages.  Those that everybody hates and those that nobody uses!".

Nice quote from Stroustrup! Anyway, the "duckling" was related to my old project :)