Linked by Jared White on Wed 7th May 2003 07:13 UTC
General Development Welcome back to Part 2 of Cocoa 101: Object-Oriented Programming for the Masses! I received a lot of great feedback on my previous article, and I'm looking forward to sharing with you once again what I've learned about Cocoa and the Objective-C language. If you missed Part 1 of this tutorial, read it here.
Order by: Score:
This is more like Objective-C 101
by dysprosia on Wed 7th May 2003 08:00 UTC

You don't really touch much on the Cocoa part of things. Cocoa is a framework. Objective-C is a language.
What I would have found more interesting is an exploration of the Foundation and Appkit frameworks.

call [super dealloc]!
by Lee Harvey Osmond on Wed 7th May 2003 08:28 UTC

If, in your method - (void)dealloc { ... }
you fail to call [super dealloc], as in the example I can see in this article, then your instance variables will be released (and garbage collected), but not those in any superclasses, and ultimately, the object itself will not deallocate. This causes a serious memory leak.

These two tutorials are.....
by Ralf on Wed 7th May 2003 08:45 UTC

...very good.

Just this.

Ralf.

Re: Objective-C 101
by Anonymous on Wed 7th May 2003 09:21 UTC

While I agree with dysprosia to an extent, perhaps the author is planning on continuing to write more articles, and Cocoa does require at least basic knowledge of Objective-C.

Very nice
by Anonymous on Wed 7th May 2003 10:27 UTC

Very nice, and I would love to read more. Are you sure you don't want to spend some time on Part 3, Jared? Pretty pleeeaaase? :-D

Autoreleasing & dealloc-ing
by Paolo Manna on Wed 7th May 2003 10:38 UTC

There is another (treacherous) memory error in the sample code...From the Cocoa documentation (Programming Topics - Memory Management):


It is possible for you to obtain a new object by invoking a class method of the form +className.... These class convenience methods create a new instance of the class, initialize it, and return it for you to use. Although you might think you are responsible for releasing objects created in this manner, that is not the case. Because the class method allocates the memory for the object, it is responsible for releasing that memory, thus class convenience methods should return their values autoreleased.


Thus, when you create in -init a NSCalendarDate or a NSColor through their class methods ([NCalendarDate calendarDate] & [NSColor clearColor]) you're actually getting an object that will be autoreleased in a real world application. If it doesn't fail on your tests it's because you probably don't have a running NSAutoreleasePool in place. For a correct programming, you should either:
- retain it (sensible thing to do, if you want to use it later)
- avoid a release in -dealloc (because the object will be gone anyway)

Memory management in Cocoa is wonderful when you finally manage it, but has its conventions...

Cocoa/GNUstep cookbook
by Nicolas Roard on Wed 7th May 2003 11:26 UTC

Marko Riedel just started to write a GNUstep cookbook (in the same spirit as Perl cookbook), but it's useable as well as a Cocoa cookbook :-)

see http://www.roard.com/docs/cookbook/

other tutorials : http://www.roard.com/docs/

Happy stepping ;)

Garbage Collection
by Pete on Wed 7th May 2003 12:07 UTC

As described, it sounds like Objective-C uses reference counting and language keywords for memory management.

I'll stick with Java... (At the expense of running a background thread to handle GC)

Reference counting was a technique explored in C++ texts as a prototypical garbage collection approach. (Scott Myers, smart pointers? I could be wrong.)

It sounds like extra work for the programmer, implementing code to do reference checks everywhere. And if you miss some, potentially problems abound.

I'm not saying Java doesn't have memory issues, just that the technique in objective-C has been discredited.

Ultimately a question of pre-compile checking through development tools (obj-c) or by the runtime system (java)

See
http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc_p.html
For details of GC. (A very old article, not accounting for advancements in JVM technology over nearly 7 years!!)

JIGS
by Pete on Wed 7th May 2003 12:15 UTC

on reading my previous posting. I came off sounding as a smarmy Java person.

Nothing against Cocoa the environment, in fact Java bindings for *step such as
http://www.gnustep.it/jigs/index.html
look most interesting...

