See the latest about a temporary release delay on new titles. Learn more. Do they need to know anything about using Apple's development tools or Objective-C? Aaron Hillegass: One of the most difficult things about writing a book is choosing your audience. It would be great to write a book that assumes nothing; anyone could read it.
|Published (Last):||8 October 2014|
|PDF File Size:||12.19 Mb|
|ePub File Size:||4.70 Mb|
|Price:||Free* [*Free Regsitration Required]|
See the latest about a temporary release delay on new titles. Learn more. Do they need to know anything about using Apple's development tools or Objective-C? Aaron Hillegass: One of the most difficult things about writing a book is choosing your audience. It would be great to write a book that assumes nothing; anyone could read it. However, an experienced programmer would find the resulting book painfully tedious. In the end, I decided to assume that readers are familiar with the C programming language and thinking in an object-oriented manner.
The reader with this base knowledge will find Objective-C to be a rather unsurprising language, so the book moves quickly through the fundamentals of Objective-C and into the design patterns of Cocoa. Scott: Conversely, how far does this edition take the reader? In other words, if a developer has already stumbled through the basics, knows the Objective-C syntax, and has compiled a few sample apps, will they find this book useful?
Aaron: I think the old adage rings true: "If you only know how to use a hammer, everything looks like a nail. The typical self-taught Cocoa programmer has mastered a few concepts and uses them in every situation. By going through the book from beginning to end, the reader gets familiarity with a large collection of ideas and technologies. This deeper understanding results in better, more reliable applications — because the reader uses the Cocoa frameworks as they were intended to be used.
The book doesn't cover everything — that would take thousands of pages — but I have done my best to identify and explain the concepts that the average Cocoa programmer uses on the average day. There is also some interesting feedback in the system: Because my book has become the standard approach to learning Cocoa programming, a lot of documentation and discussion on the internet assumes that the audience has read it.
Thus, the chapters in the book now represent the core knowledge that every Cocoa programmer is expected to have. Scott: I see that you've refined many of the existing chapters, as well as added brand new material.
Which new chapter did you find the most interesting to write, and which existing chapter received the most re-working? Aaron: For years, I have taught students in my classes how to do view swapping in an elegant, maintainable way. With It isn't nearly as glamourous as Core Data or Core Animation, but I think the chapter on View Swapping was the most satisfying addition because it is a technique that Cocoa programmers use daily. The NSArrayController chapter was reworked so much that it eventually underwent mitosis and became two chapters: One dedicated just to the ideas of Key-Value Coding and Key-Value Observing and a second devoted to the mechanics of using these ideas with NSArrayController.
Scott: I've seen emails from novice developers who liked the way the previous editions of the book were written, but were confused how they didn't match up with the recent changes in Mac OS X Has all of that been addressed now? Aaron: If Apple would just stop innovating, I would stop rewriting this book and write new ones instead. Yes, the third edition is now up-to-date with Xcode 3.
The world outside Apple has also been changing. For example, web services have also become very important, so I added the web services chapter to the book. Scott: What was the most challenging part of writing this edition of the book?
Aaron: The technologies documented in the first and second edition of the book had been around for a decade, and the community had developed a set of common idioms and best-practices. I could authoritatively say, "This is how we do it. No one can speak about their use with complete authority. I did my best to study how the engineers who created them wanted the technologies to be used. Scott: Is the material in this book a good starting point for developers looking to hit the ground running with the iPhone SDK, or are the development concepts too different?
Do you plan to write a book specific to iPhone development? There are ideas that have changed — for example, controls on the iPhone can have multiple targets and actions — but they have evolved naturally from the ideas of Cocoa programming.
That class, which will be every bit as brilliant as our Cocoa Bootcamp, is going to focus only on iPhone development. By removing ideas like the pasteboard, we create time and space for discussions of iPhone-specific topics like the CoreLocation framework and the accelerometer.
Perhaps that class will become a book someday, but we need to test and improve it in the classroom for a while first. Scott: What would you say to new developers who are trying to figure out if they should learn Objective-C or use one of the Cocoa scripting bridges in Leopard?
Aaron: For fifty years, there has been a heated debate going on about programming languages. In the meantime, real programmers have been solving real problems with imperfect languages like Perl and Objective-C.
Perl and Objective-C have three things in common: They come with incredible libraries. They don't get in your way. Both languages have good performance and loose typing. They are easy to learn. Ruby and Python are lovely scripting languages, and you can write Cocoa applications with them after you learn Objective-C! Cocoa was written in Objective-C and for Objective-C.
You will never really understand Cocoa until you understand Objective-C. It is true that some people have voiced the opinion that the iPhone SDK should have been based on languages other than Objective-C. However, it is important to note that none of these people have ever shipped an application written in Objective-C. Anyone who has used Objective-C knows that it is an able work-horse. Aaron: Fear of the NIB file. Experienced Cocoa programmers put a lot of the smarts of their application in the NIB file.
As a result, their project has a lot less code. Programmers who have spent a few years working in Visual Studio get freaked out. I like to see the code. Maybe I can just explicitly create my windows and the views that go on it? It is difficult to explain how the NIB file and a few other scary ideas create leverage. It is that leverage that enables one guy in his basement to compete with a team of engineers at Microsoft or Adobe.
It is like I showed a chain saw to a early American colonist, and he said, "Can I cut down the tree without starting the engine? I don't like the noise. Maybe I can just bang it against the tree? Scott: I think a lot of developers wonder how to get their work noticed by potential employers, customers, and the community. Do you have any suggestions? Aaron: One of the nice things about the Mac community is that quality gets noticed. People love their Macs, and anything or anyone who can make it better will get recognized in blogs and discussion groups and magazine articles.
The Mac community has been very kind to me; people have spent a lot of energy explaining the strengths and weaknesses of my books and my classes. I couldn't be more grateful. Scott: What sort of effect do you think the iPhone will have on the Mac development community? Do you think they'll divide into separate camps, or is it more likely that the lines will blur?
Do you expect to see an influx of new Mac developers from the iPhone? Aaron: It is a great time to be a Cocoa programmer. They are selling iPhones by the boatload. The Cocoa community is, in the grand scheme of things, rather small right now. I suspect that it will double in size over the next two years. Everyone in that community will know how to write code for either device. A good iPhone app is going to be very different from a good Mac app. Overall, I suspect that a brilliant iPhone app will take six months to write, while a brilliant Mac app takes five years.
I suspect that there will be two camps — not because the skill sets are different, but because iPhone programmers will have different personalities and proclivities than Mac programmers. Scott: The Mac appears to be making real inroads in the mainstream consumer computing market, and certainly the iPhone is doing the same.
Do you expect to see this carry over to the corporate world? Aaron: Apple seems to doing its best to keep Macs out of the corporate world. Most dialogues between Apple and a corporation go something like this: Corporation: Hey, does Cocoa include something to help us write apps that talk to our Oracle database?
Scott: What do you find most rewarding about the books you've written and the classes you've taught? Seeing the light go on in the student's head, seeing them ship an app, or something else? Aaron: I'm a good programmer — I've written large medical, military, and financial systems — but that is not my calling.
I am a teacher, and I live to get people to "Aha! Over my career, I've developed and tested many theories about teaching and learning. Now, I want to make these ideas manifest in a physical form. I have purchased some land, and I'm working with architects to design an environment for learning — the new Big Nerd Ranch. Scott: Mac development has changed a lot in the last few years, and dramatically so in the last six months. What sort of things surprise you when you see them now versus how things were when the first edition of the book came out in ?
Aaron: I think people overestimate how much has changed since The last 16 years have been spent making significant, but evolutionary, steps toward fulfilling the promises embodied by the elegant ideas in NeXTSTEP 1.
Scott: When you're not busy writing, do you spend most of your time teaching classes in person, or are you involved in other projects? Aaron: I teach about a dozen classes each year. I continue to help our clients write applications for the Mac, and now the iPhone, but as Big Nerd Ranch grows, I spend more and more of my day being a business guy.
Cocoa Programming for Mac OS X, 3rd Edition
View larger. The highly acclaimed introduction to Cocoa—recommended most by experienced Mac OS X developers now updated and expanded. It's the best book for a beginning Cocoa programmer. The descriptions are clear, the examples logical. Everything a programmer needs to get up to speed on Cocoa. Guiding programmers through the key features of Cocoa, this book emphasizes design patterns that enable you to predict the behavior of classes you have never used before. Written in a tutorial format, it takes you step-by-step through the creation of six applications and an Interface Builder palette.
Cocoa Programming for OS X Quotes
The highly acclaimed introduction to Cocoa-recommended most by experienced Mac OS X developers now updated and expanded. It's the best book for a beginning Cocoa programmer. The descriptions are clear, the examples logical. Everything a programmer needs to get up to speed on Cocoa. Guiding programmers through the key features of Cocoa, this book emphasizes design patterns that enable you to predict the behavior of classes you have never used before. Written in a tutorial format, it takes you step-by-step through the creation of six applications and an Interface Builder palette. Each project introduces several new ideas, and as each concept or technique is discussed, the author, drawing on his own extensive experience, shows you the right way to use it.