Objective-C or Cocoa First - objective-c

I am new to Mac/iOS development. I am coming over from C# .net. My question is should I read on Objective-C first or Cocoa? I don't want to buy two books and start reading one and find out I should have only got one book and read it.
Thanks
Curtis

Seeing as how the Cocoa frameworks were built with Objective-C, learning the language is the logical first step.

You don't need to become fluent in the language, to the point of exchanging implementations and dispatching blocks like nobody's business, all before you learn the frameworks. Indeed, such an undertaking would be folly.
At the same time, you can't learn Cocoa without a firm grasp of OOP, dynamic dispatch (messaging), MVC, and other important concepts. Some of these underlie Objective-C, some are part of Objective-C, and some are separate from Objective-C.
I say start learning those concepts, including the basic portions of the language, and then pick up the framework before you get too far into it. Like Regexident said in their comment on one of the other answers, you pretty much can't practice Objective-C without using Cocoa anyway, so it won't be long before you need to start into the framework to in order to practice the language—at which point you'll be practicing with both.
Relevant Apple documentation:
Object-Oriented Programming with Objective-C
Learning Objective-C: A Primer
Cocoa Fundamentals Guide
The (full, gory details of the) Objective-C Programming Language
If you don't already know C, start there. As with Objective-C, you don't need to become a full-blown C guru, but you do need to understand pointers, declarations vs. statements, how function calls work, the differences between the primitive types, and other basic concepts.

Objective-C is just a superset of C. All the Cocoa books that I've seen introduce Objective-C in the first part and then go on to describe how to use the frameworks. I'd recommend just getting a Cocoa book, just leaf through it and make sure the Objective-C primer in it is meaty enough for you.

I believe there is a lot of good information in the various answers here (especially #Peter Hosey's), but I do want to make sure we're not confusing the OP.
You can't practically learn ObjC without learning Cocoa today. It's like learning C# without learning .NET. You absolutely should focus very early on the patterns and underlying concepts of Cocoa (like MVC, as PH notes). But you'll get that best by working through things that teach you practical iOS or Mac development techniques rather than working through something that tries to provide a more "pure ObjC" experience such as writing command-line apps (though even Foundation is part of Cocoa, so even then you can't escape it).
The key lesson here is that I recommend new students focus on resources that teach them the whole process they need to develop for iOS or OS X. It's worth learning Xcode, ObjC, and Cocoa(Touch) together, along with MVC, target/selector, and the other critical patterns, rather than trying to take them one at a time.
PH is absolutely correct that you don't need to learn all of ObjC in one go. You can do a lot of development and never use blocks or KVO for instance. (That may change in future versions of iOS, but it's still true today.)

Related

Where should I go next?

Well, I think I have enough knowledge of cocoa that I can go learn another thing. What would you recommend learning after learning cocoa? (Ex. Core animation, OpenCL, core data)
I really depends what your goals are. If you want to stick to Objective-C, dive into Cocoa Touch if you haven't already. I'd also suggest checking out frameworks such as MacRuby if you want to stick to developing Mac apps, it is pretty sweet.
If you want to go somewhere totally different, I've been messing around with Rails and Android a lot recently.
Learn LISP.
It is fundamentally different from pretty much every other programming language there is. It will force you to think of problems in new ways. Even if you never ever will use LISP in a real world project (I never did) you will become a much better programmer.
Anyone who wants to call themselves a programmer should known about (spent at least a full week with):
C - to know the heavy lifting and how it actually works.
LISP - to understand functional programming.
Smalltalk/Objective-C - to understand real object oriented programming.
Prolog - to understand logic programming.
C++, and any language that derives its OOP design from it, is just C structs with function pointers. Yes Java and C# I look at you too.
Learning PostScript is a good way to broaden your understanding of the drawing model also used by Quartz and AppKit, and can be useful for prototyping your drawing code.
Learn another language. Maybe C/C++ since they are similar. Or maybe C#. Or you can try something completely different such as python, pascal, D or VB.
depends what you aim for
but if you are not strong in C/C++ I would suggest that. A) its what cocoa is based on B) if you want to port your code to other platforms, usually you'll have a good chance of reusing directly the C/C++ withou a lot of changes.
(Ex. Core animation, OpenCL, core
data)
those are just tools, if you want to specialize in iphone then its good practice to look up the various feature, look at the examples and then implement a little example for yourself.
otherwise if you have no precise goal you can also go to the bookstore and pick a random book ^^

