4805 Views 1 2 Previous Next 20 Replies Latest reply: Oct 14, 2009 5:42 PM by musicwind95 Go to original post
Also, note Mihalis's post above that had a few links that will probably be helpful for you. I think one of them is the same as one of the ones I just gave you. I think the other ones are resources outside of the ADC documentation (other websites) that could be helpful, so check them out to if you haven't.
I didn't mention in my last post that, for the links I gave you, you don't have to download them once you get to that site (I just figured this out myself) -- you can click on the chapters individually and page through the document on the web site without downloading it. Or, you can click where it says PDF at the top right of the screen to download it.
Anyways, I wanted to add the following two links to the list:
[A Tour of Xcode|https://developer.apple.com/mac/library/documentation/DeveloperTools/Conc eptual/ATour_of_Xcode/000-Introduction/qtintro.html] -- this is a good little document; I found that it's not so much an introduction to Xcode as it is a guide to making a sample Cocoa application; it takes you through the basics of making a traditional "Hello, World!" application using Xcode and Interface Builder
[Interface Builder User Guide|https://developer.apple.com/mac/library/documentation/DeveloperTools/Conc eptual/IB_UserGuide/Introduction/Introduction.html] -- this is a great introduction to Interface Builder (which, as you probably know, is the application you use to build the GUIs for your applications); it goes over all the basics (and some not-so-basics) of how to use Interface Builder, which is an important part of Cocoa development
I would take a quick run through the Xcode tour (the first link above) right before or during the very beginning of you experience with making Cocoa apps. Even with the simplicity of the "Hello, World!" app it has you create, you probably won't understand everything it has you doing, but that's okay -- it's a good way to get familiar with the basic process of creating a Cocoa app. You could also go back and reference it later any time you need a reminder about any part of this process.
The second link is something I would just reference as you need it. When you take the next step and start learning Objective-C, the book you are using will most likely (or definitely if it's the Apress one) not even have you develop applications with GUIs using Interface Builder. It will likely have you practice the Objective-C language using command-line utilities strictly in Xcode (the Foundation Tool template is the command-line utility that uses Objective-C, in case you're curious). This is a much better way to learn the language -- you won't have to worry about all the fancy stuff while you are still getting the concepts behind the actual language itself down, which is a good thing in my opinion. Then, when you get to the point in the book where it actually has you develop an app using the Cocoa Application template in Xcode, that's when you'll know you're getting into the GUIs and having to use Interface Builder and what not, and that's when I would take a quick run through the Xcode tour that I linked to above. Then, once you start using Interface Builder for those Cocoa apps, the second link should also prove helpful if you need to find out how to do something, or if you want a tutorial early on for how to use Interface Builder (although your book should probably teach you everything need to know about using Interface Builder in the context of Cocoa apps, when you get to that point in the book).
Best of luck, and let me know if you have any other questions.
What exactly does Cocoa do?
I had the same question for a long time, and I'm still not totally clear on it. Someone else around here would be better qualified to answer it, but I'll tell you what I do know.
Cocoa is a framework. I'm not sure how much it actually does -- I think it's more about what it allows you to do. It's a group of libraries that you build applications with, and Objective-C is the language you use to access those libraries. To help with this concept, consider the standard preprocessor directive that you put at the top of your C code:
This statement basically tells the compiler to include all the code from the stdio.h file in your file. The stdio.h file is a file that includes a bunch of code defining functions (like printf and scanf, and many others) and stuff like that. So, without this file, you can't use any of those functions. You could also build your own header file, called myfile.h, for example, that defines a bunch of functions and things that you will want to use often in the applications you create. This way, instead of having to rewrite these function definitions and everything in every application you write, you can simply write:
at the top of each application's code, and all the stuff defined in that file will automatically be included. This is loosely the concept behind what Cocoa does. It contains a bunch of frameworks, and those frameworks contain libraries, and those libraries contain files, and those files contain various definitions for functions and stuff that the people who created Cocoa think you will often need to use in building your applications. I'm not positive if that's the exact structure of it all (frameworks containing libraries and all that -- I'm not exactly sure how all that works), but you can get the basic idea. Cocoa is the framework that holds all the useful stuff that allows you to build apps on the Mac. There is also a Carbon framework for Mac developers, but I don't think it's used as commonly. Cocoa is the main framework that Mac developers work with as I understand it.
Do you need Interface Builder to build a GUI?
Yes, you definitely need Interface Builder to build a GUI. Now, keep in mind, though, that you don't need a GUI to build a program. I don't know how much of this you know or don't know, so I'll go over it all. GUI stands for graphical user interface. An interface is the part of the program that your user interacts with, and a graphical user interface is just an interface that makes use of graphics. Saying that it makes use of graphics doesn't necessarily mean 3D graphics or any of that fancy stuff -- it can be anything that is drawn (icons, text boxes, buttons, even simple static text -- anything). When you open the application Mail, for example, the window that comes up is Mail's GUI. Basically every application that your everyday user would ever use on the Mac has a GUI. However, take the Terminal utility, for example -- it interacts with the user obviously, so it has an interface, but it's purely text-based, there are no graphics, so even though it has a user interface, it doesn't have a graphical user interface. It's a command-line interface. Back in the days of Apple 2Cs and DOS, that's all there was.
Command-line utilities are an important part of learning to program. When you program in C using Xcode, you create a new project using the Standard Tool template in the Command-Line Utility section, right? That's the template for a command-line utility written in C. In the same section, you will also find a Foundation Tool template, which is the ObjectiveC-equivalent of the Standard Tool template. It creates a command-line utility written in Objective-C. Now, Objective-C is mainly for interacting with Cocoa and what not I believe, and Cocoa involves building GUIs, but that doesn't mean you can't use Objective-C for other things, like a command-line utility, and like I mentioned in the last post, when you are first learning Objective-C, it would be a very good idea to program it in simple Foundation Tool command-line utilities, so you can learn the language in the same way you programmed with C before you have to worry about bringing Interface Builder and GUIs into the picture.
So, in summation, a program can be created that doesn't have a GUI (like a command-line utility), and Objective-C is simply a language, so it can be used to build these command-line utilities just like C can. However, Objective-C is usually associated with Cocoa and applications with GUIs because that's what it is mainly intended to be used for. So, once you learn the Objective-C language and decide to step up to building full-on Cocoa applications with GUIs and what not, then you will have to learn to use Interface Builder to build those GUIs. Note that command-line utilities, unlike apps with GUIs like Cocoa apps, can be created with Xcode and Xcode only. Once you get into applications that have graphical interface (GUIs), you will need to use Interface Builder. Interface Builder is the application that you use to create those pretty, fancy interfaces with buttons and text boxes and everything, but by itself such an interface is useless. That's where Xcode comes in -- Xcode is used to write the code that tells that interface what to do and when to do it. You have to write the code that hooks up your GUI from Interface Builder to your code from Xcode.
Do you need Interface Builder to build a GUI? Or can you write one in ObjC? Or rather, is ObjC responsible for the GUI or Cocoa?
The GUI is built in Interface Builder, not written with a programming language like Objective-C. The programming language (Objective-C in this case) is simply used to tell that GUI what to do and when to do it, like I mentioned above. Neither Objective-C or Cocoa are responsible for the GUI, per se. Objective-C code simply tells the GUI how to behave, and Cocoa is just the framework that both the interface and the code draw on for their magical powers. You don't have to think of Cocoa as a solid entity the way you probably think of Objective-C, which is a tangible, real language -- Cocoa is just a framework that everything is built on, sitting there providing the tools necessary to make things happen -- we just use the word Cocoa to refer to application built using the Cocoa framework.
I hope that helps some. Again, I'm not an expert with this stuff, so take anything I say with a grain of salt, and don't hold me to the technical accuracy of every last detail, but that being said, I feel confident in the overall concepts I'm trying to explain. If you want to know exactly what this or that is, or what this or that does, then I'm probably not the person -- you should look to a book or tutorial or a more experienced dev around here, but hopefully the general ideas and concepts I've thrown out there can help you to put yourself on the right track, and please feel free to ask more questions if you have them.
Here's a post from a blogger who sounds like he has a good deal of experience on the iPhone platform and claims that "the role of Obj-C is probably overstated".