Clever Geek Handbook

What's the advantage of Xcode's seemingly overly complex control / logout workflow?

I am new to Objective-C, Cocoa, Xcode and Interface Builder. I have a C background in the past as well as a lot of RealBASIC experience.

I'm working on the Mark and LaMarche iPhone 3 Dev book and I'm really just stunned at how tedious some things are. Maybe someone can shed some light on this for me. My question is, why does the process for seemingly simple actions involve such a complex number of steps? Is there a benefit to complexity that I will fall in love with later? Or is it just a brute fact that is inevitable?

For example, in RealBASIC, if I want the slider value to be displayed in the textbox, I just add:

myTextBox.text = mySlider.value

for the slider. Changed event. I can program this in less than 1 minute.

In Xcode / Interface Builder, I have to physically inject a declaration for both the textbox and slider, then also inject a property / output declaration for each, then create a method declaration and implementation for ValueChanged, even then set up the (relatively) complex integer value type slider in NSString using initWithFormat. Then I have to go back to Interface Builder to bind the controls to the controls and methods that I introduced. I can't see how this can be done in much less than 10 minutes. Maybe 5.

So what's the use of this? Why doesn't the Builder interface automatically create, or at least suggest, manage declarations and @property statements, and method declarations and implementations? Why can't you double-click the slider in IB, present you with a list of events, and prompt you to automatically insert a skeletal method into your .h and .m file? And why does IB even have to be a separate application?

I agree that some of them are my unfamiliarity with all the Xcode stuff, but is it really as efficient as a development environment?

I apologize if this is a dead horse theme, flames with opposite sides at full aggro. If so, just say yes, what it is and move on.

Thanks Rob

+2


source to share


2 answers


Many of the reasons behind IB work will become clearer as you get used to the MVC paradigm.



Once you start using Cocoa Bindings, which update your model when the user interface changes and vice versa, you should see a huge performance boost.

+3


source


I, too, used to think that Xcode and Interface Builder were unnecessarily complex until I worked on the book on both (specifically Getting Started iPhone Development: Learning the iPhone SDK ).

If you are serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend putting together a book like the one I used. Of course it was for iPhone development, but I think there is another book by the same publisher (or author) that is direct Mac programming.



Once you work through this and understand what is going on behind the scenes, it starts to make more sense. In a way, I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.

Give the book a try and see if it helps :-) Good luck!

+1


source






More articles:


All Articles