21–30 of 51 posts
Hope it helps!
The fine print for new iOS devs: If you succeed in overcoming all of the obstacles ahead of you and actually create a worthwhile app on Apple's platform their is a good chance they will screw you over without warning or explanation by blocking your app, yanking your app, changing the rules, calling you a pornographer, randomly charging you new fees, prohibiting whatever it is your app does, changing the hardware you'…
Man, there's all these things standing in the way of success! I'd better not even try. Come on, seriously? There's risk involved in pretty much every venture, and you can't exactly control the actions of outside entities. If I kept avoiding tasks because there was a chance of it being screwed over by someone else, I'd never get anything done.
Earlier quoted context omitted.
Model View Controller is an odd mental model? It's quite popular right now and I think that it's the best pattern for decoupling user interfaces from the underlying code.
MVC is fine. It's the way that your controllers are instantiated by a NIB that I find odd. It's too magical for me.
The fine print for new iOS devs: If you succeed in overcoming all of the obstacles ahead of you and actually create a worthwhile app on Apple's platform their is a good chance they will screw you over without warning or explanation by blocking your app, yanking your app, changing the rules, calling you a pornographer, randomly charging you new fees, prohibiting whatever it is your app does, changing the hardware you'…
Earlier quoted context omitted.
MVC is fine. It's the way that your controllers are instantiated by a NIB that I find odd. It's too magical for me.
Serialization, marshaling, pickling...whatever your favorite terminology, that's all a nib is: archived object instances. If you don't have a mental model for that then you've got bigger problems than interface builder.
I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on.
I suppose I could have gotten over those mental hurdles eventually, but I chose not to. I prefer thinking about objects that I make myself, and I avoid Interface Builder whenever possible.
Earlier quoted context omitted.
MVC is fine. It's the way that your controllers are instantiated by a NIB that I find odd. It's too magical for me.
It's exactly the opposite of magical: you're simply building objects in IB that are "live" while you're building them and that then are freeze-dried when you save the file, and reconstituted at runtime. It's certainly magical in the sense that it's a beautiful way to do things. ;-)
Earlier quoted context omitted.
Serialization, marshaling, pickling...whatever your favorite terminology, that's all a nib is: archived object instances. If you don't have a mental model for that then you've got bigger problems than interface builder.
Personally, I don't agree with that. I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on. I suppose…
Even if you just wrap your head around File's Owner, you're 80% of the way there. Essentially, what it boils down to is this: it's a proxy object that gets set when NSBundle's loadNibNamed:owner:options: is called (which is called behind-the-scenes by UIViewController, which is where you'll usually be interacting with nibs). So, in Interface Builder, you change the class of File's Owner to whatever class should be managing the nib and it will give you access to all of that class's IBOutlets.
Like you, I prefer to create a lot of my UI programatically. But in a lot of cases it's just so much more efficient (from a time management perspective) to lay everything out in Interface Builder.
Yes – programming is fun to hop into, but just a heads up: the most difficult process to learn and master is the marketing and promotion part of releasing an app. I feel that two blog posts linked in this article touches this subject in an interesting way: http://struct.ca/2010/the-story-so-far/ and http://blog.endloop.ca/blog/2010/08/12/100k-in-4-months-a-ni... That said, I would recommend Corona - http://www.anscam…
Really not sure I agree with that. Coding is tough, and in my experience developing iOS apps well (and Cocoa apps in general to a lesser extent) is one of the most difficult forms of programming. And as for marketing and promotion, I'd say even more challenging is coming up with an idea which doesn't need marketing or promotion :)
And yes – the biggest challenge is probably coming up with something original!
The fine print for new iOS devs: If you succeed in overcoming all of the obstacles ahead of you and actually create a worthwhile app on Apple's platform their is a good chance they will screw you over without warning or explanation by blocking your app, yanking your app, changing the rules, calling you a pornographer, randomly charging you new fees, prohibiting whatever it is your app does, changing the hardware you'…
In most of your cases it's pretty clear going into it how much risk you run of any of those things happening to you. And for most people that risk is almost 0.
And as others have already responded: there's always risk.
Earlier quoted context omitted.
Personally, I don't agree with that. I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on. I suppose…
Here's a pretty good overview of the various objects you mentioned: http://developer.apple.com/library/ios/#documentation/Cocoa/... Even if you just wrap your head around File's Owner, you're 80% of the way there. Essentially, what it boils down to is this: it's a proxy object that gets set when NSBundle's loadNibNamed:owner:options: is called (which is called behind-the-scenes by UIViewController, which is where you…