The Complete Guide for Starting iPhone and iOS Development
writings.withoutfriction.com
writings.withoutfriction.com
Hope it helps!
Winter 2010- http://itunes.apple.com/us/itunes-u/iphone-application-devel...
Spring 2009-http://itunes.apple.com/us/itunes-u/iphone-application-progr...
Spring 2011 (Starting Soon)-http://www.stanford.edu/class/cs193p/cgi-bin/drupal/
I've followed parts of CS193P twice (can't remember which one) and both were pretty good. If this one is really better, I wouldn't like to miss it… :)
Oh I can not say enough good things about that class. Great teachers, great material.
Yes, it's technically illegal but isn't that the best kind of illegal?
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.anscamobile.com/corona/ - for anyone wanting to give iPhone app development a shot. Much easier and fun to jump into than objective-c, especially if you want to make games, and still pretty damn powerful!
Going the Cocos2d route will also help you learn some of the peculiarities of the platform, like memory management and object lifecycle, while giving you enough skills to jump right into pure CocoaTouch.
Nothing against Corona, it has it's place. Bubble Ball[1] was developed with Corona for example.
[1] http://www.pcworld.com/article/216880/8th_graders_iphone_gam...
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!
You're welcome to do it all in code, but it seems to be discouraged by many.
Now in the nib you say "here are three buttons, connect them to outlets a, b, c." Now when Someone asks the controller for it's view it will create the views and connect the pointers in the manner you requested.
There is "magic" taking place, but no more so than the interaction between HTML and JavaScript in a web page. It may be unfamiliar at first, but not unfathomable.
It's certainly magical in the sense that it's a beautiful way to do things. ;-)
I think simple programs should be able to be expressed in one file and created in a simple text editor.
You're saving creating the hundreds of lines of codes that would be required to do this in a "normal" IDE.
This seems a patently false statement. I would count as code any representation of procedural or configuration information that could be interpreted or executed in the running of an application.
If the underlying systems requires hundreds of lines to represent a simple object (like a button, panel, or toolbar), then maybe as a programming environment designer, you should go back and simplify your underlying representation, rather than add a layer of UI to generate hundreds of lines of code.
UIButton *button = [UIButton buttonWithType:UIButtonTypeRoundedRect];
[button setTitle:@"Button" forState:UIControlStateNormal];
Of course, if you want to display the button:
button.frame = CGRectMake(10, 10, 80, 20);
[view addSubview:button];
Now, when you put together all the objects in a moderately complicated UI, you will end up with hundreds of lines of code. Some people find it easier to work with this visually in Interface Builder. Others find it easier to manually construct the UI in code. Either method works perfectly well. I generally use a mix of both, depending on the nature of the UI element I'm working with.
All of our designers use IB to layout the UI. It works really well - as they don't have to touch the code and we don't have to touch the layout.
Unfortunately, if you are doing any kind of custom animation (think sliding/expanding), IB is useless - you'll have to set the frames in code.
In general, IB is great because it helps separate presentation from the code.
When I first started out, I hated IB, but I've come to accept the fact that it really does help productivity (when working with designers closely). If you hate IB, consider going Android - there is nothing like IB on Android. All XML and a simple (nothing like IB) layout editor.
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.
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.
That's a tautologically pointless thing to say.
It's weird we live in a world of hand-holding comfort and plentiful documentation on almost everything and yet we still create more.
How terrible we are for wanting a world of comfort instead of superior discomfort and confusion.
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're allowed to use, changing the software you're allowed to use, and many other ways that seem impossibly outrageous right now until it actually happens.
Invest your time and money at your own risk. You've been warned.
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.
All platforms have downsides.
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.