New to ObjC, coming from AppleScript Studio and not understanding certain things

Yes I've seen questions like these before but they're all for people who basically want to start from scratch. I come from AppleScript Studio (for those who do not know it, it's AppleScript in Xcode with IB etc.). The only things new to me are related to interface and implementation files. In my code I've already written 2000+ lines of ObjC, so it's not the syntax. But I fail to understand inheritance, accessing variables from other class files, etc.. The way I use ObjC is having one NSObject in IB which its class is changed to something new by me and then all my code is written in that one implementation file. My biggest problem is finding out how to access parameters from other classes.
So do any of you have any tips on where to start? Normally I'd start from scratch with a book but I seem to fairly be able to write code as long as it's located in one big file...
Thanks for your help.
I've had excellent luck with these Cocoa Dev Central tutorials, and they're short and well-organized enough that you should be able to skip over any parts that you feel you already know.
http://cocoadevcentral.com/articles/000081.php (C)
http://cocoadevcentral.com/d/learn_objectivec/ (Obj-C)
http://cocoadevcentral.com/d/learn_cocoa/ (Cocoa part 1)
http://cocoadevcentral.com/d/learn_cocoa_two/ (Cocoa part 2)
http://cocoadevcentral.com/articles/000082.php (Style part 1)
http://cocoadevcentral.com/articles/000083.php (Style part 2)
It sounds to me like you can probably skip the first (C), but it couldn't hurt to skim it. The second (Obj-C, especially Part 5, Designing a Class Interface, and onward) is where the answers to your immediate questions lie. Good luck!
Although you understand Interface Builder, it's very clear that you don't understand Objective-C or Cocoa very well at all. You need to stop flailing around and give yourself a firm grounding in the language and frameworks. The only way to do this properly is to start at the beginning.
You should start by learning Objective-C properly. In my opinion, the best way to to this is to read Stephen Kochan's superb Programming in Objective-C 2.0. This will teach you how to write Objective-C properly and explain object-oriented coding, class inheritance and so on. You should read the book cover to cover and do all the exercises.
You should then read Aaron Hillegass' Cocoa Programming for Mac OS X which will teach you how to take Objective-C and marry it to Interface Builder and the Cocoa frameworks to produce working Cocoa apps.
You should also read Cocoa Design Patterns which will explain what the design patterns in Cocoa are and how to use them to your advantage to write Cocoa apps the right way.
I can relate to your confusion on those particular aspects of Objective-C coding. The notation used to pass arguments and access object attributes is quite different than other C-type environments. Creating your object properties with the #synthesize directive (when applicable) can go a long way to ensuring consistent behavior. Also to keep in mind that Obj-C uses the 'super' keyword to access base objects instead of 'base'.
When I was first learning Obj-C I learned from this Apress guide and felt it to be a helpful transition from a C/Java background to understanding Obj-C's syntax and object/inheritance model.
I would suggest that your "problem" has nothing to do with Objective-C and everything to do with object-oriented design. I would get a good OO book such as Design Patterns (Gamma, et. al.), Object-Oriented Software Construction (Meyer), etc. I would suggest not using Objective-C for this part of your education (use Java), because you will easily confuse software design with learning the Cocoa (and other) frameworks. Once you get a leg up on this, you can then explore how to apply in objective-C, how Cocoa framework uses object-oriented techniques, etc.
And enjoy!
PS: The ability to write code is not your goal, particularly if the code is located in one big file.

Strategies for porting Carbon code to Cocoa

I'm looking for strategies and articles on making Carbon code 64-bit ready.
Carbon for 64-bit does not and will not exist. It's pretty much a dead end.
So in order to bring Carbon application and toolkits to 64-bit their GUI part will have to be re-written in Cocoa and Objective-C, right?
How can I minimize the effort I have to put into the transition? How can I minimize the amount of needed Objective-C code?
So in order to bring Carbon application and toolkits to 64-bit their GUI part will have to be re-written in Cocoa and Objective-C, right?
Yup.
How can I minimize the effort I have to put into the transition? How can I minimize the amount of needed Objective-C code?
Learn Cocoa. Read The Objective-C Programming Language and the Cocoa Fundamentals Guide. Become familiar with MVC, KVC, and Objective-C. Bookmark the Foundation and AppKit framework references. Learn to love Interface Builder, for it is your friend (moreso in Cocoa than it ever was in Carbon).
Get good at Cocoa. Read more Guides (if you're still on Leopard, use [1] instead). Write as many throwaway apps and even real apps as you can get away with in whatever time you have available. If you can, give them away under a BSD license, and write reusable source code and give that away, too. People will find bugs and some will tell you about them, and some will submit patches. Get to be able to write a complete app with a model layer, no more than two controllers, and at least one custom view or cell in a day.
Read the Carbon Porting Guide, then port your app.
I came from Carbon myself. It's completely different—you may as well start fresh, ignoring your previous Carbon experience, and maybe you won't make some of the early mistakes I did (like skipping the model layer).
As for your app, you probably have a lot of surgery to do, as Carbon did not force you to keep UI and logic separate like Cocoa does. Cocoa enforces MVC; if you don't adhere to it, you pay the price by reinventing wheels and making and correcting mistakes.
That makes Cocoa sound like more work, but it's not. Porting is hard (inevitably), but otherwise, Cocoa is quite the opposite: Writing (and reading!) a Cocoa app is much easier than writing (and reading) a Carbon app. Once the porting is over, you'll be glad you switched.
Oh, and many people will recommend one or both of Cocoa Programming for Mac OS X by Aaron Hillegass and Programming in Objective-C 2.0 by Stephen Kochan. I have the first book, and have read some of it, but that was after I had already learned Cocoa, so I can't earnestly recommend it; that said, it is not bad, and I don't think you'd do wrong to read it. I have not even seen the second book, so I won't say anything about its quality.
[1]: file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/index-date0.html (Stack Overflow won't let me link file: URLs)

Which is easier for beginners: RubyCocoa or ObjC/Cocoa

I've heard a few debates in the past over which is more mature: RubyCocoa or Obj-C/Cocoa... but I have felt that the answers jet right over the "newbie" that would truly appreciate an answer.
So the question is: for a total beginner, with little-to-no programming experience, is it easier to learn Ruby and explore Cocoa via the bridge (then possibly tackle Obj-C) or to straight up jump right into Objective-C and Cocoa.
Both communities are strong and have a plethora of resources, but as many people have pointed out the syntax of Obj-C is just daunting. Perhaps for a true beginner it would be easier to learn Ruby then tackle Objective-C?
Update: I apologize, but when I said "learn Ruby and explore Cocoa" I did not mean to learn programming via RubyCocoa, but rather to learn Ruby (and once one feels confident enough) begin to explore Cocoa with the possibility of leveraging their growing skill-set to tackle Obj-C.
I would not recommend learning to program with RubyCocoa.
I love Ruby and think it's a great language to learn programming, but the RubyCocoa bridge isn't documented well enough that I'd recommend it as a learning environment. You'd be learning general programming concepts, the Cocoa frameworks and the quirks of RubyCocoa all at the same time. That's a lot of stuff to shove into your head.
If you're bound and determined to start with Cocoa, start by learning Objective-C. Otherwise, you could learn Ruby to begin with and then transition to Objective-C once you feel a little more comfortable as a programmer. And once you've done all that, you can use RubyCocoa, but then you'll know enough that it won't make you go crazy.
I would start with what Apple is preaching: Objective-C/Cocoa
Writing Code is the Easy Part
No point really in:
Try to see which is easy, if you are opting for the easy way, you will always get it wrong.. fear not what is hard, for hard is to fear not.
Trying to compare languages/approaches that way, as per the post I added, thinking what's easy/nice/hard in this case is a question of syntax, which ultimately boils down to interpretation, beauty is in the eye of the beholder.
Depending on what they will ultimately attempt to do with the technology you will find somethings are "easier" than others in one approach or the other..easy is a hard thing to define
Only one question matters: What does one know before being exposed to any of the two approaches? -- you said:
for a total beginner, with little-to-no programming experience
My answer:
Often near where I live tourists ask:
"How do I get to placename X from here?"
People here usually answer:
"If I were you, and I was trying to get to placename X, I wouldn't start from here.."
So.. the answer to your question is:
Neither
Total beginners should always study the basics of programming as per what #Tafkas said.. (not necessarily needing to study OOP languages.. but programming...) before making any kind of decision on what to study and/or implement. (This + requirements gathering)
..Otherwise the people learning these language/technology skills will be just another set of script kiddies on their way to becoming copy paste code monkeys
The problem with starting with RubyCocoa is that you end up learning both ruby and cocoa and the interaction between the two at the same time. I would say learn ruby, or learn Objective-C/Cocoa. Jumping right into RubyCocoa is going to throw you off.
It sounds like your goal is to learn to program in Cocoa, using either Ruby or Objective-C as the language.
While I've never used Ruby (or RubyCocoa, for that matter), my understanding is that Cocoa is written with Objective-C as the primary language, and the bridges (Python and Ruby) come in second. While they generally work well, there are some rough edges that aren't there when using Cocoa from Objective-C.
I would say that you should go the Objective-C/Cocoa route. It might not be bad to start with another language first - C if you want to learn it (which would be useful, since Objective-C is a superset of C), or something like Java if you want to go the OO route.
That's not to say that RubyCocoa doesn't work or isn't useful. It's great for what it does, but I don't think that it is the place to start with Cocoa programming.
I would suggest that if your going to be serious about writing Applications for OSX and/or the iPhone I would highly suggest you get your feet wet with Objective-C and Cocoa.
The reason are simple:
The Documentation from Apple on Objective-C is excellent.
You're going to get more help from the community here at Stack Overflow because there are more Objective-C/Cocoa developers than RubyCocoa. (from what I've seen so far).
The Objective-C Developers are very good at helping each other out and I could not find a better group of developers with open arms to new people learning the language.
Great Developer books are available as well as outside training if you want it.
The big one that I see is that you can NOT develop for the iPhone using RubyCocoa. But if you learn Objective-C/Cocoa you can pretty much dive right into Cocoa Touch.
There is no guarantee that Apple will keep RubyCocoa updated as much as they do with Cocoa.
Don't get me wrong, learning Ruby is a great language and I don't think you can go wrong learning it. However right now if you have the option right now to learn either or, go with Objective-C/Cocoa.
I think you're in for a harder road by going with RubyCocoa if you want to build serious applications for either OS X or especially later for the iPhone.
The main reason is simply being able to find answers to common programming questions that you might have. There is a burgeoning community around Objective-C/Cocoa with a lot of forum support, code snippets, samples, etc. It will be infinitely easier for you to rapidly learn how to you use Cocoa if you understand Objective-C. It will also be easier for your peers to troubleshoot your code and help you out when you get stuck. Objective-C is really not that hard to learn, especially if you have some kind of grounding in OO concepts.
I would suggest to start with an oo language such as c++ or java. After understanding the basic comcepts of oo it should not be to hard to learn objective-c.
The problem with ruby cocoa is that there is no guarantee apple will support this in the future. They have dropped the cocoa-java bridge in the past.
I think this depends on how much the beginner already knows. If you already know object oriented programming, you should definitely learn objective-c. Thinking in paradigms like messaging, delegation, and categories will help a lot to understand the Cocoa system. If you've got a few languages under your belt, but no object oriented programming, then you probably also have enough experience to learn OOP through Cocoa, but understand that it handles things differently from languages like C++. If you have very little programming experience, then ruby may be better in the short term.
One other advantage of objective-c to keep in mind is the manual reference counting memory management paradigm. It can be much easier to deal with than malloc/free, but it doesn't allow the laziness that Java and scripting languages engender.

Do I have to learn Objective-C for professional Mac Development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Do I really have to learn Objective-C to develop solid Mac Apps?
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
So do I really have to learn Objective-C ?
I would prefer a dynamic language.
Objective-C is a dynamic language, as far as the Objective-C parts go. Here's a little summary article: http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html
The syntax is scary at first, but it grows on you. I suggest biting the bullet and slogging through it.
If you want to work at a "real job" doing Mac programming with other people, you're going to need to know Objective-C (in my opinion, anyway).
I think the short answer is yes, you need to learn Objective-C.
The Python and Ruby "bridges" work, but it's not what Apple is pushing or using itself. A few years ago there was a Java bridge to Cocoa but that's now deprecated. Who knows what will happen to the non-ObjC languages?
In any case, Objective C is pretty dynamic. Not in the way that Ruby/Python are perhaps, but it's certainly not like C++.
Short answer: YES :)
Our first app was built in Python, using the PyObjC bridge. From experience I can tell you that to build an application with a bridge you need to learn:
The idiosyncrasies of the bridge
To read and write code in the bridge language (Python in my case)
To read code in Objective-C (All useful sample code is in Obj-C)
To write pseudo-code in Objective-C (if you ever want to ask questions on a mailing list or likewise)
Cocoa
Of all those things to learn, Cocoa is the biggy. It's where the really interesting stuff comes in and the thing you really need to wrap your brain around. After working on this PyObjC project, it's become pretty easy for me to code in Obj-C, even though I had no prior experience coding in C.
So my advice is: Focus on learning Cocoa, and use the language that's most suited as a tool to do that (Obj-C). If you ever find a particular reason to use a bridge, such as having a need for an ORM that can deal with networked SQL, etc. you can apply around 90% of what you learned writing your first Obj-C/Cocoa app(s) in the bridged project.
Finally: I don't really understand the resistance many people who're new to the platform have to learning Objective-C. Isn't it exciting and gratifying to learn new stuff and build the best possible things armed with this new knowledge?
You definitely need to learn Objective-C even if you choose to use one of the bridges. Apple has already shown by their treatment of Java that they're not really interested in providing huge amounts of support or backwards compatibility to the use of Cocoa through anything but Objective-C.
So use one of the bridges, if you like, but have a firm grasp of the Objective-C runtime and the bridges so that you can manage them yourself, if need be.
Do I really have to learn Objective-C to develop solid Mac Apps?
Currently, yes.
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
Correct.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
Cocoa#: I don't know, as I don't use C#.
PyObjC: Sort of, but Cocoa in Python is a bit of a hack, since Python isn't Smalltalky enough.
RubyCocoa: Maybe. I'm waiting for MacRuby to mature, though. See also:
Jens Alfke on MacRuby
Jesper on MacRuby
There are a small number of successful Cocoa apps written in bridged languages, so you don't necessarily need to use it that much, but you do need to learn it. People who try to learn to write Mac OS programs in bridged languages do themselves a huge disservice. The bridged languages are great tools, but they are the sort of things that allow someone with a knowledge of the bridged language and Objective C to become extra productive, not skip learning Objective C.
In order to use something like PyObjC or MacRuby effectively you need to really have a good understanding of how the native runtime works to deal with all the impedance mismatches that can occur between the bridged language and the Objective C runtime.
Short answer is yes, longer answer is "you can use Objective-C++." Either way you're going to have to learn at least some of Objective-C. Once you start digging into Cocoa (the framework for building Mac OS X apps), the Xcode tools, and the Apple Human Interface Design guidelines, you'll realize that Objective-C is the way to go.
Not only you have to know Objective-C (the easy part), you must be very comfortable with plain old C. That's in my opinion the biggest challenge for most people.
If you already know C, Objective-C is pretty easy to learn.
Ruby and Python are both viable for "real" Mac apps. ADC has a few articles on the topic. MacRuby looks like it will be replacing RubyCocoa.
I would still recommend learning Objective-C though. Most of the example code you find will be in Objective-C and the books tend to be Objective-C (though the Pragmatic Programmers have a RubyCocoa book in the works. Most Cocoa apps are written in Objective-C.
And Objective-C is dynamic. Take a closer look at it, it isn't nearly as intimidating as people think. It's Cocoa that tends to have the steeper learning (or unlearning) curve.
No you don't have to learn cocoa however it is worth looking at because it is an incredibly powerful api and very well documented, if you already know C then its very easy (honestly it is - i know it looks daunting syntactically).
The problem with the bridged approach on OS X is it seems to be very immature and only really designed for people who are prepared to read the documentation associated with the main cocoa api.
In all honesty if you know c you will pick up the basics of obj-c with a book, the one by Arron Hilligas (spelling?!?!) is superb.
If you try hard enough, you can go about producing software without using Objective-C that has the potential to be great except for the fact that at the end of the day it won't be very good. You will spend more time trying to harangue a language into doing something that it isn't the absolute best at. At WWDC I wore a shirt that said "Learn Objective-C or Retire" which didn't go over too well with some people who still held dearly onto the last threads of Pascal's life, but the point is altogether true - Objective C is where it's at on the Mac and to pretend otherwise is to do yourself a disservice.
Having said that, you should definitely not rule out the bridges on the platform for extending your application - Bill Bumgarner is quick to point out how much power the Twisted networking framework provides to Cocoa applications via the PyObjC bridge.
Not programming in a scripting language turns out to not be so bad when you're using XCode. The GDB integration is very good; I'm primarily a Perl guy, and I find the XCode debugger very nice and very easy to use.
The "fix" feature will really surprise you with how usable it is. Imagine finding a bug in your ObjC code, fixing it, and then telling the debugger to continue on. It actually works in a lot of cases.
Try ObjC. You may find you like it a lot better than you think you will.
"have to", well... technically, no.
Since most Mac app jobs are done thro ObjC (for a very good reason I might add), I wouldn't kid yourself and learn it.
Hell no. You can use a number of languages to make a nice GUI with. It just depends on what's the usual/easiest solution for the platform. In Mac OS X's case, Objective-C and AppKit are pretty easy to use choices. However, I use REALBasic sometimes, and that allows cross platform development (and, of course, a performance hit).
So really it depends on how much work you want to put into it. You should learn Objective-C if you want to really do serious Mac development. But you can get by without it....
No. While Apple is strongly pushing Cocoa, Carbon is still supported. It uses plain C instead. As for good-looking GUIs, just use Interface Builder.
However, I must say that Objective-C is a great language. It is really easy (it was my first language) and very powerful.
In general yes; but even if you (correctly IMHO) ruled out Mono, GTK and SWING because they don't fit well in the GUI, try Qt. it's REALLY respectful of Mac GUI standards (HIG: Human Interface Guidelines), and can be equally programmed on C++, Python and Java. the last version is cocoa-based and 64-bit capable.
the only thing missing from Qt that you'd get from Objective-C is those awful non-HIG-compliant modern Apple applications (yeah, Aperture and Final Cut, I'm looking at you!)