|
|
#1 |
|
Prospect
Join Date: Aug 2007
Posts: 9
|
Any help for a person trying to learn Obj-C?
Hello. I'm a technical engineer, and lately I have been trying to learn Obj-C for MAC OSX development (not iOS, yet). I've read a lot and followed a few tutorials here and there. I believe I understand the basics of it all (have some experience with other languages, C, perl, Java, shell scripts, etc), but maybe not.
In just about every example I have seen, there is an AppDelegate, and some "window *" things (for handling windows and the UI). But recently I found myself browsing through Apples sample code and reference material. I came upon this: https://developer.apple.com/library/...ion/Intro.html I downloaded, compiled, and ran the sample code linked above. A window popped up with some fields and display text. I expected this to happen, because there is a nib and GUI shown in the sample project. BUT what I didn't expect is: there are NO appdelgate files, I don't see a (window *) variable anywhere, and while I think I can partially guess WHY it all works, I get the feeling I am missing some important part of the mechanics of it all. All the Tuts I've read/seen show how to connect things like windows and such to the AppDelegate, how to create and connect windows and buttons and fields of a GUI with IBActions or IBOutlets, and that all seems to make perfect sense to me. But this particular example (linked above) appears to have NONE of that! It does have "bindings" which sort of help me see why it could/should work, but even that doesn't explain it all (in my mind). Apologies if this is an inappropriate place to ask such a question, but would anyone here know what it is that I might be missing, and where I might look to learn more on this particular area of knowledge? How does this sample program work without the AppDelegate and the basic GUI stuff that other examples have? What glues this example together? (I'm on Lion, using XCode 4.something, the latest for Lion, I believe) thanks for any reply. mikey |
|
|
|
|
|
#2 |
|
Site Admin
Join Date: Jan 2002
Location: Montreal
Posts: 31,940
|
You really need a book (e.g. the one by Hillegass) to learn Cocoa and Obj-C.
Obj-C is the language, but your question was more about the Cocoa framework.
__________________
hayne.net/macosx.html |
|
|
|
|
|
#3 |
|
Prospect
Join Date: Aug 2007
Posts: 9
|
Oh, I agree that I need a book. I plan to buy one or two next week.
I'd also agree that my question is about the Cocoa framework, and specifically about how this very small example ties in to the framework. I feel that if could figure that out, or learn it, I'd have a much more solid foundation on which to further my knowledge of Objective-C. The Hillegass book is one I will pick up. thanks for the reply! mikey |
|
|
|
|
|
#4 |
|
Major Leaguer
Join Date: Apr 2005
Posts: 477
|
This example shows KVO (key value observing). Suppose in a project you want to make some change every time some other change happens. You could do this in the interface but what you are really doing is using the KVO mechanism programmatically.
So in the example project, KVO is setup using the "keyPathsForValuesAffecting..." methods. Fahrenheit and kelvin has decided to watch celsius. Note that there's more than one way to setup KVO. If celsius changes in the window then F and K also change because they are watching it. If F changes in the window, since it is linked using bindings to the F variable in code, then the F setter method is called, which changes C, and since C changed then K changes. If K changes in the window, then the K setter is called, which changes C, and thus F changes because it's watching C. Bottom line is KVO is a critical technology of cocoa programming. Bindings use the KVO mechanism to work. Note: you also have KVC (key value coding) which defines how you need to write your code so that KVO works. Good luck with your learning! |
|
|
|
|
|
#5 |
|
Prospect
Join Date: Aug 2007
Posts: 9
|
Thank you for your reply. I figured out the part you explained, at least enough to know the watching was going on and how the changing must have been working. That part makes complete sense to me. Mostly because I can see it, and learn from it. It is the pieces of the code/program that I cannot see which are throwing me for a loop.
One thing I am stuck on is how or why a window even comes up, since I do not see any window object creation/references, nor is there any AppDelegate code (which is what I am used to in most examples/tutorials I have seen). This code is mostly an object definition but not much else... A second part is, I tried to add a fourth type of temperature, a fictitious one that would update based on Celsius (like the others), but I could not get it to behave like I expected (based on the setup I can see). Granted I am new to all of this, which is why I am planning to grab a couple books. Now I am wondering whether the Hillegass book would contain enough information...such that I could piece the behind-the-scenes behavior that is going on. thanks again! |
|
|
|
|
|
#6 |
|
Major Leaguer
Join Date: Apr 2005
Posts: 477
|
The window comes up because it's created in the nib file. Nibs (or xibs) contain all interface objects. So click on the nib which opens the nib in interface builder. Click on the window object in the resulting window and then look at the attributes inspector, there's a checkbox that says "Visible at launch". That's checked which makes the window visible at launch. So when the application starts the objects in the nib are unpacked and instantiated, and then act according to the properties you give it in code or in the interface builder inspectors. Note that if you uncheck that box then the window won't show when the application starts. You could make it visible in code but there's no need because of the checkbox in interface builder.
Regarding adding another temperature, just add another textfield to the window and bind its value to the new temperature instance variable you create. Then in code create the @property statement for the variable, the getter and setter methods, and the "keyPathsForValuesAffecting..." method. That's it. Anyway get the book. I have it and it helped me a lot. By the time you're through it you'll have more than enough information to understand lots of this although you'll refer back to that book a lot because you can't really absorb everything. Objective-c language is simple. It's all of the classes that are hard. There's tons of them and it takes a lifetime to learn everything. You have the right attitude though... ask questions, investigate, and never give up. Last edited by regulus6633; 01-14-2013 at 11:17 AM. |
|
|
|
|
|
#7 | |||||||||||||||||||||||
|
Prospect
Join Date: Aug 2007
Posts: 9
|
This is what I thought, and what I tried to do. For some reason, that I am hoping to find in the book(s), I could not make it fully functional. It worked about 90%, but there was always some issue, like it would break one of the other fields, or the new field wouldn't update, or some other issue that I did not understand and could not figure out. I even seemed to get different (still non-working) results just by re-downloading the sample code and starting fresh. That's when I knew I was missing something big, I mean there isn't really anything much I can change in this example - it is pretty small. I have an understanding of the nib/xib and Interface Builder, and I believe I understand the example window and its properties, although I stumbled a bit using the inspectors to figure out the bindings completely - still working on that. I had investigated as much as I thought possible before asking the question (I have learned to try, as hard as possible, to answer my own questions before asking in a forum like this - and I suppose in this case that's where I am). Your words give me encouragement that I am on the right track. I appreciate that, and your willingness to coach me! Off to buy the books...I won't bug this forum again unless it is to answer my own question. mikey |
|||||||||||||||||||||||
|
|
|
|
|
#8 | |||||||||||||||||||||||
|
Site Admin
Join Date: Jan 2002
Location: Montreal
Posts: 31,940
|
Yes - it explains everything step by step. But you do need to devote a few weeks to this learning process. You can't rush it.
__________________
hayne.net/macosx.html |
|||||||||||||||||||||||
|
|
|
|
|
#9 | ||||||||||||||||||||||||||||||||||||||||||||||
|
Prospect
Join Date: Aug 2007
Posts: 9
|
I read, and I read. I was trying hard to figure out why I could not make the above changes work. No matter what I read, or did based on my reading, anything I attempted appeared to cause my version (with 4 temps) to fail. In fact, I could not even type a single digit into my new textfield without crashing the program. No need to hit <CR>, just select my new field and press a '1' - BANG! it crashed. Everytime. Hard crash, stack trace and all. Messing around, I also found that if I typed -99 into the Celsius field it was OK, but if I typed -100 into the Celsius field, the program crashed. I didn't even touch the Celsius field, (or so I think). Anyway, after reading as much as I could on Bindings (and everything even partially related to them), more than most would ever want to know, I finally convinced myself that I was doing everything correctly regarding adding a 4th temperature. So, I gave up on the sample code I had downloaded from Apple (and messed with), started a new project, and typed everything in from scratch. I re-made the bindings, re-wrote the setters/getters, added the fourth temperature, and did everything I thought was necessary based on what the original code looked like, and what I learned (from reading) needed to be done. Wouldn't you know it, the dang thing worked! Not a single problem. I was elated to find that I am not crazy, and that it appears I do understand the basics of bindings (YAY!). As a follow-up I deleted the original project I had been working on (originally downloaded from Apple, then munged by me into an apparently non-working beast). Then I re-downloaded the Apple sample code. Made only my changes for a fourth temperature, and it also worked!!, Which means I must have messed up the original - but I'll be damned if I can see it. It certainly isn't in the code portion. I still have the old project, and expect it will be a great tool for learning to debug crashes someday... |
||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
#10 | |||||||||||||||||||||||
|
Site Admin
Join Date: Jan 2002
Location: Montreal
Posts: 31,940
|
The stack trace should tell you exactly where the crash was and that together with any error messages etc should be enough to diagnose the problem. But note that a common cause of crashes for beginners to Obj-C/Cocoa is forgetting to retain objects. Most people need to read the docs on Cocoa memory management at least 3 times and go through at least 3 tutorials on it. It isn't that it is hard, it's just that it's different and you need to follow the rules. Note also that some crashes are intermittent - they don't happen all the time. Often you will find an egregious bug and wonder how could this ever have worked. Fact is often you get away with blue murder and it only crashes occasionally. I recommend treasuring every crash - it is a sign of a bug that will afflict your program sooner or later - and it's far better that it be sooner. So deal with each crash immediately.
__________________
hayne.net/macosx.html |
|||||||||||||||||||||||
|
|
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|