iOS Learning from an "older" perspective?

[huntercr]

I'm diving straight into iPhone development and throwing caution to the wind! 😀
and I'm learning Cocoa and Objective C along the way. I've had 12 years of professional experience coding in C, almost exclusively for unix environments.

I see how powerful Cocoa is ( and Objective C itself ) and I have great confidence ( perhaps foolishly! ) that I'll be able to write good code once I get over a few hurdles.

Problem is... I am having a hard time understanding *why* you do some of this.

So many tutorials when illustrating devleoping an app say something like "connect blah blah button to File Owner" in Interface builder. Now I understand that you need to do it, but I can't understand *why* you do that. I mean why *really*... What are you really doing when you do that?

That's just a simple example, but it's stuff like that that I am looking to understand.

Anyone know of any books or tutorials that can explain this from the unix perspective?

Sorry for asking what is probably a FAQ. Learning that I have to unlearn what I have learned ( Like having control over the application! ) has been frustrating for an old timer like me 🙂

To me all of this feels so powerful, and yet I'm having trouble getting the quirkiness of the frameworks.

 

[jnic]

So many tutorials when illustrating devleoping an app say something like "connect blah blah button to File Owner" in Interface builder. Now I understand that you need to do it, but I can't understand *why* you do that. I mean why *really*... What are you really doing when you do that?

Follow a couple of the tutorials for a couple of simple apps for the sake of learning roughly the "what" (very dull, sorry), then ditch Interface Builder and start doing your UIs programmatically in the loadView method of your ViewControllers. That'll teach you the "why" very quickly, and should give you the power you're after 🙂

Here's an example loadView to get you started:

- (void)loadView {

	CGRect screen = [[UIScreen mainScreen] bounds];
	UIView *contentView = [[UIView alloc] initWithFrame:screen];
	
	UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 200, 200)];
	label.text = @"Hello World";
	label.backgroundColor = [UIColor redColor];
	
	[contentView addSubview:label];
	[background release];
	
	self.view = contentView;
}

Anyone know of any books or tutorials that can explain this from the unix perspective?

"The iPhone Developer's Cookbook" by Erica Sadun is fantastic; it dives straight into code whilst still being accessible. Can't recommend this book enough.

 

[beachdog]

The "File's owner" thing is, I agree, a subtle and strangely difficult concept when first encountered; at least it was for me. It helps if you understand the basic model-view-controller paradigm that many different UI frameworks are based on (if not, that is too much to cover in this post).

"File's owner" is basically a way to indicate what class is going to be the controller for the view you are looking at in interface builder. Those controls in the view are going to send events somewhere -- to where? Wherever you wire them to, but generally you wire them to "File's owner", so they are sent to an instance of that class. And that class is going to be the controller of the view. They call it "File's owner" because at run time you are going to create an instance of that controller class, and you are going to point it at this xib file to create the view objects and to establish itself as the controller. So, from that perspective, the controller class is going to be the "owner" of that xib file (at least that's how I look at it). To make it simpler, I follow the conventions of many examples, and I tend to name the xib file and the controller class similarly: e.g., if I create "MyViewController.xib" then I also create "MyViewController.h" (and .m), and then I set File's owner in the xib to be an instance of the MyViewController class. Anyways, to make a long story short, all that the "File's owner" information in the xib file is doing is letting you specify the controller class to associate with the view, which you need to do one way or the other (programmatically it would be done simply by having the controller class actually having the code to create the view objects).

UNlike the previous poster, I generally prefer to wire up my UIs in interface builder rather than programmatically, although I am comfortable with either and sometimes a specific feature needs to be done programmatically. In general, this seems to be a matter of choice.

 

[firewood]

If you're a hard core C programmer, skip using Interface Builder and try building all your Cocoa interfaces programatically in code at first. Then after you see how your UI objects are created and accessed by your code, you will understand how IB pre-instantiates and fills in these object data structures for you.

Also, search online for details about the Objective C runtime internals. It's very close to just another mini-interpreter lookup engine.

Consider IB and Obj C as fancy macro generators.

.

 

[huntercr]

Thanks guys, I really appreciate the responses. I well definitely check out that book jnic, and I really appreciated the multiple perspectives from everyone.

I'm determined to get used to this! 🙂