Re: Reference counting
by Rayiner Hashem on Wed 7th May 2003 13:21 UTC

I'd hardly say that reference counting GC has become "discredited." I haven't used ObjC, but I have used the reference counting equivilent in C++. A reference counting smart pointer, like shared_ptr from Boost, is just as good as garbage collection in most cases. All you have to remember is that instead of:

int* i = new int

you do:
shared_ptr<int> i = new int

After this, 'i' will automatically take care of deallocating memory when it goes out of scope.

All very good
by Sean on Wed 7th May 2003 13:25 UTC

But when do we get into the chocolate theory behind cocoa?:)

And what about milk to mix ratio?:)

More seriously, it is nice to see someone writing about the great programming enviroment that Cocoa/OPENSTEP/GNUStep provide. Hopefully it will get a lot of Linux people interested in it since it would give Linux an edge over Windows in ease of programming and quality of programs, not to mention the fact that it would solve a lot of the compatibility across distros problems that can be seen today. Just think, no more package management problems and programs that have more consistant and user friendly interfaces than anything that Windows has to offer.

Re: Reference counting
by Nicolas Roard on Wed 7th May 2003 14:50 UTC

Well reference counting isn't very difficult to program with, simpler of course than malloc/free, and it's more efficient than garbage collecting ... it's a good solution.

Anyway you could use garbage collecting with GNUstep if you want, althrough I never used it (reference counting don't bother me and I like to have a better control on what is done). But GC isn't available with Cocoa.

Objective-C and Cocoa
by Heinr!ch on Wed 7th May 2003 15:48 UTC

(I'm being the devil's advocate here - so forgive me...) I have a hard time imagining developers embracing Cocoa, let alone Objective-C. Why would anyone want to program in a language that effectively is only popular on one platform? Why would anyone want to use a closed framework that's bound to a single platform? As an enterprise developer I can tell you that there's no way any IT shop I know of would consider going back from Java or .NET. Yes, you can write Cocoa apps in Java. But again, why would I do this instead of SWT or Swing?? These facts alone will keep Apple in the consumer market - barely.

Re: Re: Reference counting
by Megol on Wed 7th May 2003 16:00 UTC

> Well reference counting ... [is] more efficient than
> garbage collecting ... it's a good solution.

This is not always true, sometimes a pure GC is more efficient.

Re: Objective-C and Cocoa
by Christopher Culver on Wed 7th May 2003 16:02 UTC

"(I'm being the devil's advocate here - so forgive me...) I have a hard time imagining developers embracing Cocoa, let alone Objective-C. Why would anyone want to program in a language that effectively is only popular on one platform? Why would anyone want to use a closed framework that's bound to a single platform?"

Cocoa is an implementation of the OpenStep specification. It's cross-platform. Right now Cocoa apps can run on Mac OSX or Linux with little change necessary, and hopefully the Gnustep platform can be made to compile on Windows.

Re: Re: Reference counting
by Nicolas Roard on Wed 7th May 2003 16:05 UTC

This is not always true, sometimes a pure GC is more efficient.

I agree ... <u>sometimes</u> it is more efficient.

Re: Objective-C and Cocoa
by Heinr!ch on Wed 7th May 2003 16:59 UTC

"Cocoa is an implementation of the OpenStep specification. It's cross-platform. Right now Cocoa apps can run on Mac OSX or Linux with little change necessary, and hopefully the Gnustep platform can be made to compile on Windows."

That's great but I just don't see developers embracing it en masse when Microsoft, Sun, and IBM are pitching a simpler development paradigm - which truly applies to 95% of application development requirements out there. Very few apps need such fine control over system resources these days because it's far less expensive to scale up than it is to write such concise applications (that's not to say that some apps wouldn't benefit from it). If you look at how companies are spending money right now, you'll note that it's on creative integration and scaling (up or out). Few, if any companies, are switching from VB, Java, or .NET to C, C++, or Objective-C. That's all I was saying. ;-)

Memory-management mistakes
by Jared White on Wed 7th May 2003 17:03 UTC

