I am currently learning Objective-C and Cocoa. Next, I want to stick up to iPhone programming. I'll get a book for that, of course. But I would like to know now already, what the main differences are between Cocoa and Cocoa Touch.
Cocoa – What are the main differences between Cocoa and CocoaTouch
cocoacocoa-touch
Related Solutions
Let's start with retain
and release
; autorelease
is really just a special case once you understand the basic concepts.
In Cocoa, each object keeps track of how many times it is being referenced (specifically, the NSObject
base class implements this). By calling retain
on an object, you are telling it that you want to up its reference count by one. By calling release
, you tell the object you are letting go of it, and its reference count is decremented. If, after calling release
, the reference count is now zero, then that object's memory is freed by the system.
The basic way this differs from malloc
and free
is that any given object doesn't need to worry about other parts of the system crashing because you've freed memory they were using. Assuming everyone is playing along and retaining/releasing according to the rules, when one piece of code retains and then releases the object, any other piece of code also referencing the object will be unaffected.
What can sometimes be confusing is knowing the circumstances under which you should call retain
and release
. My general rule of thumb is that if I want to hang on to an object for some length of time (if it's a member variable in a class, for instance), then I need to make sure the object's reference count knows about me. As described above, an object's reference count is incremented by calling retain
. By convention, it is also incremented (set to 1, really) when the object is created with an "init" method. In either of these cases, it is my responsibility to call release
on the object when I'm done with it. If I don't, there will be a memory leak.
Example of object creation:
NSString* s = [[NSString alloc] init]; // Ref count is 1
[s retain]; // Ref count is 2 - silly
// to do this after init
[s release]; // Ref count is back to 1
[s release]; // Ref count is 0, object is freed
Now for autorelease
. Autorelease is used as a convenient (and sometimes necessary) way to tell the system to free this object up after a little while. From a plumbing perspective, when autorelease
is called, the current thread's NSAutoreleasePool
is alerted of the call. The NSAutoreleasePool
now knows that once it gets an opportunity (after the current iteration of the event loop), it can call release
on the object. From our perspective as programmers, it takes care of calling release
for us, so we don't have to (and in fact, we shouldn't).
What's important to note is that (again, by convention) all object creation class methods return an autoreleased object. For example, in the following example, the variable "s" has a reference count of 1, but after the event loop completes, it will be destroyed.
NSString* s = [NSString stringWithString:@"Hello World"];
If you want to hang onto that string, you'd need to call retain
explicitly, and then explicitly release
it when you're done.
Consider the following (very contrived) bit of code, and you'll see a situation where autorelease
is required:
- (NSString*)createHelloWorldString
{
NSString* s = [[NSString alloc] initWithString:@"Hello World"];
// Now what? We want to return s, but we've upped its reference count.
// The caller shouldn't be responsible for releasing it, since we're the
// ones that created it. If we call release, however, the reference
// count will hit zero and bad memory will be returned to the caller.
// The answer is to call autorelease before returning the string. By
// explicitly calling autorelease, we pass the responsibility for
// releasing the string on to the thread's NSAutoreleasePool, which will
// happen at some later time. The consequence is that the returned string
// will still be valid for the caller of this function.
return [s autorelease];
}
I realize all of this is a bit confusing - at some point, though, it will click. Here are a few references to get you going:
- Apple's introduction to memory management.
- Cocoa Programming for Mac OS X (4th Edition), by Aaron Hillegas - a very well written book with lots of great examples. It reads like a tutorial.
- If you're truly diving in, you could head to Big Nerd Ranch. This is a training facility run by Aaron Hillegas - the author of the book mentioned above. I attended the Intro to Cocoa course there several years ago, and it was a great way to learn.
The original code for the Cocoa frameworks came from the NeXTSTEP libraries Foundation and AppKit (those names are still used by Apple's Cocoa frameworks), and the NextStep engineers chose to prefix their symbols with NS.
Because Objective-C is an extension of C and thus doesn't have namespaces like in C++, symbols must be prefixed with a unique prefix so that they don't collide. This is particularly important for symbols defined in a framework.
If you are writing an application, such that your code is only likely ever to use your symbols, you don't have to worry about this. But if you're writing a framework or library for others' use, you should also prefix your symbols with a unique prefix. CocoaDev has a page where many developers in the Cocoa community have listed their "chosen" prefixes. You may also find this SO discussion helpful.
Related Topic
- Objective-c – Does it make sense to first learn Cocoa for Leopard and then Cocoa Touch for iPhone
- Xcode / Cocoa : What are the differences between debug and release builds
- Objective-c – @synthesize vs @dynamic, what are the differences
- Cocoa: What’s the difference between the frame and the bounds
- Objective-c – Cocoa versus Cocoa Touch – What is the difference
Best Answer
The core concepts of Cocoa and Cocoa touch are similar, in that there is a view hierarchy and responder chain. However, the UIView architecture is much more closely tied to the more recent technologies such as CoreAnimation.
The types of controls that are available also change.
Additionally, Cocoa touch introduces the concept of UIViewControllers, which create a nice abstraction for putting code that interacts with your main program and the specific view it owns. As Chuck pointed out in the comments, this was added in Cocoa in Mac OS X 10.5, so depending on how you learned Cocoa you may or may not be aware of them.
Finally, as others have mentioned, Garbage Collection does not exist on the iPhone currently.