tags:

views:

533

answers:

6

I recently became interested in iPhone app development, so I've been looking at online tutorials, and also reading a book, trying out the examples as I go along.

I'm getting better, but one of the things I still find quite annoying about the usual development model is that I really have no idea what the SDK is really doing behind the scenes to make the app "work" because Apple protects me from this. For example, when I make connections on interface builder, this presumably corresponds to code being generated somewhere... Where that code is and what it does and how it works are not obvious (to me).

So I'm wondering, is it possible to create an iPhone app entirely programmatically? That is, have execution start in some main method, which will then programmatically create any views, register event listeners, etc. And if yes, what are some good resources for something like this?

+2  A: 

I don't use interface builder and it works great for me. When creating a new app in XCode you can chose "Window-based app" and it will create you a window in your new project and the application delegate. The application delegate has method applicationDidFinishLaunching which is effectively your "main" method - you can create views and them into window directly, or you can create viewcontrollers and then add their views into the window.

DenNukem
+1  A: 

Short answer: Yes

Long answer:

Interface builder isn't doing much more than generating XML for you. You can open the XIB in a text editor to prove it, and Xcode is even smart enough to eval the XML and give you compiler warnings when appropriate.

There are lots of tools that auto-gen iPhone projects, probably the most popular being Unity. There is also the open source project Titanium for the adventurous. It's a lofty project to undertake by yourself, so I'd recommend pitching in to help one of the open source projects that are already out there first until you are well versed with it before trying to go off and reinvent a better wheel again.

slf
+9  A: 

There is no generated code. It's serialization. Interface Builder serializes the object tree to the .xib file, your app deserializes it back.

Of course, you can also build your UI in the code, it's just more code. In early versions of the SDK this was even necessary, since Interface Builder was not available yet.

oefe
There are a lot of situations where it's significantly easier to set up your interface manually, there are lots where it's easier to use IB. My iPhone apps are usually mostly code. The views for my OS X apps are nearly 100% IB and I can't imagine what a nightmare it would be to try and replicate them in code.
kubi
+2  A: 
I'm getting better, but one of the things I still find quite annoying about
the usual development model is that I really have no idea what the SDK is really 
doing behind the scenes to make the app "work" because Apple protects me from 
this. For example, when I make connections on interface builder, this presumably 
corresponds to code being generated somewhere... Where that code is and what it 
does and how it works are not obvious (to me).

You've got it all wrong. IB helps you instantiate your control objects and helps you connecting them to your code logic through IBOutlets, but these are real, live objects, it's not code generated, this is a misconception. This code is archived in Nib files (runtime) and in Xib files (used by IB during design) all of this and more, including the Nib Object Life Cycle is explained in detail at https://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW8

And yes, you can bypass IB entirely, but it's definitely not for beginners.

Your tone is slightly condescending, but thanks anyway.
miorel
A: 

Do Apple developers know that in other languages... the "code" and the "interface designer" toosl are both in the same package???? They automatically know about each other. They were designed to work together.

You never need to "connect" anything. No "Outlet" connections. No "Action" connections.

The NAMES you pick for your objects... you can just reference by that name... right in your code.

It makes it EXTREMELY easy to work with.

Bonnie
and your point is?
stefanB
A: 

Bonnie's point is that Apple should get with it and scrap IB. I've stopped using it out of disgust. Have you ever programmed in Delphi, Visual Studio, etc. Light years ahead, baby! RAD = Rapid Application Development, it's been around for years, except at Apple.

Theodore
Unless you're using a definition of Rapid Application Development I'm unfamiliar with, I don't see how this has anything to do with IB. Setting up a demo app in IB is certainly no more difficult than anything else out there.
kubi