iOS Use Interface Builder or not?

[CPlusPlusMan]

No offense, but creating the objects in code does not give you any more control over things. It doesn't give you any less tho, so I agree with you: pick whichever you're more comfortable with.

For me IB is nice because I can create an interface as complex as needed, and only worry about what actually needs worrying in code. My controller classes are not polluted with components that relate only to the view.
Eventually I find IB really helps embracing the MVC pattern, which is kinda wicked

that's great for you... I love MVC too... I'll make a view class with all my control widget objects and instantiate them in main, then I'll implement the right methods to pass the interaction on to the controller who can access the view class... I'll set it up in main and then we'll be off with a neat little gui application... You don't need interface builder to implement an OO methodology. all you need is a text editor, a dev system and the truth. I'm sorry for you that you aren't a skilled enough programmer to use MVC in pure code... really I wonder why you find it to be so great to avoid what you love... because IB makes it that much easier for you.

Great, then go write lines and lines of code.

No one said you had to use the hammer if you'd rather nail it with your bare hands....

not really an accurate analogy... I could go and get a hammer and nails and all sorts of carpenter tools and start building and doing what I love and what I'm passionate about, or I can hire a bunch of guys and get a bunch of postmodern tools to do all of it for me and sit on my ass... the second is easier yes... but it's not doing what I love at all.... It's just lazy and shows that I really don't love carpentry and am not as passionate about it as I claimed to be.

... but then, don't complain that it hurts

Besides, you're argument is plain stupid. Ever tried to do .Net with Java? Qt with Objective-C? It just wouldn't make sense, so why do you want to write Cocoa code in C++? (which, incidentally, is probably the easiest of these three examples).

I don't care if I can do Cocoa in C++... that would be painful. that's not my point... my point was that a Library written in a language which is not dynamic like Obj-C and Cocoa/Carbon was able to give programs an easy way to hand code interfaces in a non-dynamic language no less, for the mac.... Apple is not inhibited by a lack of capability or an impossiblity of concept... Apple is simply choosing not to provide programmers a way to be programmers and do what they're supposed to be crazy passionate about... Apple could do this with little effort given they're using a language that cocoa was built to run on. they just don't want to because they want everyone to use their lazy ass system invented in the 90's (IB). for more insight into my reasoning, see the above posts....

 

[CommanderData]

CPlusPlusMan, you're very passionate about your opinions. I think in my case I hate IB because I got started programming GUI applications using only text editors and the command line over 25 years ago.

I remember the novelty of getting a mouse for the PC in about 1985... no windows, no hard drive, nothing. I had to program an interrupt handler to listen for mouse movements. Then I got started writing a paint program, complete with pull-down menus that I saw from a certain gleaming new Apple product when I went to the museum of science a couple of years before. All of that was hand coded, because nobody was doing anything like it at the time on the PC.

Over a quarter century of this type of stuff gets in your blood. I can visualize the layout coordinates precisely, spacing between objects, offsets from the screen bounds, etc. Doing the math (whether base 10, binary, or hex) in my head all this time helps. Actually the iPhone kind of brings me back to the old days of coding where one guy could make something quite impressive, fun and/or useful working at home. And the optimization puzzles! How do I fit everything I want to do in this limited ram? How do I optimize this bit of drawing code to squeeze out the performance I want? Of course I started with systems with 1.5Mhz processors and 64KB of RAM, so it's not quite that bad... Good times

I learned how to work without IB after seeing how horrid and un-intuitive it was. I picked up bits and pieces as I went, because I was learning Objective-C at the same time. Now I am glad I did. How would I use IB to layout my current game? I couldn't. Everything is custom drawn images residing in various CALayers of the gameplay view. I suppose it might have worked for laying out my custom table cells or custom picker wheel items on some other views, but why bother linking any of my code into some black-box xib/nib whatever the heck they are when I can lay it *all* out in code and see it, understand it...

Try this starter tutorial for interface-hand-coders:
http://blog.mcilvena.com/2009/01/xcode-starting-point-for-iphone-hand-coders/

I would have liked to found this tutorial when I was learning to hand code views and things.

Oh yeah- no offense to anyone who actually likes IB or needs to use it , but I'm more than satisfied without it

 

[Taum]

my point was that a Library written in a language which is not dynamic like Obj-C and Cocoa/Carbon was able to give programs an easy way to hand code interfaces in a non-dynamic language no less, for the mac...

Sorry but:
a) Would you care to explain exactly how Obj-C is not a dynamic language? (because apparently you think Qt's hacks to make C++ look like Java make it *so* much better).
b) Here you seem to be the one not clever enough to understand how to build your interface in code, as other have stated before it is completely possible.

I studied hard how to program in C++ and BASIC and Java and C# and C and Obj-C because I Love programming... I love sitting at my computer writing code... I hate how apple seems to think it's a good idea to take that away by magic so that the lazy programmers here who hate coding and would rather just be code monkeys for money who just wanna do the least work and claim to be a programmer can do just that... It's not fair and it's insulting to us who love our jobs as programmers... who love debugging our code because it's a neat puzzle for us... who love inventing, innovating, and doing new things that no one ever thought of before...

No, sorry but you love writing stupid MVC classes and glue-code. If you think it's the "hard work" and you're passionate about it that's fine, but you can't say it's something no-one ever thought of before.

The point taken by Apple is to design a full MVC architecture for you and let you write only the code which is relevant to your application. What you call "lazy" I call "clever". This way I can then call you the stupid code monkey who writes thousands of stupid lines of code for money

 

[adamk77]

I find IB to be very intuitive.

How much more intuitive can you get --

drag and drop controls and link it to a method?

 

