[Diggory Laycock]

OK here's my Question:

I'm no super-coder, but I'm fascinated by the power of Objective C and the Cocoa frameworks.

I've run through a few tutorials on Cocoa at O'reilly and reckon i've got my head round some of the concepts.

I'm very keen to learn Cocoa fully and write apps for OS X, but it seems to me that Apple's Frameworks are limited. Foundation seem to be a great base for further classes {thus the name} and AppKit seems to be a great framework for building Aqua GUI-ed Apps {and dealing with opening/saving, undo, AppleScripting etc. }

But that's all there is. Don't you feel that there is something missing? Apps need more than a document architecture. There needs to be another framework that deals with handling hardware.

As far as I can tell if you want to do that you have to use Carbon APIs in your code.

That's fine for people with 10 years of Old-school Mac development. But If I have to learn Carbon as well as cocoa to write truly useful apps then why learn cocoa in the first place?

I assumed that cocoa and carbon were equal citizens in OS X - that anything carbon could do cocoa could do, but it seems that cocoa relies on Carbon for Hardware access.

Where are the classes that represent Infra-Red communications?
Where are the GameSprockets-esque input device classes?
Does anyone else feel that using cocoa they can't quite get full access to the OS?

Should I be expecting apple to provide this kind of framework in the future or is apple expecting third-party developers to cook-up their own frameworks and then publish them? Surely this will end up like OS 9 where the core of the system is clean, but end-users have to rely on a raft of unstable or expensive system add-ons.

Or have I mis-understood the whole thing? If so please put me right!

[ 10-22-2001: Message edited by: Diggory Laycock ]

[Millennium]

Cocoa is, by and large, a GUI API. The main focus of Carbon is the same; it may seem a shade more "complete" due to legacy API support, but that stuff is only there for backward-compatibility. If you take a look at Apple's own tools and tutorials, Carbon is basically used as a GUI API. There are many other API's which are neither Carbon nor Cocoa, but used by both. CoreFoundation is one particularly common example. As for your questions:

Where are the classes that represent Infra-Red communications?

I don't know for certain, but presumably in IOKit. It's where they belong, at any rate; I don't know if they've actually been put into place or not. I'd think they'll be there when they are added, if they are not there already.

Where are the GameSprockets-esque input device classes?

HIDManager.

Does anyone else feel that using cocoa they can't quite get full access to the OS?

Not particularly.

The idea behind Unix (and, by extension, OSX) is that you use the right tool for the job. Tools are often small, but integrated well enough that you can do some amazingly powerful stuff by combining the tools in the right way. What is commonly called "Cocoa" is really a set of two tools: FoundationKit and AppKit, which happen to have Objective-C interfaces. Quartz is another tool, as are IOKit, HIDManager, and QuickTime.

It is true that some of these don't use Objective-C's message-passing mechanism. But they're still perfectly accessible via Objective-C. Just because you use functions rather than messages doesn't make it any less valid.

Cocoa is good for what it does. So is Carbon; it's merely another path to the same destination.

[Diggory Laycock]

I see. Thanks. So, man cannot live on Cocoa alone.

looks like I'll have to learn C as well.

[Millennium]

Originally posted by Diggory Laycock:
<STRONG>I see. Thanks. So, man cannot live on Cocoa alone.

looks like I'll have to learn C as well.</STRONG>

You already know C, for the most part. Objective-C is just a superset of C (this is a large part of why it makes so much sense to code Cocoa in Obj-C; you can integrate other API's very easily). There's a few things that you probably haven't been using yet, but these won't be a problem to pick up.