Aaahhh! I did forget that I need to retain the calendar and color objects since they were already autoreleased. Yes, I didn't go too much into the fact that convention dictates, for the most part, that new objects returned by convenience class methods have been autoreleased. I'll make sure I fix this right away, along with the missing dealloc message that should be sent to the superclass after the instance variables have been released.

Thanks everyone for catching these mistakes!

Jared

Question
by dan on Wed 7th May 2003 17:18 UTC

"It's cross-platform. Right now Cocoa apps can run on Mac OSX or Linux with little change necessary, and hopefully the Gnustep platform can be made to compile on Windows."

This is a real question:

Would it help if Apple started really pushing cross platform Cocoa (openstep?) programming tools for other platforms? Would it be helpfull to all *NIX environments if they all shared this common approach?

Re: Objective C and Cocoa
by Anonymous on Wed 7th May 2003 17:36 UTC

I have a hard time imagining developers embracing Cocoa, let alone Objective-C. Why would anyone want to program in a language that effectively is only popular on one platform? Why would anyone want to use a closed framework that's bound to a single platform?

I have a hard time imagining developers embracing MFC... why would anyone want to use a closed framework that is bound to a single platform? ;)

Look, I'm all for cross-platform solutions, but using things like Swing/Qt/etc is a tradeoff. You usually can't access all of the GUI functionality of the platform, and its often obvious that your product isn't a "native" application.

What most large applications do is keep the back-end code in ANSI C/C++, then use native toolkits for each platform GUI. So in OS X, the GUI would be in ObjC + Cocoa. In Windows, it would be in MFC. The beauty of ObjC + Cocoa is in just how quickly you can create a fully-functioning GUI and integrate it with the rest of your app.

And for the posters interested in Java: Apple provides Java bindings to Cocoa. It's built into their tools, so when you write a Java app, you can forgo swing for Cocoa if you want (again, to get a real native feel for the app... or if you just prefer Java over C/ObjC).

Re: Objective-C and Cocoa
by Nicolas Roard on Wed 7th May 2003 17:43 UTC

what is far more important than the language (considering it has some "common" features like Objects support, of course), is the quality of the development framework and perhaps the developpers tools. And honnestly, OpenStep is way ahead if you considere quality, consistency, elegance and ease of use. I don't even speak about InterfaceBuilder (or Gorm in the case of GNUstep) for creating GUI.

It's a truely wonderful framework. You develop way more quickly with it ...

Reference counting isn't very difficult to use... there are some simple rules to follow , of course, but frankly it's not a so big annoying point (in fact for many people it's even a plus !). Good case study, GNUstep supports the use of a garbage collector instead of the retain/release ... but almost any GNUstep programmers/programs uses retain/release (the only exception is GNUstepWeb which uses in some parts of it garbage collecting).

see http://www.stepwise.com/Articles/Technical/HoldMe.html
for a good article on retain/release.

Don't focuses on retain/release, it's not worth it, and you'll miss the quality of OpenStep ...

Please continue!
by Adric on Wed 7th May 2003 19:41 UTC

This series has been quite informative thus far, and has helped untangle some of the issues that have thus far kept me from getting anywhere with PB, IB, AppleScript Studio, etc.

You've cleared up some of the weirdness of ObjC syntax admirably. Now, if you can only help me understand how
to apply weird ObjC syntax to actually attaching methods to widgets (The connection between IB connections and the real code in PB?)

Either way,
Thanks

OK, everything will soon be fixed....
by Jared White on Wed 7th May 2003 21:05 UTC

Hi folks,

The memory mistakes in my code have been fixed (along with some of the explanations), but I didn't convey the placement of the fixed paragraphs properly to the editor, so right now it's all a bit mixed up. But it's being taken care of right now, so, hopefully soon, everything will look right.

Sorry about that,

Jared

re re Obj-C and Cocoa
by dysprosia on Thu 8th May 2003 09:41 UTC

If one is able to fix OS X .pbproj files to original .project files, then one is effectively able to run the same code on OPENSTEP, thus crossplatform to Intel, Moto, HP and Sparc architectures as well. Without the .pbproj conversion, you could still recreate the project yourselves: the codefiles are quite compatible if you don't use the Cocoa proprietary objects (which there aren't many)