[Aea]

Divulging from the question like everybody else.

I think the moral crusade against making programming easier is misplaced sentiment. Frameworks and Tools like IB haven't made programming any easier for the non initiated or those who want to get into the field with little effort in the long run at all. But they have made the lives of software engineers easier and eliminated a lot of the grunt work that now goes into creating more feature rich and useful applications.

 

[adamk77]

Divulging from the question like everybody else.

I think the moral crusade against making programming easier is misplaced sentiment. Frameworks and Tools like IB haven't made programming any easier for the non initiated or those who want to get into the field with little effort in the long run at all. But they have made the lives of software engineers easier and eliminated a lot of the grunt work that now goes into creating more feature rich and useful applications.

Very well put!

I agree wholeheartedly.

I understand the fixation people have -- a bit OCD, if you ask me -- for wanting to do something always in code because doing it in IB somehow makes them feel like they are an inferior programmer or make them feel like they aren't really programming. But IB is just a tool and a means to an end. You still must know how everything works under the hood. And I really have no sympathy for those who want to get into the field with little or no effort, so I don't really care about them.

 

[Jokode]

Well this forum got real busy! Im just replying to the original question...

Firstly Im still pretty new to xcode (~6months) so Im far from an expert, but personally I found IB to just confuse the issue. You mentioned in your question you dont normally use tools like IB - I was the same when I started so I gave IB a try (which many of the examples force you to do of course), but after struggling for the first couple of days with it I decided to give the pure code approach the same time and see how far I got.

I just found that coding the views and their relationship with controllers in code was more natural to me and I made much more progress.

I also found that doing it all in code gave me a good understanding of how everything works under the hood and as I was new to objective-c, this was a good thing!

So I guess I'm old skool and just prefer doing it all in code Thats my 2 cents anyways.

 

[CPlusPlusMan]

Sorry but:
a) Would you care to explain exactly how Obj-C is not a dynamic language? (because apparently you think Qt's hacks to make C++ look like Java make it *so* much better).
b) Here you seem to be the one not clever enough to understand how to build your interface in code, as other have stated before it is completely possible.



No, sorry but you love writing stupid MVC classes and glue-code. If you think it's the "hard work" and you're passionate about it that's fine, but you can't say it's something no-one ever thought of before.

The point taken by Apple is to design a full MVC architecture for you and let you write only the code which is relevant to your application. What you call "lazy" I call "clever". This way I can then call you the stupid code monkey who writes thousands of stupid lines of code for money

wow... way to still completely misunderstand me. Obj-C is dynamic... C++ is not... yet a library and compiler system has been created for all three operating systems in C++ (a non dynamic language) to interface a library that depends on the dynamism of Obj-C (cocoa) to function.

Secondly, I've found one tutorial through someone's gracious reference that illustrates how to make an iPhone app purely in code..... I want to do the same thing for regular Cocoa NS classes but I still have not found a single tutorial to that effect.

Thirdly, the gluecode in this case is one line.... I'm ok with that. at least I can at the beginning of my application after all the controls are set up, write a list of connections quite simply and it's in code.... at the very least... instead of being a magic part of a nib file that you can't see. It's annoying as hell and I'd rather be able to check every connection in a list in my code.

a code monkey just does what he needs to to make his boss happy and make applications and doesn't really care about the programming. they're not computer scientists. they're not engineers and they for the most part write terrible software.... it's stupid, and it takes all the fun out of making applications! and Apple needs to provide documentation on how to make the same apps purely in code. and it needs to open up it's system to other languages instead of being so ethnocentric about Obj-C. because really the syntax pisses me off because it's ugly and inconvenient as sin!

I'm sorry, but that's just the truth. Apple is trying to appeal to programmers who see their art form as a chore instead of their passion by making it easy to substitute paints and brushes with crayons and colored pencils. you can get quite artful with them, but they're just not the same! I want a palette and brushes... not crayons and colored pencils... I'm a computer scientist... a programmer God-damnit! and I wanna code because that's what I do, that's what I'm passionate for, and neither you nor apple are gonna make me feel otherwise!

 

[dejo]

I'm sorry, but that's just the truth.

No, it's just your opinion.
Seriously, dude, all this ranting is not endearing yourself with others here.

 

[Aea]

I'm sorry, but that's just the truth. Apple is trying to appeal to programmers who see their art form as a chore instead of their passion by making it easy to substitute paints and brushes with crayons and colored pencils. you can get quite artful with them, but they're just not the same! I want a palette and brushes... not crayons and colored pencils... I'm a computer scientist... a programmer God-damnit! and I wanna code because that's what I do, that's what I'm passionate for, and neither you nor apple are gonna make me feel otherwise!

In the real world, we tend to pull tested & tried APIs off the shelf and build our applications around, or using them. There's a little something called not reinventing the wheel.

 

[admanimal]

http://www.rentzsch.com/notes/programmersDontLikeToCode

I'm a computer scientist and a programmer. I don't like to write code; I like to solve problems. Yes, I can write 1000 lines of uninteresting UI code if I really want to but doing so is a pretty mechanical process that I would rather leave to Interface Builder. I get no joy from writing interface code because there is nothing special going on with it; it's all just setting a bunch of properties. I get much more satisfaction out of doing something clever with my code, even if it's just a few lines or involves calling a lot of library functions that someone else wrote for me.

Apple is trying to appeal to programmers who want to spend their time writing the difficult portions of their app rather than trivial but time consuming UI code.

 

[caveman_uk]

Most iPhone UIs aren't that complicated so I tend to do them in code - it keeps the project less cluttered. On the other hand if there's more than a handful of views to place it's much easier to do it in IB. So I do both.